Single Sign-on (Einmalanmeldung, SSO) hat ein echtes Problem gelöst: das Passwort-Chaos. Aber viel zu viele Teams sind an diesem Punkt stehen geblieben und gehen davon aus, sie hätten damit "Identität erledigt". In Wirklichkeit ist SSO nur die Eingangstür; Identity Governance ist alles, was vor und nach dem Durchschreiten dieser Tür passiert.

Dieser Beitrag erklärt den entscheidenden Unterschied zwischen SSO und Identity Governance, warum SSO allein Risiken und Handarbeit erzeugt und wie ein moderner, automatisierter Governance-Stack tatsächlich aussieht.

Zentrale Erkenntnisse auf einen Blick

  • SSO zentralisiert die Anmeldung, automatisiert aber typischerweise nur einen kleineren Teil deiner Anwendungen - oft die rund 20 %, die moderne Protokolle wie SAML und SCIM unterstützen. Die übrigen 80 % der Zugriffe bleiben manuell und größtenteils unsichtbar.
  • Schlanke IT-Teams verbringen routinemäßig den Großteil ihrer Zeit mit Zugriffstickets, Onboarding/Offboarding und spontanen Berechtigungsänderungen, weil SSO weder Lebenszyklen, noch Berechtigungen oder Freigaben steuert.
  • Moderne Identity Governance kann manuelle Zugriffstickets um bis zu 80 % reduzieren, den vierteljährlichen Aufwand für Identity-Compliance um über 100 Stunden senken und etwa 30 % SaaS-Verschwendung beseitigen, indem ungenutzte Lizenzen zurückgeholt und unnötige Enterprise-Upgrades nur für "SCIM-Komfort" vermieden werden.
  • SSO kümmert sich überwiegend um menschliche Anmeldungen. Dienstkonten, Bots, CI/CD-Pipelines, geteilte Konten und OT-Systeme liegen meist außerhalb von SSO und benötigen eine eigene Governance, um Blindflecken zu vermeiden.
  • Der Identitäts-Stack der Zukunft kombiniert SSO mit Identity Governance, Identitätsautomatisierung und universellen Konnektoren, um eine einheitliche Sicht auf alle Identitäten und alle Anwendungen zu schaffen - menschlich und nicht-menschlich, SCIM-fähig und nicht-SCIM-fähig, Cloud und On-Premises.

Erkenntnis 1: SSO endet am Anmeldebildschirm

Verstehe, welches Problem SSO wirklich löst

SSO beantwortet eine enge, aber wichtige Frage: Wie authentifiziert sich dieser Benutzer gegenüber dieser Anwendung? Es zentralisiert die Anmeldung, erzwingt Mehrfaktor-Authentifizierung und verbessert die Nutzererfahrung, indem es Dutzende von Passwörtern durch einen Identitätsanbieter (IdP) wie Okta, Azure AD oder Google Workspace ersetzt.

In vielen Umgebungen schiebt SSO auch eine kleine Menge an Informationen nachgelagert weiter - Gruppenmitgliedschaften oder Basisattribute - und kann eine begrenzte Kontoprovisionierung übernehmen, sofern Anwendungen und Lizenzen SCIM unterstützen.

Aber SSO tut nicht:

  • Entscheiden, wer überhaupt Zugriff auf welche Anwendungen erhalten soll.
  • Rollen, Tätigkeitsprofile oder Trennungs-von-Aufgaben-Regeln modellieren.
  • Fein granulare Berechtigungen vergeben oder entziehen (zum Beispiel bestimmte Slack-Kanäle oder GitHub-Repositories).
  • Joiner/Mover/Leaver-Lebenszyklusereignisse über alle Systeme hinweg orchestrieren.
  • Lückenlose Prüfpfade bereitstellen, wer welchen Zugriff wann und aus welchem Grund genehmigt hat.

SSO so zu behandeln, als würde es all das leisten, ist der Grund, warum Organisationen still und leise in Identitätsspagat abrutschen: mehr Anwendungen, mehr Berechtigungen, mehr Ausnahmen - alles zusammengehalten durch Tickets und Tabellen.

