Hören Sie auf, Ihr SSO-Tool für Governance zu verbiegen - warum Single Sign-on niemals vollständige Identity Governance liefern wird

SSO und Identity Provider sind zum sichtbaren Gesicht des Identitätsmanagements geworden. Wer jedoch versucht, sein SSO in eine vollständige Identity-Governance-Lösung zu verwandeln, schafft Blindflecken, manuelle Arbeit und echte Sicherheitsrisiken. Dieser Artikel erklärt, wo SSO aufhört, wo Identity Governance beginnt und wie Sie ein Modell entwerfen, das wirklich Least Privilege, sauberes Offboarding und prüfungsreife Zugriffskontrolle ermöglicht.

Wichtigste Erkenntnisse auf einen Blick

  • Die meisten SSO-/IdP-Tools können nur Anwendungen automatisieren, die SAML/OIDC + SCIM unterstützen - typischerweise etwa 20 % eines modernen SaaS-Stacks. Die übrigen 80 % an Anwendungen, Systemen und nicht-menschlichen Identitäten werden manuell oder über fragile Skripte gesteuert.
  • Wenn SSO in Richtung Governance überdehnt wird, verbringen schlanke IT-Teams oft rund 60 % ihrer Zeit mit Zugriffsanfragen, Kontenbereitstellung und Offboarding statt mit strategischen Aufgaben wie Cloud-Governance, OT-Sicherheit oder Härtung des Produktionszugriffs.
  • Genau dort, wo SSO außen vor bleibt - nicht-SCIM-fähige SaaS-Tools, Legacy-Anwendungen, Datenbanken, CI/CD, Servicekonten, KI-Agenten - entstehen Identity Sprawl, Verstöße gegen Least Privilege und Prüfungslücken.
  • Teams, die auf eine spezialisierte Identity-Governance-Lösung mit echter Identitätsorchestrierung und Automatisierung über alle Anwendungen hinweg umsteigen, reduzieren manuelle Zugriffstickets typischerweise um etwa 80 % und gewinnen pro Quartal über 100 Stunden zurück, die zuvor in der Nachverfolgung von Audit-Trails und Nachweisen für Zugriffsüberprüfungen steckten.
  • Das nachhaltige Muster ist klar: SSO kümmert sich um Authentifizierung und adaptiven Zugriff beim Login; eine Governance-Schicht übernimmt fein granulare Berechtigungen, SaaS-Governance, Kontenbereitstellung und -entzug, Identitätsrisikomanagement und kontinuierliche Richtliniendurchsetzung.

Erkenntnis 1: SSO war nie dafür gebaut, Ihr Identity-Governance-System zu sein

Verstehen Sie, was Ihr SSO tatsächlich leistet

Ihr SSO bzw. IdP ist eine Authentifizierungsmaschine. Es ist hervorragend geeignet für:

  • Zentrale Anmeldung und Erzwingung von MFA
  • Aufbau einer primären Identität für jede Nutzerin und jeden Nutzer
  • Ausstellen von Token an Anwendungen über SAML oder OIDC
  • Zuweisung von Nutzenden zu Anwendungen oder Gruppen, teilweise mit grundlegender SCIM-Unterstützung für Kontenbereitstellung

Damit ist SSO ein Grundpfeiler der Identitätssicherheit und des adaptiven Zugriffs. Aber es macht SSO nicht zu einer vollwertigen Identity-Governance-Plattform.

Identity Governance beantwortet andere Fragen:

  • Wer hat Zugriff auf welche konkreten Ressourcen (nicht nur auf welche Anwendungen)?
  • Warum haben sie diesen Zugriff? Wer hat ihn unter welcher Zugriffsrichtlinie genehmigt?
  • Wann wurde dieser Zugriff zuletzt überprüft? Sollte er nach dem Least-Privilege-Prinzip überhaupt noch bestehen?
  • Was passiert, wenn sich ihre Rolle ändert oder sie das Unternehmen verlassen?

