Im Bereich Produktdesign haben Light-Versionen mittlerweile einen festen Stand. Seien es Lebensmittel, Streamingdienste, Versicherungen, Reisen oder Heimwerkerbedarf: Light-Varianten versprechen Basisausstattung statt Komplexität und obendrein einen schnellen Einstieg. Auch im Identitätsmanagement hat sich dieses Prinzip etabliert. Hier steht "Light IGA" für abgespeckte Identity-Governance-and-Administration-Ansätze, die mit vorgefertigten Standardkonnektoren und klar begrenztem Umfang zügig Mehrwert liefern sollen.

Im IGA-Kontext wären Basisfunktionen beispielsweise die Anbindung von HR-Systemen an das Benutzerverzeichnis, automatisierte Bereitstellung von Zugängen für gängige SaaS-Apps oder die Strukturierung von Reviews und Zertifizierungen. Vollwertiges IGA ist weniger ein Tool für Anträge und Reviews als eine komplette Steuerungsebene: Es zielt darauf ab, Identitäten (auch Maschinen- und Servicekonten) und Berechtigungen über heterogene Landschaften hinweg (Cloud, Legacy, DevOps, Datenplattformen) konsistent zu erfassen, zu bewerten und in nachweisbaren Prozessen zu kontrollieren.

Der Haken: In großen Organisationen wird aus dem "schnellen Einstieg" oft eine trügerische Sicherheitskulisse. Denn ausgerechnet die Identitäten, die im Ernstfall entscheidend sind – etwa Servicekonten, Cloudadministratoren, Legacy-Logins, Entwicklerzugänge – liegen häufig außerhalb der Reichweite besagter Light-Versionen. Identitätsmanagement gerät dann zur Insellösung und Governance zum Lippenbekenntnis.

Beim Audit platzt die Illusion

Auf den ersten Blick kann ein schnell integriertes IGA-Werkzeug ungemein attraktiv klingen und viele Aufgaben auf einmal lösen: Die wichtigsten Systeme wie HR, Active Directory, Microsoft 365 und diverse Kernanwendungen sind schnell angebunden. Joiner-Mover-Leaver-Prozesse laufen automatisiert, Zertifizierungen werden endlich fristgerecht abgeschlossen. Die Sicherheitsverantwortlichen sind zufrieden. Doch dann stellen Auditoren die wichtigen Fragen: 

• Wie werden Servicekonten in Cloud-Kontrollebenen gesteuert?
• Wer verantwortet gemeinsame Logins in alten ERP-Prozessen?
• Warum haben externe Auftragnehmer in Entwicklungsumgebungen Zugriffe, die bis in Produktivdaten reichen?
• Wer hat was genehmigt und nach welchen Regeln?

Bei genauerem Hinsehen wird plötzlich sichtbar, was die Statistik nicht zeigt: Viele dieser Systeme sind gar nicht Teil der IGA-Plattform. Nicht, weil das Team unsauber gearbeitet hat, sondern weil die Plattform dort endet, wo ihre Konnektor-Bibliothek endet. Der Rest wird zusammenrecherchiert: Logs, Tickets, E-Mail-Verläufe und Excel-Listen. Der gewünschte Audit-Trail bleibt Stückwerk Das ist die eigentliche Trennlinie: Light IGA automatisiert, was erreichbar ist. Vollwertiges IGA muss steuern, was relevant ist.

Was Light IGA kann und warum das oft nicht reicht

Light IGA verspricht einen schnellen, günstigeren und überschaubaren Einstieg. Typischerweise gelingt damit ein großer Schritt weg von manueller Bereitstellung und sporadischen Zugriffsreviews. Das Problem beginnt aber dort, wo "Standard-Enterprise-IT" endet. In vielen Unternehmen beginnt genau dort der eigentliche Aufwand Wenn die Governance an den Rändern ausläuft, entstehen wieder genau jene Parallelprozesse, die IGA eigentlich ersetzen sollte: informelle Genehmigungen, lokale Ausnahmen, historisch gewachsene Konten. Das Ergebnis wirkt ordentlich, ist aber lückenhaft. Und in der Sicherheit sind Lücken keine Nuance, sondern ein Geschäftsrisiko.

Diese Lücken entstehen aber nicht nur durch mangelnde Reichweite. Die Integrationstiefe bei fehlenden Konnektoren ist nur ein Aspekt, der bei Light IGA zu kurz kommt. Durch immer dynamischere Prozesse braucht es eine Kombination aus stabilem Framework und Anpassungsfähigkeit. Light IGA verführt dazu, fehlende Funktionen mit der Brechstange anzupassen oder mit Skripten nachzurüsten. Das macht nicht nur den Betrieb kostenintensiver, sondern erhöht auch die Kosten, wenn sich Unternehmen besagten neuen Anforderungen anpassen müssen. Gerade die Integration von KI-Elementen – etwa für Datenanalyse (Risikosteuerung, Rollenmodellierung), Benutzerführung oder die Einbindung von Non-Human-Identities – ist in solchen Umgebungen oft kaum erreichbar.