Warum diese Lücke für Risiko und Betrieb so relevant ist

Wenn SSO deine faktische "Governance-Schicht" ist, tauchen schnell einige Muster auf:

  • Manuelle Provisionierung an allen Ecken. Die Personalabteilung eröffnet ein Ticket; die IT legt Konten an und weist Rollen von Hand in allen Anwendungen zu, die kein SCIM, keine APIs oder keine SSO-Integration haben.
  • Offboarding nach dem Prinzip Hoffnung. Das Deaktivieren eines Benutzers im SSO wird als "Aufgabe erledigt" betrachtet, obwohl Dutzende lokaler Konten in SaaS-Werkzeugen, Produktivsystemen und internen Diensten weiter existieren.
  • Überberechtigte Nutzer. Menschen sammeln im Laufe von Team- und Rollenwechseln immer mehr Zugriffe an; es gibt keinen systematischen Weg, Minimalprinzip umzusetzen oder nicht mehr benötigte Zugriffe konsequent zu entziehen.
  • Wackelige Audit-Story. Bei Zugriffskontrollen ziehst du Daten aus jeder Anwendung einzeln, führst sie in Tabellen zusammen und kannst trotzdem kaum sauber nachweisen, wer was genehmigt hat.

Aus Sicht von Sicherheit und Compliance ist das weder Identity Governance noch robuste Identitätssicherheit. Es ist eine zentrale Anmeldung, die auf einem fragmentierten, überwiegend manuellen Zugriffsmodell mit uneinheitlicher Richtliniendurchsetzung sitzt.

Identity Governance ist im Gegensatz dazu das Vorgehen und die Werkzeuglandschaft, die sicherstellt, dass die richtigen Identitäten - menschliche wie nicht-menschliche - zum richtigen Zeitpunkt den richtigen Zugriff auf die richtigen Ressourcen haben - mit vollständiger Nachvollziehbarkeit. SSO ist ein wichtiges Signal in diesem Bild, aber nicht das ganze Bild.

Erkenntnis 2: Governance bedeutet Lebenszyklus, Minimalprinzip und Abdeckung

Dem Identitätslebenszyklus folgen, nicht nur der Anmeldung

Ein einfacher Weg, die Grenzen von SSO zu erkennen, ist, den Identitätslebenszyklus durchzuspielen und zu fragen, wo tatsächlich Entscheidungen getroffen werden.

  1. Joiner (Onboarding).

    • SSO: Erstellt vielleicht in einigen Anwendungen automatisch ein Konto, wenn die Personalabteilung jemanden im Verzeichnis anlegt.
    • Governance: Definiert Grundausstattung an Zugriffen (was jede neue Person erhält), rollenbasierte Zugriffe (was bestimmte Funktionen wie Vertrieb oder Entwicklung erhalten) und Ausnahmen. Sie steuert die automatisierte Kontoprovisionierung über alle Anwendungen hinweg - auch ohne SCIM - und erzwingt Zugriffsanträge und Genehmigungsworkflows für sensible Berechtigungen.

  2. Mover (Rollen- oder Teamwechsel).

    • SSO: Aktualisiert Gruppenmitgliedschaften im Verzeichnis, lässt alte Zugriffe in nachgelagerten Systemen aber häufig unangetastet.
    • Governance: Wendet Zugriffsrichtlinien und Orchestrierungsregeln an, sodass Berechtigungen der alten Rolle entzogen und neue Berechtigungen vollständig vergeben werden. So verhindert sie Berechtigungsaufblähung und Verstöße gegen Trennungs-von-Aufgaben-Vorgaben.

  3. Leaver (Offboarding).

    • SSO: Deaktiviert die Anmeldung bei Anwendungen, die an den IdP angebunden sind.
    • Governance: Stellt sicher, dass Konten wirklich überall deprovisioniert werden - in SaaS-Diensten, internen Anwendungen, Cloud-Konten, OT-Systemen und produktiven Zugriffspfaden. Lizenzen werden zurückgeholt, Dienstkonten bei Bedarf neu zugeordnet und ein vollständiger Audit-Trail für Revisionssicherheit erzeugt.