SSO sieht in der Regel eine Person, eine Menge an Gruppen und eine Liste von Anwendungen. Was es selten sieht, ist das vollständige Berechtigungsmodell innerhalb dieser Anwendungen: welche Slack-Kanäle, welche GitHub-Repositories, welche Produktivdatenbanken, welche Kundendatensätze. Das ist kein Designfehler - es ist schlicht nicht der Zweck, für den SSO gebaut wurde.

Was das für Ihre Governance-Strategie bedeutet

Wenn Sie von Ihrem SSO Identity Governance erwarten, werden Sie:

  • Gruppenmitgliedschaften als Stellvertreter für Berechtigungen verwenden, obwohl reale Berechtigungen tiefer liegen (Projekte, Repositories, Umgebungen, fein granulare Rollen)
  • Auf statische Gruppen setzen statt auf richtliniengesteuerte, kontextabhängige Entscheidungen
  • "Nutzer kann sich anmelden" mit "Nutzer sollte diese Zugriffsebene jetzt haben" verwechseln

Das Ergebnis ist Governance-Theater: Sie haben ein aufgeräumtes Dashboard für Logins, aber kein vollständiges Bild des Zugriffs. Least Privilege wird zum Wunschziel. Offboarding wird zur Checkliste mit viel Hoffnung. Identity-Compliance und Prüfungsreife werden zu manuellen Übungen in Tabellenkalkulationen.

Die Lösung besteht nicht darin, SSO noch stärker zu verbiegen. Die Lösung ist eine klare Trennlinie: SSO für Authentifizierung und grobe Zugriffszuteilung; Identity Governance für Berechtigungen, Lebenszyklus und Nachweise.

Erkenntnis 2: Das Abdeckungsproblem - SSO berührt nur einen Bruchteil Ihres Stacks

Machen Sie die 20-%-vs.-80-%-Realität in Ihrer Umgebung sichtbar

Die meisten Teams stellen bei einer Bestandsaufnahme ihres Stacks dasselbe Muster fest:

  • Eine Minderheit der Anwendungen hängt hinter SSO und unterstützt SCIM (oder Ähnliches) für die Kontenbereitstellung.
  • Ein langer Schwanz an SaaS-Anwendungen ist nur teilweise angebunden: Nutzende melden sich über SSO an, aber die Berechtigungen innerhalb der Anwendung werden weiterhin manuell verwaltet.
  • Eine große Menge an Systemen liegt komplett außerhalb von SSO: Datenbanken, Datenplattformen, interne Tools, On-Prem- und OT-Systeme, Zugriffswege in die Produktion, VPNs, Jump-Hosts.
  • Nicht-menschliche Identitäten - Servicekonten, Bots, CI/CD-Pipelines, Integrationen, KI-Agenten - umgehen SSO häufig vollständig und existieren als gemeinsame Passwörter oder Schlüssel.

Das ist die Abdeckungslücke. Ihr SSO-Dashboard wirkt wie eine einheitliche Konsole für Identitätsmanagement, ist aber in Wahrheit nur eine Konsole für Logins auf einem Teil der Systeme. Je stärker Sie wachsen, desto weniger repräsentativ wird es für den tatsächlichen Zugriff.

Warum Abdeckungslücken Least Privilege und Offboarding aushebeln

Least Privilege funktioniert nur, wenn Sie allen Zugriff sehen und steuern können:

  • Wenn 80 % Ihres Stacks über Tickets, Jira-Kommentare und Admin-Konsolen verwaltet werden, gibt es keinen konsistenten Weg, Zugriffsrichtlinien durchzusetzen.
  • Führungskräfte und Ressourcenverantwortliche können nicht einfach erkennen, wer Zugriff auf sensible Daten oder Produktivumgebungen hat, sodass vierteljährliche Überprüfungen zu reinen Abnickrunden oder Tabellenakrobatik verkommen.
  • Offboarding wird zu einem "hoffnungsbasierten" Prozess: Sie nehmen SSO-Zugriff und einige offensichtliche Konten weg, aber Dutzende von anwendungslokalen Konten, geteilten Logins und Servicekonten bleiben bestehen.