Wo die Unterschiede zum Risiko werden

IGA ist zudem gern innerhalb von Funktionsdebatten in der Diskussion: Provisioning, Zertifizierung, SoD, Requests. In der Praxis entscheidet jedoch die Reichweite. Eine Plattform kann perfekte Workflows liefern und trotzdem am Risiko vorbeisteuern, wenn die gefährlichsten Zugriffe unsichtbar bleiben.

Vollwertiges IGA zielt deshalb auf die Rolle als Steuerungsebene. Es bietet eine konsolidierte Sicht auf Identitäten und Rechte, nachvollziehbare Begründungen ("warum hat dieses Konto Zugriff?") und belastbare, auditierbare Wege zur Korrektur. Die entscheidende Frage ist nicht, ob Prozesse irgendwie laufen, sondern ob sie für die kritischen Systeme laufen. Konkret zeigt sich der Unterschied an drei Punkten:

• Reichweite der Integration: Nicht nur Standard-SaaS, sondern auch Cloud-Kontrollebenen, Legacy-Systeme, Dev-/Data-Stacks – inklusive der dort agierenden Maschinen- und Dienstidentitäten.
• Erklärbarkeit und Nachweis: Zugriff muss nicht nur existieren, sondern begründet, genehmigt und historisch rekonstruierbar sein. Er muss einen durchgängigen Audit-Trail haben und sollte kein Puzzle aus Logfiles sein.
• Abhilfe mit System: Erkenntnis und Korrektur gehören zusammen. Risiken müssen erkannt und priorisiert werden und sich anschließend gezielt über kontrollierte Workflows beheben lassen, statt durch Ad-hoc-Aktionen, die später niemand mehr schlüssig erklären kann.

Incident Response macht Governance-Lücken sichtbar

Spätestens wenn ein Sicherheitsvorfall auftritt, zählt nicht, wie viele Zertifizierungen pünktlich waren, sondern wie schnell belastbare Antworten kommen. Ein typischer Fall ist Ransomware, die über kompromittierte Zugangsdaten eines Dienstkontos eingeschleust wird. Das Konto wurde vor Jahren eingerichtet, nie mehr sauber überprüft, hat aber breit gestreute Rechte in ERP-nahen Prozessen oder Datenablagen. Dann braucht Incident Response sofort Klarheit: Wo hat dieses Konto überall Zugriff? Welche vergleichbaren Konten existieren? Was wurde wann geändert? Was lässt sich schnell abschalten, ohne den Betrieb zu bremsen?

Wenn IGA nur den "angebundenen Teil" analysieren kann, bleibt der Rest manuelle Detektivarbeit. Und genau dann zeigt sich, was "Light" im Ernstfall bedeutet: Dass Governance keine umfassende Sicherheitsfähigkeit darstellt, sondern Scheinsicherheit mit blinden Flecken bedeutet.

Die Frage nach Light- oder Vollversion übersieht das zentrale Problem

Light IGA kann sinnvoll sein, wo IT-Landschaften überschaubar sind, regulatorischer Druck gering ist und Standardanwendungen dominieren. In großen Organisationen ist die Realität jedoch gespickt mit Multicloud, Schatten-IT, Legacy, DevOps-Toolchains und Maschinenidentitäten. Genau dort wachsen Risiken und genau dort endet Light IGA leider oft zuerst.

Der Praxistest ist unangenehm, aber eindeutig. Sicherheitsverantwortliche müssen dabei zwei zentrale Fragen stellen: Ist kurzfristig belegbar, wer auf ein kritisches System zugreifen kann und warum? Und können wir nachweisen, wie schnell Zugriffe entzogen werden können, ohne Chaos zu stiften?
Wenn diese Antworten für die wichtigsten Systeme fehlen, hat das IGA-Programm sein Ziel verfehlt, egal wie rund die Standardprozesse aussehen. Die Frage ist nicht, welche Plattform mehr Funktionen anbietet. Die Frage ist, ob Governance dort stattfindet, wo Risiko entsteht.

Fazit – Reichweite schlägt Einfachheit

Light IGA deckt das Greifbare ab, doch vollwertiges IGA sichert das Relevante. In modernen Hybridszenarien aus Multicloud, Legacy und Maschinenidentitäten bietet ein abgespeckter Ansatz oft nur trügerische Scheinsicherheit. Entscheidend ist nicht die Qualität der Standardprozesse, sondern ob die kritischen Risiken tatsächlich abgedeckt sind.

Über den Autor: Thomas Müller-Martin ist Field Strategist DACH bei Omada Identity