Ohne automatisierte Lebenszyklus-Governance bleiben "Geisterzugriffe" bestehen, lange nachdem SSO-Konten geschlossen wurden - ein leiser, aber ernster Missstand im Identitätsrisikomanagement.

Nicht-menschliche Identitäten und SaaS-Governance einbeziehen

Klassisches SSO ist im Kern auf Menschen ausgerichtet. Moderne Umgebungen sind jedoch voller nicht-menschlicher Identitäten:

  • Dienstkonten und gemeinsame Postfächer.
  • Bots, Robotergestützte Prozessautomatisierung und KI-Agenten.
  • CI/CD-Pipelines und Build-Server.
  • Datenbanknutzer, API-Schlüssel und Integrationsnutzer.
  • OT- und Produktionszugriffskonten in Werken, Lagern oder Rechenzentren.

Die meisten davon authentifizieren sich nicht über browserbasiertes SSO. Gleichzeitig verfügen sie oft über weitreichendere Berechtigungen als normale Nutzer.

Identity Governance holt diese Identitäten in dieselbe einheitliche Sicht wie deine Mitarbeitenden. Sie bietet dir:

  • Ein kanonisches Verzeichnis aller Identitäten - Mensch und Maschine.
  • Einheitliche Zugriffsrichtlinien und Genehmigungen für besonders riskante Berechtigungen.
  • Prüfpfade dazu, wer Dienstkonten und Geheimnisse erstellt, rotiert oder deaktiviert hat.
  • Transparenz, wo nicht-menschliche Identitäten auf sensible Daten, Cloud-Ressourcen oder OT-Systeme zugreifen.

Auf der SaaS-Seite verknüpft Governance Berechtigungen mit Kosten. Wenn du genau weißt, wer in welcher Anwendung welche Lizenz hat - und warum - kannst du die Rückgewinnung von Lizenzen automatisieren, das Minimalprinzip durchsetzen und vermeiden, für Enterprise-Pakete nur deshalb zu zahlen, um SCIM-Unterstützung zu erhalten.

Das ist gelebte SaaS-Governance: Zugriff, Ausgaben und Sicherheit über deinen Anwendungsbestand hinweg miteinander in Einklang bringen, statt sie als drei getrennte Probleme zu behandeln.

Erkenntnis 3: Die reine SSO-Strategie bricht bei Skalierung zusammen

Erkenne die Symptome, dass SSO überdehnt wird

Wenn du prüfen willst, ob deine Organisation SSO heimlich als Ersatz für Governance benutzt, halte Ausschau nach diesen Symptomen:

  • Ticket-Hölle. Die IT verbringt den Großteil der Woche mit Zugriffsanfragen, Onboarding/Offboarding und Berechtigungsänderungen statt mit Projekten.
  • Tabellengetriebene Zugriffe. Die "Wahrheitsquelle" dafür, wer welche Berechtigungen haben sollte, steckt in Tabellen, Wikis oder in den Köpfen Einzelner.
  • Uneinheitliches Offboarding. Jeder Austritt löst eine Checkliste aus, die nie ganz vollständig ist - insbesondere bei Nischen- oder Altsystemen.
  • Unklare Produktionszugriffe. Niemand kann schnell beantworten, wer Admin- oder Produktionszugriff auf Cloud-Konten, Datenbanken oder OT-Systeme hat.
  • Schmerzhafte Audits. Jede Prüfphase bedeutet Exporte aus Dutzenden Werkzeugen, manuelle Zusammenführung von Identitäten und hinterherlaufen wegen Genehmigungen.

Das sind keine SSO-Probleme. Das sind Governance-Probleme, die SSO nie lösen sollte.

Die Kosten in Risiko, Zeit und Geld messbar machen