Identitätsrisikomanagement wird damit reaktiv. Sie entdecken verwaiste Konten erst in einer Prüfung. Sie merken, dass ein ehemaliger externer Mitarbeitender noch Zugriff auf ein zentrales SaaS-Tool hat, wenn etwas schiefgeht. Sie stellen fest, dass eine nicht-menschliche Identität deutlich mehr Berechtigungen hat, als Sie jemals einer Person geben würden.

Nichts davon lässt sich durch zusätzliche Gruppen in SSO beheben. Sie brauchen Governance, die auch folgende Bereiche erreicht:

  • Nicht-SCIM-fähige SaaS-Anwendungen mit tiefen, anwendungsinternen Berechtigungen
  • Interne Tools und Legacy-Systeme
  • Servicekonten, Automatisierungsidentitäten und andere nicht-menschliche Identitäten
  • OT-Systeme und Cloud-Infrastruktur, nicht nur "Vordertür"-Logins

Erkenntnis 3: Compliance, Audit und Datensouveränität verlangen mehr als SSO-Logs

Prüfen Sie Ihre Audit-Trails und Genehmigungsabläufe

Compliance-Rahmenwerke und Kundinnen/Kunden fragen nicht nur: "Hatten Sie MFA?" Sie wollen wissen:

  • Können Sie nachweisen, wer zu einem bestimmten Zeitpunkt Zugriff auf dieses System, diesen Datensatz oder diese Region hatte?
  • Können Sie belegen, dass dieser Zugriff von der richtigen Person genehmigt und regelmäßig überprüft wurde?
  • Können Sie eine saubere, vollständige Ausbuchung für Mitarbeitende und Dienstleistende nachweisen, die ausgeschieden sind?

SSO hilft bei einem Teil des Puzzles: Es zeigt, wer sich wann und von wo authentifiziert hat. Es kann anzeigen, welche Anwendung gestartet wurde. Aber es zeigt in der Regel nicht:

  • Welche Berechtigungen innerhalb dieser Anwendung bestanden
  • Welche Workflows und Genehmigungen zu diesen Berechtigungen geführt haben
  • Wie sich diese Berechtigungen im Verlauf von Rollen-, Team- oder Standortwechseln verändert haben

Genau hier setzt Identity Governance an. Eine echte Governance-Schicht liefert Ihnen:

  • Zentrale Audit-Trails für Zugriffsanfragen, Genehmigungen, Änderungen und Entzüge
  • Strukturiere Zugriffsüberprüfungen mit klarer Verantwortlichkeit statt ad-hoc-E-Mail-Kampagnen
  • Nachweisexports, die SOC 2, ISO 27001 und Kundenprüfungen erfüllen, ohne dass wochenlang improvisiert werden muss

Auswirkungen auf Risiko, Identity-Compliance und Datensouveränität

Ohne Governance können Sie eine starke Anmeldesicherheit haben und dennoch bei Identity-Compliance scheitern:

  • Funktionstrennungsrichtlinien (Separation of Duties) sind nicht durchsetzbar, wenn Sie Berechtigungen über Fachanwendungen und Infrastruktur hinweg nicht sehen.
  • Sie können Fragen wie "Wer kann auf Produktionsdaten zugreifen?" oder "Wer kann Daten von EU-Betroffenen berühren?" nicht zuverlässig beantworten - beides ist für Datensouveränität und Datenschutz kritisch.
  • Adaptive Sicherheit auf der Login-Ebene kann überprivilegierte Konten und veraltete Zugriffe tief in Systemen nicht ausgleichen.

Mit der Zeit untergräbt das Ihre Governance-Reife. Die Folge sind:

  • Wiederkehrende Prüfungsfeststellungen zu unvollständigen Zugriffsüberprüfungen und fehlenden Nachweisen
  • Notfallprojekte zur "Zugriffsbereinigung", getrieben von Aufsichtsbehörden oder Kundschaft
  • Spannungen zwischen Security, IT und Fachbereichen, weil alle darüber streiten, wessen Tabelle die wahre Datenquelle ist

