Ihr Vorstand hat die Zero Trust Initiative abgenickt. Ihr habt MFA ausgerollt. Ihr habt auf SSO konsolidiert. Das Login-Dashboard ist aufgeräumt und die Präsentation trägt stolz den Titel "Zero Trust Architecture".
Jetzt die eigentliche Frage: Wer hat Zugriff worauf - genau jetzt - in jeder Applikation eures Stacks?
Wenn die ehrliche Antwort mehrere Tage voller Excel-Exports, Screenshots und Nachfragen bei App-Ownern braucht, habt ihr kein Zero Trust. Ihr habt null Sichtbarkeit - verpackt in Zero-Trust-Branding.
Das ist kein Vorwurf an die Teams, die das gebaut haben. Es ist ein strukturelles Problem darin, wie Zero Trust verkauft, implementiert und gemessen wird. Authentifizierung ist der sichtbare, auslieferbare Teil des Frameworks. Identity Governance ist der härtere, weniger glamouröse Teil, den die meisten Implementierungen leise überspringen.
Angreifer haben das längst verstanden. Sie brechen nicht mehr an der Haustür das Schloss auf. Sie laufen durch den Seiteneingang, den ihr offengelassen habt.
Was Zero Trust wirklich verlangt (und wo die meisten Programme aufhören)
Zero Trust Architecture basiert auf einem einfachen Prinzip: Kein User, kein Device und kein Workload wird per se vertraut - völlig unabhängig vom Netzwerksegment. Das System muss jede Zugriffsanfrage authentifizieren, autorisieren und validieren, bevor irgendetwas passiert.
NIST SP 800-207 beschreibt Zero Trust als Ende-zu-Ende-Ansatz, der Identity, Credentials, Access Management, Endpoints und Hosting-Umgebungen umfasst. Das ist der Standard. Das ist das, worauf ihr euch eingelassen habt.
Und das ist das, was die meisten Implementierungen am Ende liefern: MFA beim Login, SSO für die Apps, die es unterstützen, plus ein Netzwerksegmentierungs-Projekt, das sich seit 18 Monaten "in Phase zwei" befindet.
Die meisten ZTA-Rollouts fokussieren sich auf menschliche Zugriffe. Sie ergänzen MFA, führen SSO ein und segmentieren Netzwerke. Das ist wichtig - lässt aber nicht-menschliche Identitäten weitgehend außen vor.
Und das noch bevor wir über das eigentliche Coverage-Problem sprechen.
Das Coverage-Problem, über das niemand im Zero-Trust-Briefing spricht
Die wenigsten Enterprise-Stacks sind flächendeckend SCIM-fähig. Ein typisches, SaaS-lastiges Unternehmen betreibt Dutzende Tools - GitHub, Notion, Figma, Linear, Jira, Slack, Legacy-On-Prem-Systeme, OT-Umgebungen, interne Eigenentwicklungen - und nur ein Teil davon unterstützt SCIM im Standard-Lizenzmodell.
Wenn ihr SSO + SCIM als Identity-Layer ausrollt, automatisiert ihr den Zugriff für diese Minderheit. Die übrigen 60-80 % eurer Applikationslandschaft werden weiter per Tickets, Excel-Listen und Ad-hoc-Skripten verwaltet. Das ist keine kleine Governance-Lücke. Das ist die Mehrheit eurer Angriffsfläche - außerhalb eures Control-Planes.
Je größer Identitätslandschaften werden, desto schwerer wird es, Sichtbarkeit und Kontrolle zu behalten. User, Rollen, Applikationen und Berechtigungen verteilen sich auf verschiedenste Systeme. Für Security-Teams wird es extrem schwierig nachzuvollziehen, wer wann worauf Zugriff hat - insbesondere in größeren Organisationen.
Zero Trust sagt: "Never trust, always verify." Aber ihr könnt nur verifizieren, was ihr sehen könnt. Wenn 70 % eurer Apps nicht an eure Governance-Schicht angebunden sind, verifiziert ihr nicht - ihr geht ins Blaue davon aus.
Der Zero-Trust-Realitätscheck: NIST SP 800 207 definiert Zero Trust als einen End-to-End-Ansatz, der Identität, Anmeldeinformationen, Zugriffsverwaltung, Endpunkte und Hosting-Umgebungen umfasst. Es ist per Definition kein Framework, das sich ausschließlich auf Authentifizierung beschränkt. Wenn Ihr ZT-Programm am Anmeldebildschirm anhält, entsprechen Sie nicht dem Framework, von dem Sie glauben, dass Sie es implementiert haben.
Die Authentifizierungs-Illusion: Warum verifizierte Logins noch keine kontrollierten Zugriffe bedeuten
Die unangenehme Wahrheit über reine "Authentication-first"-Zero-Trust-Implementierungen lautet: Eine verifizierte Identität ist noch keine governte Identität.
Wenn ein User sich per SSO mit MFA anmeldet, beantwortet ihr genau eine Frage: Ist diese Person in diesem Moment die, für die sie sich ausgibt? Ihr beantwortet aber nicht:
- Welche Berechtigungen hat diese Person in jeder einzelnen App, auf die sie zugreift?
- Passen diese Berechtigungen überhaupt noch zu ihrer aktuellen Rolle?
- Haben sich diese Berechtigungen seit der ursprünglichen Vergabe verändert?
- Welche Zugriffe hat diese Person, die sie längst nicht mehr haben sollte?
- Welche Zugriffe sind aus einer früheren Rolle, aus alten Projekten oder Teams noch aktiv?
Das sind Identity-Governance-Fragen. Die liegen komplett außerhalb der Authentifizierungsschicht.
Identity Security hat alle anderen Risiken als Top-Sorge in Cloud-Umgebungen überholt. Laut dem "State of Cloud and AI Security 2025"-Report der CSA sind unsichere Identitäten und riskante Berechtigungen das Sicherheitsrisiko Nummer eins in der Cloud.
Die meisten Organisationen messen ihr Zero-Trust-Programm aber so: Der häufigste Identity-und-Access-Management-KPI ist die Quote der MFA- oder SSO-Nutzung (42 %). Nur wenige messen tiefere Indikatoren wie Missbrauch von Berechtigungen, Zugriffsanomalien oder den Missbrauch nicht-menschlicher Identitäten.
Ihr messt die Haustür - während die Hinterfenster offenstehen.
Wenn Angreifer Authentifizierung komplett umgehen
Die Lage wird noch kritischer, wenn man anschaut, wie moderne Angriffe tatsächlich ablaufen. Selbst mit MFA umgehen Angreifer die Authentifizierung, indem sie aktive Websessions kapern. Gestohlene Session-Cookies, missbrauchte OAuth-Tokens und Credential-Stuffing über Infostealer-Malware brauchen kein Passwort - sie nutzen den bestehenden, bereits authentifizierten Zugriff einer Identität.
Gestohlene Zugangsdaten machten 2025 rund 22 % der bekannten Initial-Access-Vektoren aus - der häufigste Einstiegspunkt für Angreifer in ein Netzwerk. Einmal drin, erlauben übermäßige Berechtigungen und mangelnde Sichtbarkeit eine unbemerkte Privilegieneskalation.
Genau dieser letzte Punkt ist das Problem. "Unbemerkt eskalieren" passiert, weil Berechtigungen nie richtig governed wurden - sie wurden irgendwann einmal vergeben und dann nie wieder überprüft. Authentifizierung bringt den Angreifer durch die Tür. Bestehender, ungovernter Zugriff erledigt den Rest.
Die drei Governance-Lücken in eurer Zero Trust Architecture
Lücke 1: Nicht-SCIM-Apps - die Blind Spots, die euer SSO-Dashboard versteckt
Jeder Anbieter behauptet, seine Plattform "integriert sich mit Tausenden von Apps". Gemeint ist meistens: Sie können die Authentifizierung zu diesen Apps vermitteln. Damit ist nicht gemeint, dass sie Zugriffe innerhalb dieser Apps govern, automatisch die richtigen Berechtigungen provisionieren oder automatisch deprovisionieren, wenn jemand das Unternehmen verlässt.
Ohne starke Governance wird die Flexibilität von JWTs zum Risiko. Wenn Tokens als verteilte Policy-Caches mit langen Laufzeiten fungieren, seid ihr wieder bei statischen Credentials - nur in moderner Verpackung.
Die Apps ohne SCIM-Support - und das sind viele, vor allem außerhalb von Enterprise-Pricing-Tiers - haben keinen automatisierten Deprovisioning-Hook. Wenn jemand euer Unternehmen verlässt und ihr die Person in Okta oder Entra deaktiviert, bleibt der Zugriff auf diese Apps aktiv. Die Person kann sich weiterhin mit einem alten, nie rotierten Passwort direkt einloggen.
2025 betrieb ein durchschnittliches Enterprise etwa 275 SaaS-Applikationen im Technologie-Stack. Die Governance-Schicht der meisten Zero-Trust-Implementierungen deckt nur einen Bruchteil davon ab.
Lücke 2: Das Problem der verwaisten Identitäten
Inaktive Konten sind riskant, weil Angreifer - oder auch Insider - sie nutzen können, um sich lateral zu bewegen, sensible Daten zu erreichen und Security-Kontrollen zu umgehen. Sie sind das Ergebnis von unvollständigem Offboarding, Rollenwechseln, Shadow IT sowie alten Test- und Dienstleister-Accounts.
Verwaiste Konten sind kein "Hygiene-Thema". Sie sind eine direkte Folge davon, Authentifizierung mit Governance zu verwechseln. Ihr habt die SSO-Session entfernt. Ihr habt aber nicht den lokalen App-Account gelöscht. Die Identität existiert weiter, sie hat Berechtigungen - und niemand hat sie auf dem Radar.
Angreifer zielen bewusst auf inaktive Konten, weil sie selten auffallen - aber immer noch gültigen Zugriff auf sensible Systeme bieten.
91 % der Unternehmen meldeten im letzten Jahr einen Identity-bezogenen Sicherheitsvorfall - fast doppelt so viele wie im Jahr davor. Viele dieser Vorfälle führten auf Credentials und Berechtigungen zurück, von denen die Organisation gar nicht wusste, dass sie noch aktiv waren.
Lücke 3: Nicht-menschliche Identitäten - die am schnellsten wachsende Angriffsfläche
Service-Accounts. API-Keys. Credentials in CI/CD-Pipelines. KI-Agenten. Bots.
Diese Identitäten übersteigen die Zahl menschlicher User in den meisten modernen Umgebungen deutlich. Sie haben oft erhöhte Berechtigungen. Sie umgehen SSO. Sie werden nicht offboarded, wenn ein Projekt endet. Und sie tauchen in den meisten Zero-Trust-Programmen praktisch nicht auf.
2025 haben AI-bezogene Vorfälle - Shadow AI, Plugin/API-Chains - die Messlatte für Zero Trust Security angehoben: Autorisierung pro Request muss auch Datenflüsse in Modelle und Agenten abdecken, nicht nur menschliche User. Nur wenige Teams hatten reife Zugriffssteuerungen für AI, entsprechend hoch waren die Schadenkosten.
Ein Zero-Trust-Programm, das nicht-menschliche Identitäten nicht governed, deckt im besten Fall die Hälfte der Identitäten in der Umgebung ab. Die andere Hälfte läuft unbeaufsichtigt - bis etwas schiefgeht.
Wie echtes Zero Trust aussieht: Authentifizierung + kontinuierliche Governance
"Gutes" Identity-und-Access-Management in einer Zero-Trust-Sicherheitsarchitektur bedeutet, über reine MFA und SSO hinauszugehen hin zu einem adaptiven, identity-first Control-Plane, der jede menschliche und nicht-menschliche Identität im gesamten Umfeld governed. In der Praxis startet das mit einer Single Source of Truth für Identitäten, starker Lifecycle-Automation für Joiner-Mover-Leaver und der konsequenten Abschaffung gemeinsamer oder rein lokaler Accounts, wo immer möglich. Zugriffe werden nach klar definierten Rollen, Business-Kontext und Least-Privilege-Policies vergeben - mit zeitbasiertem Just-in-Time-Elevating für sensible Aufgaben anstelle dauerhafter Adminrechte.
Das ist der Anspruch. Was braucht es, um die Lücke wirklich zu schließen?
Komplette App-Abdeckung. Nicht nur SCIM-fähige Apps. Nicht nur Apps mit teuren Enterprise-APIs. Jede Applikation in eurem Stack - inklusive der Tools, die euer SSO nicht berühren kann - muss an eure Governance-Schicht angebunden sein. Das heißt: Konnektoren, die unabhängig von SCIM funktionieren und auf feingranularer Berechtigungsebene arbeiten - nicht nur auf Gruppenebene.
Lifecycle-Automation, die den kompletten Hire-to-Retire-Prozess abdeckt. Wenn jemand startet, wird der Zugriff automatisch provisioniert. Wenn sich Rollen ändern, werden Berechtigungen automatisch angepasst. Wenn jemand geht, wird der Zugriff überall entzogen - nicht nur im IdP. Keine teilweisen Offboardings. Keine verwaisten Konten.
Kontinuierliche, Echtzeit-Zugriffsüberwachung und Access-Reviews - statt quartalsweiser Excel-Orgien, die am Ende nur durchgewunken werden, weil Reviewer überlastet sind. Policy-Verletzungen, überprivilegierte Konten und schlafende Berechtigungen müssen in dem Moment auffallen, in dem sie entstehen - nicht im nächsten Audit.
Governance für nicht-menschliche Identitäten nach denselben Prinzipien wie für menschliche Identitäten. Service-Accounts bekommen Lifecycle-Policies. API-Keys bekommen Ablaufdatum und Rotation. KI-Agenten bekommen strikt eingegrenzten, least-privilege Zugriff mit vollständigem Audit-Trail.
Zero Trust bleibt im Kern an eine Idee gebunden: Zugriff muss sich kontinuierlich "verdient" werden, nicht dauerhaft vergeben sein. Was sich ändert, ist die Enforcement-Fläche. Policies folgen Identitäten und Workloads über hybride Infrastrukturen - sie enden nicht an der Firewall.
Der ehrliche CISO-Selbsttest
Nehmt euch drei Minuten und geht den folgenden Check durch. Das ist der echte Test, ob euer Zero-Trust-Programm Governance-Tiefe hat - oder "nur" Authentifizierungs-Coverage.
Wenn ihr unter 8 punktet, hat eure ZT-Architektur relevante Blind Spots. Das ist kein Intent-Versagen - es ist eine strukturelle Lücke, die viele Implementierungen teilen. Die Authentifizierungsschicht ist der sichtbare, leicht messbare Teil. Governance ist die härtere, weniger sichtbare Schicht darunter, die entscheidet, ob Zero Trust Security tatsächlich durchgesetzt wird.
Authentifizierung vs. Governance: Die Realität im direkten Vergleich
So sehen die beiden Modelle in der Praxis aus:
| Fähigkeit | ZT mit Authentifizierung nur (SSO + MFA) | ZT mit Identitätsverwaltung (Iden) |
|---|---|---|
| Überprüfen, wer sich anmeldet | ✅ Ja | ✅ Ja |
| Steuern, auf was sie innerhalb von Apps zugreifen | ❌ Nein | ✅ Ja - Kanal, Repo, Projektebene |
| Nicht-SCIM-/Legacy-Apps abdecken | ❌ Nein - Blindstelle | ✅ Ja - 175+ Apps, jeder Stack |
| Verwalten von nicht-menschlichen Identitäten (Bots, KI-Agenten, Service-Konten) | ❌ Nein | ✅ Ja - vollständiger Lebenszyklus |
| Erkennen von verwaisten und Zombie-Konten | ❌ Nein | ✅ Ja - kontinuierlich, in Echtzeit |
| Durchgehend das Prinzip der geringsten Privilegien durchsetzen | ❌ Nur regelmäßige Überprüfungen | ✅ In Echtzeit, richtliniengesteuert |
| Beantworte die Frage 'Wer hat gerade Zugriff auf was?' | ❌ Teilweise - SCIM-Apps nur | ✅ Ja - gesamter Stack |
| Auditierbare Zugriffsnachweise | ❌ Manuell, fragmentiert | ✅ Unveränderliche Protokolle, jederzeit verfügbar |
| Bereitstellungszeit | Monate | ~24 Stunden |
Der Unterschied zwischen linker und rechter Spalte ist der Unterschied zwischen "wir haben Zero Trust" und "wir können Zero Trust nachweisen". CISOs, die schon einmal eine Live-Prüfung oder forensische Analyse nach einem Incident durchlaufen haben, wissen sehr genau, in welcher Spalte sie stehen mussten.
Wie Iden die Governance-Lücke schließt
Iden ist gezielt für Organisationen gebaut, die SSO haben, aber keinen echten Governance-Layer darüber. Iden verbindet sich mit eurem gesamten Stack - nicht nur mit den SCIM-freundlichen Tools - und liefert vollständige, feingranulare Identity Governance über jede menschliche und nicht-menschliche Identität.
Wie das konkret aussieht:
- Universelle Konnektoren für 175+ Apps, inklusive solcher ohne SCIM oder API-Support. Kein Enterprise-Upgrade nötig, um genau die Tools zu automatisieren, die euer Team wirklich nutzt. Keine SCIM-Steuer.
- Feingranulare Kontrolle, die deutlich über SCIM-Gruppenzuweisungen hinausgeht - Channel-, Repo- und Projekt-Ebene, damit Offboarding wirklich vollständig ist, nicht halbgar.
- Automatisiertes Lifecycle-Management von Onboarding bis Offboarding - inklusive Rollenwechsel, Dienstleister-Zugriff und Governance für nicht-menschliche Identitäten. Alles policybasiert, ohne manuelle Zugriffstickets.
- Kontinuierliche Access Governance - keine punktuellen Reviews. Policy-Verletzungen, verwaiste Konten und überprovisionierte Zugriffe werden in Echtzeit erkannt und behoben.
- Unveränderliche Audit-Logs und eine zentrale Sicht ("Single Pane of Glass") über jede Identität, jedes Recht und jede Zugriffsentscheidung - damit die Frage "wer hat Zugriff worauf - genau jetzt?" eine belastbare Antwort hat und kein Fünf-Tage-Research-Projekt auslöst.
- Go-Live in etwa 24 Stunden, nicht in Monaten. Keine Systemintegratoren. Keine Sechs-Monats-Projekte. Gebaut für schlanke IT-Teams, die nicht auf "Phase zwei" warten können.
Mehr dazu, warum SSO-Tools nicht für Identity Governance gemacht sind und wie die Lücke zwischen Authentifizierung und Governance konkreten Risikoaufwand erzeugt. Und wenn ihr den größeren Kontext von Identity Governance - Vergangenheit, Gegenwart und die Lücken dazwischen - betrachtet, lest past and present of identity governance.
Was CISOs mitnehmen sollten
Zero Trust ist kein Produkt. Es ist keine reine Authentifizierungsstrategie. Es ist eine Sicherheitsstrategie, die verifizierte, kontinuierlich governte Zugriffe über eure komplette Umgebung verlangt - inklusive der Apps, die nie dafür gedacht waren, der Accounts, an deren Provisionierung sich niemand erinnert, und der nicht-menschlichen Identitäten, die im Hintergrund auf Autopilot laufen.
Die größte Fehlannahme ist, Zero Trust sei primär ein Netzwerk-Projekt. Bis 2030 wird Zero Trust primär ein Projekt für Identitäten, Endpoints und Datenkontrollen sein. Identität ist das neue Control Plane.
Wenn ihr die Frage "wer hat Zugriff worauf - genau jetzt - über jede App hinweg?" nicht beantworten könnt, ist das keine Reporting-Lücke. Es ist eine Sicherheitslücke. Und genau dort wird der nächste Breach starten.
Authentifizierung liefert euch eine verifizierte Identität an der Tür. Governance sorgt dafür, dass das gesamte Gebäude sicher bleibt, nachdem diese Identität eingetreten ist.
FAQ
Löst MFA nicht bereits das Zero-Trust-Authentifizierungsproblem?
MFA stärkt die Authentifizierung – aber sie deckt nur das Login-Ereignis ab. Sobald ein Benutzer authentifiziert ist, bestimmt MFA nicht, was er zugreifen kann, auf welchem Berechtigungsniveau und über welche Apps hinweg. Angreifer, die Sitzungscookies oder OAuth-Tokens stehlen, umgehen MFA vollständig und agieren mit den Berechtigungen, die diese Identität bereits innehat. MFA ist notwendig; sie ist jedoch nicht ausreichend für Zero Trust.
Wir verwenden Okta/Entra für SSO. Ermöglicht uns das nicht Zero Trust?
SSO zentralisiert die Authentifizierung und erzwingt MFA. Es regelt nicht, was Benutzer in jeder App tun können, deckt Apps ohne SCIM- oder API-Unterstützung nicht ab und verwaltet keine nicht-menschlichen Identitäten wie Servicekonten oder KI-Agenten. Im Durchschnitt automatisiert SSO nur 20–40% eines modernen SaaS-Stacks – der Rest Ihrer Apps bleibt ein Blindspot. SSO ist die Vordertür; Identitätsgovernance ist jeder Raum, jede Schublade und jeder Schrank im Gebäude.
Was bedeutet 'kontinuierliche Governance' in der Praxis tatsächlich?
Kontinuierliche Governance bedeutet, dass Ihre Identitätskontrollen in Echtzeit arbeiten – nicht nach einem vierteljährlichen Überprüfungsrhythmus. Der Zugriff wird jedes Mal gegen die aktuelle Richtlinie bewertet, nicht nur, wenn er gewährt wird. Wenn sich die Rolle eines Mitarbeiters ändert, aktualisieren sich Berechtigungen automatisch. Wenn jemand das Unternehmen verlässt, wird der Zugriff über alle Apps hinweg widerrufen – nicht nur bei SCIM-verbundenen. Verwaiste Konten, Richtlinienverstöße und überprovisionierte Berechtigungen werden sofort gemeldet und behoben, sobald sie auftreten, nicht Monate später bei einer Prüfung entdeckt.
Wie unterscheidet sich Iden von dem, was unser bestehendes SSO- oder IGA-Tool bereits tut?
Nicht-menschliche Identitäten umfassen Servicekonten, API-Schlüssel, Bots, CI/CD-Pipeline-Zugangsdaten und KI-Agenten. Diese Identitäten verfügen oft über erhöhte Berechtigungen, werden selten überprüft und umgehen SSO vollständig – was sie zu hochwertigen Zielen für Angreifer macht. Eine Zero-Trust-Architektur, die nur menschliche Logins regelt, ignoriert eine rasant wachsende Angriffsfläche. Iden verwaltet sowohl menschliche als auch nicht-menschliche Identitäten im gleichen, von Richtlinien getriebenen Lebenszyklusrahmenwerk.
Was sind 'Nicht-menschliche Identitäten' und warum sind sie wichtig für Zero Trust?
Nicht-menschliche Identitäten umfassen Servicekonten, API-Schlüssel, Bots, CI/CD-Pipeline-Zugangsdaten und KI-Agenten. Diese Identitäten besitzen oft erhöhte Berechtigungen, werden selten überprüft und umgehen SSO vollständig – was sie zu hochwertigen Zielen für Angreifer macht. Eine Zero-Trust-Architektur, die nur menschliche Logins regelt, ignoriert eine rasant wachsende Angriffsfläche. Iden verwaltet sowohl menschliche als auch nicht-menschliche Identitäten im gleichen, von Richtlinien getriebenen Lebenszyklusrahmenwerk.