Die Auswirkungen zeigen sich an drei Stellen:

  1. Sicherheit und Risiko.
    Überberechtigte Nutzer, verwaiste Konten und unverwaltete nicht-menschliche Identitäten gehören zu den häufigsten Pfaden zu Datenverlust und Produktionsstörungen. Ohne zentrale Richtliniendurchsetzung und laufende Überprüfung bleibt Identitätssicherheit eher Schlagwort als wirksame Kontrollinstanz.

  2. Operative Last für schlanke Teams.
    In einem typischen Unternehmen mit 50 bis 2.000 Personen und kleinem IT-Team kann manuelle Provisionierung und Bearbeitung von Zugriffsanfragen leicht den Großteil der Kapazität verschlingen. Teams, die echte Identitätsautomatisierung und Governance einführen, reduzieren manuelle Zugriffstickets regelmäßig um etwa 80 % und gewinnen damit wöchentlich ganze Arbeitstage für Infrastruktur, Sicherheit und strategische Themen.

  3. Compliance und Softwareausgaben.
    Manuelle Benutzerzugriffsprüfungen können ein Viertel der Arbeitszeit einer Person pro Quartal binden. Wenn Zugriffsprüfungen, Prüfpfade und Nachweise automatisiert sind, werden sie zum Hintergrundprozess statt zum flächendeckenden Feuerwehreinsatz. Gleichzeitig senkt bessere SaaS-Governance - inklusive automatischer Lizenzrückgewinnung - die Softwarekosten häufig um rund 30 %, ohne legitime Nutzung anzutasten. Das erleichtert zudem die Erfüllung regulatorischer, datenschutzbezogener und datensouveränitätsbezogener Vorgaben.

In Summe ist der ROI für den Schritt über "nur SSO" hinaus klar: weniger Risiko, weniger Mühsal, weniger Verschwendung.

Erkenntnis 4: So sieht ein moderner SSO- plus Governance-Stack aus

Behandle SSO als Eingangstür, nicht als ganzes Haus

Eine moderne Identitätsarchitektur trennt Verantwortlichkeiten klar:

  1. SSO-/IdP-Schicht.
    Kümmert sich um Authentifizierung, Mehrfaktor-Authentifizierung und Sitzungsverwaltung. Bietet ein zentrales Konto pro Person, zentrale Richtlinien für die Anmeldung und Integrationen mit möglichst vielen Anwendungen.

  2. Identity-Governance-Schicht.
    Dient als Richtlinien- und Orchestrierungsgehirn. Sie modelliert Rollen und Zugriffsrichtlinien, führt Joiner/Mover/Leaver-Workflows aus, verwaltet Zugriffsanträge und Genehmigungen, setzt das Minimalprinzip durch und liefert revisionssichere Nachweise.

  3. Konnektor- und Automatisierungsschicht.
    Schließt Abdeckungslücken, indem sie Konten in allen Anwendungen bereitstellt und entfernt - auch ohne SCIM oder leistungsfähige APIs - sowie in Infrastruktur, OT-Systemen und für nicht-menschliche Identitäten. Hier kommen universelle Konnektoren, SCIM-Unterstützung, wo verfügbar, und Workflow-Automatisierung zusammen.

In diesem Modell bleibt SSO klar in seiner Rolle: Es weist Identitäten nach und stellt Sitzungen her. Governance verantwortet die Frage, "wer soll was haben" in deiner gesamten Umgebung. Automatisierung stellt sicher, dass Realität und Richtlinie übereinstimmen.

Gemeinsam bilden diese Schichten das Rückgrat deiner Strategien für Identitätsverwaltung, Cloud-Governance und OT-Sicherheit. Mit wachsender Reife kannst du adaptive Zugriffs- und Sicherheitskontrollen auf Governance-Signale aufsetzen und mithilfe von Kontext und Risiko entscheiden, wann Authentifizierung verschärft oder Zugriff eingeschränkt werden sollte.

Praktische Schritte über "nur SSO" hinaus