SSO ist für Identitätssicherheit notwendig. Es ist nur nicht ausreichend für Identity Governance.

Erkenntnis 4: SSO mit Gewalt in Governance zu pressen, ist teures Flickwerk

Zählen Sie die Kosten von Skripten, Workflows und Stammwissen

Wenn Teams entscheiden "SSO ist unser Governance-Tool", sammeln sie meist dieselben Muster an:

  • Eigenbau-Skripte, die HR-Attribute in SSO-Gruppen synchronisieren und rudimentäre Kontenbereitstellung versuchen
  • Einzelfall-Workflows in ITSM-Werkzeugen für Zugriffsanfragen, zusammengehalten durch E-Mail-Genehmigungen
  • Wikis voller Einträge wie "Wenn jemand ins Team X kommt, denk daran, ihn in die Gruppen A, B, C aufzunehmen und außerdem in diesen fünf SaaS-Anwendungen manuell anzulegen"
  • Kritisches Wissen über Produktionszugriff, Servicekonten und Sonderfälle, das in den Köpfen weniger Personen steckt

Das funktioniert - bis es nicht mehr funktioniert. Jede neue Anwendung, jedes neue Team, jede neue nicht-menschliche Identität erhöht die Fragilität. Irgendwann:

  • Verbringen Sie den Großteil Ihrer Zeit mit Zugriffsanfragen statt mit wertschöpfender Arbeit
  • Sind Sie bei jedem Offboarding nervös, weil Sie wissen, dass Sie etwas übersehen werden
  • Fürchten Sie, dass ein übersehenes Skript oder eine falsch konfigurierte Gruppe einen Sicherheitsvorfall - oder eine Prüfungsfeststellung - auslöst

Das ist der versteckte Preis, wenn Sie SSO in die Rolle von Identity Governance zwängen. Sie sparen kein Geld. Sie zahlen mit Entwicklungszeit, Betriebsrisiko und Stress.

Wie eine spezialisierte Governance-Schicht die Rechnung verändert

Eine moderne Identity-Governance-Plattform ist genau für dieses Problem gebaut. Typischerweise bietet sie:

  • Eine einheitliche Sicht auf alle Identitäten - Mitarbeitende, Externe, Partner, Servicekonten, Bots und andere nicht-menschliche Identitäten
  • Identitätsorchestrierung und Automatisierung, die zwischen HR, SSO/IdP, SaaS-Anwendungen und Infrastruktur sitzt und Joiner-Mover-Leaver-Prozesse Ende-zu-Ende steuert
  • Tiefe Konnektoren für SCIM-fähige Anwendungen und alternative Anbindungswege für Anwendungen ohne SCIM-Unterstützung, sodass die Abdeckung vollständig statt 20 % ist
  • Umfangreiche Zugriffsanfragen mit richtlinienbewusster Weiterleitung, Genehmigungen und automatisierter Bereitstellung, nicht bloß Tickets
  • Eingebaute Zugriffsrichtlinien und deren Durchsetzung, inklusive Funktionstrennung und Least-Privilege-Vorlagen
  • Kontinuierliche Audit-Trails, Zugriffsüberprüfungen und Berichte, die Sie prüfungsbereit statt prüfungsüberrascht halten

SSO bleibt dabei im Spiel: Es bleibt Ihr Identity Provider und Ihre Engine für adaptiven Zugriff. Governance schließt daran an - oft über SCIM und APIs - und erweitert Sichtbarkeit und Steuerung auf Systeme, die SSO nicht erreicht.

In der Praxis bedeutet das:

  • 80 % weniger manuelle Zugriffstickets, weil Standardbereitstellungen, Änderungen und Offboarding automatisiert sind
  • Sauberes, konsistentes Offboarding für Menschen und Maschinen gleichermaßen
  • Eine deutlich klarere Geschichte, wenn Sie Ihrem Vorstand, Prüfenden oder Großkundschaft Ihre Identitätssicherheit und Ihr Identitätsrisikomanagement erklären

Fazit und nächste Schritte: Lassen Sie SSO SSO sein - und verlagern Sie Governance dorthin, wo sie hingehört