Du brauchst kein sechsmonatiges Programm, um SSO und Governance zu entflechten. Ein pragmatischer Ansatz sieht so aus:

  1. Bestandsaufnahme deiner Identitätslandschaft.
    Liste alle Anwendungen, Infrastrukturen und OT-Systeme auf. Halte bei jedem fest, ob es hinter SSO liegt, wie Konten erstellt werden und wie sie entfernt werden.

  2. Menschliche und nicht-menschliche Identitäten kartieren.
    Erfasse Dienstkonten, Integrationsnutzer, geteilte Konten und Bots ebenso wie Mitarbeitende und externe Kräfte. Genau hier verstecken sich viele Blindflecken.

  3. Zielrichtlinien definieren, nicht nur Werkzeuge.
    Lege fest, wie "guter" Zustand aussieht: zum Beispiel alle Joiner erhalten am ersten Tag definierte Grundzugriffe; alle Mover lösen eine automatische Neuausrichtung der Zugriffe aus; alle Leaver sind innerhalb weniger Stunden vollständig deprovisioniert; Produktionszugriffe erfolgen bedarfsgerecht und genehmigt.

  4. Zuerst die wirkungsvollsten Abläufe automatisieren.
    Beginne mit den wenigen Anwendungen und Systemen, die die meisten Tickets erzeugen oder das höchste Risiko darstellen (häufig Personalwesen, Zusammenarbeit, Quellcode und Produktionszugriffe). Binde sie in deine Governance-Workflows ein, sodass Kontoprovisionierung, Zugriffsänderungen und Offboarding richtliniengesteuert laufen.

  5. Mit dem bestehenden SSO integrieren, nicht es ersetzen.
    Dein IdP bleibt der zentrale Punkt für Authentifizierung. Governance sollte daneben stehen, Identitätsdaten konsumieren, Zugriffsentscheidungen treffen und Automatisierung steuern - auch für Systeme, die nie native SSO- oder SCIM-Unterstützung bieten werden. Achte bei der Bewertung von Plattformen auf saubere Okta-Integration und vergleichbare Unterstützung für dein aktuelles SSO.

  6. Messen und nachsteuern.
    Verfolge Kennzahlen wie Volumen manueller Tickets, Zeit bis zum Onboarding, Zeit bis zum Offboarding, Audit-Feststellungen und Auslastung von SaaS-Lizenzen. Nutze diese Werte, um den ROI sichtbar zu machen und gezielt zu entscheiden, wo du Automatisierung als Nächstes ausbaust.

Mit der Zeit verwandelt dieser Ansatz Identität von einem Flickenteppich aus Anmeldungen und Ad-hoc-Prozessen in ein kohärentes System: SSO für die Anmeldung, Governance für Entscheidungen und Aufsicht, Automatisierung für die Umsetzung.

Fazit: SSO ist notwendig - aber bei Weitem nicht ausreichend

SSO war ein großer Schritt nach vorn für Benutzerfreundlichkeit und Basissicherheit. "Wir haben SSO" gleichzusetzen mit "wir haben Identity Governance" ist jedoch der Weg in Identitätsspagat, Handarbeit und vermeidbare Risiken.

Governance ist die Arbeit, zu entscheiden und durchzusetzen, wer unter welchen Bedingungen wie lange worauf zugreifen darf - über alle Anwendungen, Umgebungen und Identitätstypen hinweg. SSO ist ein wichtiger Teil dieser Geschichte, aber nicht die gesamte Handlung.

Wenn du die Symptome einer reinen SSO-Strategie erkennst - Ticketflut, Offboarding nach dem Prinzip Hoffnung, schmerzhafte Audits, unklare Sicht auf Produktionszugriffe - ist es Zeit, dein mentales Modell zu überarbeiten. Ergänze deinen IdP um eine Governance- und Automatisierungsschicht, die deinen gesamten Stack abdeckt, Minimalprinzip standardmäßig durchsetzt und dir in Echtzeit revisionssichere Antworten auf die Frage "wer hat worauf Zugriff" liefert.

So sieht Identity Governance in der Praxis aus: nicht noch ein weiterer Anmeldebildschirm, sondern eine einfachere, schnellere und vollständigere Art, Zugriffe für deine gesamte Organisation zu steuern.

Häufig gestellte Fragen

Ist SSO nicht Teil von Identity Governance?

Doch. SSO und dein Identitätsanbieter sind grundlegende Bausteine deines Identitäts-Stacks. Sie zentralisieren die Authentifizierung, reduzieren Passwortwildwuchs und geben dir einen konsistenten Ort für Mehrfaktor-Authentifizierung und grundlegende Richtlinien.

Aber Governance hat einen größeren Umfang: Lebenszyklusmanagement, Zugriffsrichtlinien, Genehmigungen, Zertifizierungen, Identitätsrisikomanagement und die kontinuierliche Angleichung von Richtlinie und Realität. Die richtige Denke ist "SSO plus Governance", nicht "SSO statt Governance".

Woher weiß ich, dass wir aus dem reinen SSO-Ansatz herausgewachsen sind?

Typische Signale sind:

  • Die IT geht in Zugriffsanfragen, Onboarding/Offboarding und Berechtigungsänderungen unter.
  • Ihr seid auf Tabellen oder informelles Erfahrungswissen angewiesen, um zu wissen, wer was haben sollte.
  • Offboarding erfordert manuelle Checklisten und lässt euch trotzdem unsicher zurück.
  • Zugriffsprüfungen sind langsam, mühsam und oft unvollständig.
  • Ihr könnt die Frage "wer hat Admin- oder Produktionszugriff auf dieses System" nicht schnell beantworten.

Treffen mehrere dieser Punkte auf euch zu, nutzt ihr SSO, um eine Governance-Lücke zu stopfen - und es ist Zeit, die Ursache anzugehen.

Brauchen kleinere Unternehmen wirklich Identity Governance?

Für sehr kleine Teams mit wenigen Anwendungen können manuelle Prozesse eine Zeit lang funktionieren. Aber sobald ihr einige Dutzend Personen und einige Dutzend Anwendungen überschreitet, geht die Rechnung nicht mehr auf. Tickets stapeln sich, Offboarding wird riskanter und Audits (formelle oder kundenseitige) werden immer schwieriger.

Moderne Governance-Werkzeuge sind für schlanke IT-Teams gedacht, nicht nur für Großunternehmen. Ziel ist nicht mehr Bürokratie, sondern weniger Handarbeit und klarere Kontrolle über Zugriffe, während ihr wachst.

Und was ist mit nicht-menschlichen Identitäten und Dienstkonten - gehören die in die Governance?

Unbedingt. Nicht-menschliche Identitäten verfügen oft über sehr mächtige Berechtigungen: Datenbankzugriffe, Bereitstellungsrechte, Integrationsschlüssel und mehr. Sie aus der Governance auszuklammern, schafft einige der größten Blindflecken in deiner Umgebung.

Du solltest an einem Ort sehen können, welche Dienstkonten es gibt und was sie tun dürfen; wo sinnvoll dieselben Zugriffsrichtlinien und Genehmigungen wie für Menschen anwenden; und vollständige Prüfpfade über Änderungen pflegen. SSO allein liefert all das nicht.

Wo sollten wir beginnen, wenn wir bereits Okta, Azure AD oder einen anderen SSO-Anbieter haben?

Behalte dein bestehendes SSO - es ist ein zentraler Baustein. Gehe dann wie folgt vor:

  1. Verbinde dein Personalwesen-System und dein SSO mit einer Identity-Governance- und Automatisierungsschicht.
  2. Beginne damit, Joiner/Mover/Leaver-Workflows für eine kleine Anzahl besonders wirkungsstarker Anwendungen zu automatisieren.
  3. Zentralisiere Zugriffsanträge und Genehmigungen, sodass Führungskräfte Zugriffe an einem Ort freigeben und die IT an einem Ort Richtlinien einsehen und durchsetzen kann.
  4. Erweitere die Abdeckung schrittweise auf nicht-SCIM-Anwendungen, Infrastruktur, OT-Systeme und nicht-menschliche Identitäten.

Das Zielbild ist nicht, SSO zu ersetzen, sondern es durch ein Governance-System zu ergänzen, das der tatsächlichen Komplexität deiner Umgebung endlich gerecht wird.