SSO ist ein mächtiger Baustein Ihres Identitäts-Stacks. Aber es wurde nie dafür entwickelt, Ihre Identity-Governance-Plattform zu sein. Je stärker Sie versuchen, es in diese Rolle zu drängen, desto mehr manuelle Arbeit, inkonsistente Prozesse und unsichtbare Risiken sammeln Sie an.

Sie müssen nicht alles Bestehende austauschen. Sie müssen die richtigen Grenzen ziehen und die Lücken schließen.

Konkrete nächste Schritte:

  1. Verantwortlichkeiten dokumentieren. Machen Sie es explizit: SSO/IdP verantwortet Authentifizierung, Sitzungssteuerung und adaptiven Zugriff. Governance verantwortet Berechtigungen, Lebenszyklus, Genehmigungen, Überprüfungen und Prüfnachweise.
  2. Ihren Stack inventarisieren. Ordnen Sie Systeme ein in: vollständig gesteuert (automatisierte JML-Prozesse, Zugriffsüberprüfungen), nur SSO (Logins, aber manuelle Berechtigungen) und komplett manuell. Achten Sie besonders auf Zugriffswege in die Produktion, Finanzsysteme und Systeme mit Kundendaten.
  3. Ihre Identitäten erfassen. Listen Sie menschliche Identitäten und nicht-menschliche Identitäten (Servicekonten, Bots, CI-Jobs, API-Schlüssel, KI-Agenten) auf. Wenn sie nicht in Ihrem Identity-Governance-Modell vorkommen, stellen sie ein Risiko dar.
  4. Mindestanforderungen an Governance definieren. Legen Sie für Ihre Unternehmensgröße und Ihr Risikoprofil fest, was "gut genug" bedeutet: automatisierte Joiner-/Mover-/Leaver-Prozesse, standardisierte Zugriffsanfragen, regelmäßige Zugriffsüberprüfungen, belastbare Audit-Trails, klare Richtliniendurchsetzung.
  5. Governance-Optionen evaluieren. Suchen Sie nach Identity-Governance-Plattformen, die sich sauber mit Ihrem SSO integrieren (z. B. Okta-Integration oder Entra ID), nicht-SCIM-Anwendungen abdecken, menschliche und nicht-menschliche Identitäten vereinheitlichen und von einem schlanken IT-Team ohne sechsmonatiges Projekt betrieben werden können.

Ziel ist nicht "mehr Tools". Ziel ist das richtige Werkzeug für die richtige Aufgabe - damit Identity Governance vollständig, einfach zu betreiben ist und nicht länger nur mit SSO zusammengeflickt wird.

Häufig gestellte Fragen zu SSO und Identity Governance

Kann ich mich für Governance auf mein SSO verlassen, wenn wir noch ein kleines Unternehmen sind?

Für sehr kleine Teams kann die Nutzung von SSO-Gruppen als schlanke Möglichkeit zur Zugriffsverwaltung ein pragmatischer Einstieg sein. Doch zwei Dinge ändern sich schnell:

  • Ihr SaaS-Stack explodiert, und nur ein Teil davon sitzt ordentlich hinter SSO.
  • Compliance-Anforderungen (SOC 2, ISO 27001, Kundenbewertungen) verlangen Nachweise, die SSO allein nicht liefern kann.

Entwerfen Sie Ihr Identity-Governance-Modell frühzeitig, auch wenn Sie es schrittweise umsetzen. Andernfalls müssen Sie unter Zeitdruck alles neu aufbauen, sobald Wachstum oder Prüfungen Sie dazu zwingen.

Woran erkennen wir konkret, dass wir SSO in Governance hineinzwängen?

Typische Warnsignale:

  • Die meisten Zugriffsänderungen beginnen in SSO und laufen dann in Tickets und manuelle Schritte in mehreren Werkzeugen aus.
  • Niemand kann eine verlässliche Liste liefern, wer Zugriff auf bestimmte sensible Systeme oder Daten hat.
  • Zugriffsüberprüfungen sind tabellengetrieben und schmerzhaft, obwohl Sie "SSO haben".
  • Offboarding-Checklisten sind lang, manuell und fehleranfällig - insbesondere für Externe und Dienstleistende.
  • Servicekonten und Automatisierungsidentitäten sind kaum sichtbar und werden als geteilte Geheimnisse statt als gesteuerte Identitäten behandelt.

Wenn Ihnen das bekannt vorkommt, übernimmt Ihr SSO Doppelrolle als Governance-Tool - und Ihr Team trägt die Last.

Wie sollten SSO und eine Governance-Plattform zusammenspielen?

Denken Sie an SSO und Governance als zwei Schichten:

  • SSO / IdP: Quelle für Authentifizierung, adaptiven Zugriff, bedingte Richtlinien beim Login und teilweise grobe Zuweisung von Anwendungen.
  • Identity-Governance-Plattform: Quelle der Wahrheit dafür, wer worauf, warum und wie lange Zugriff haben sollte.

In einer gesunden Architektur gilt:

  • HR oder Ihr führendes Quellsystem sendet Identitätsereignisse (Joiner/Mover/Leaver) an die Governance-Schicht.
  • Die Governance-Schicht entscheidet, welche Anwendungen und Berechtigungen gewährt oder entzogen werden, und nutzt SCIM oder andere Konnektoren, um Änderungen in SSO und Anwendungen durchzusetzen.
  • SSO setzt weiterhin Anmelderisikorichtlinien durch, aber Berechtigungen und Genehmigungen liegen in der Governance.

So erhalten Sie starke Identitätssicherheit an der Eingangstür und starke Governance dahinter.

Was ist mit nicht-menschlichen Identitäten und Servicekonten?

Nicht-menschliche Identitäten sind oft der größte blinde Fleck im Identitätsmanagement:

  • Servicekonten, die mit kritischer Infrastruktur verknüpft sind
  • CI/CD-Pipelines mit weitreichendem Produktionszugriff
  • Bots und Integrationsnutzer in SaaS-Tools
  • API-Schlüssel und Token, die teamübergreifend geteilt werden

Diese authentifizieren sich meist nicht über SSO und tauchen selten in HR-Systemen auf. Eine Governance-Plattform sollte:

  • Sie als vollwertige Identitäten mit Verantwortlichen, Zweck und Richtlinien modellieren
  • Sie in dieselben Zugriffsüberprüfungs- und Deprovisioning-Prozesse wie Menschen einbinden
  • Sicherstellen, dass ihre Berechtigungen dem Least-Privilege-Prinzip folgen, insbesondere in Produktions- und OT-Umgebungen

Wenn Ihre "Governance"-Geschichte nicht-menschliche Identitäten ausblendet, ist Ihre Risikobetrachtung unvollständig.

Wie begründe ich Budget für eine spezialisierte Identity-Governance-Lösung?

Stellen Sie es in Begriffen dar, die Führungskräfte verstehen:

  • Risikoreduktion: Weniger verwaiste Konten, enger gesteuerter Produktionszugriff, bessere OT-Sicherheit und insgesamt stärkere Identitätssicherheit.
  • Betriebliche Effizienz: 80 % weniger manuelle Tickets und erhebliche Zeiteinsparungen bei Audits und Zugriffsüberprüfungen, sodass Ihr IT-Team an strategischen Projekten arbeiten kann.
  • Kostenoptimierung: Bessere SaaS-Governance und Lizenzrückgewinnung verringern Verschwendung, insbesondere bei teuren, SCIM-gebundenen Enterprise-Plänen.
  • Compliance und Umsatz: Starke Identity-Compliance und Prüfreife verkürzen Sicherheitsfragebögen, beschleunigen Großkundengeschäfte und reduzieren das Risiko gescheiterter Audits.

Verglichen mit den laufenden Kosten manueller Arbeit, zusammengeflickter Skripte und hektischer Audit-Feuerwehreinsätze ist eine fokussierte Governance-Schicht meist die günstigere und sicherere Wahl.