SaaS-Offboarding braucht mehr als deaktivierte Benutzerkonten

Viele IT-Organisationen haben ihr Joiner-Mover-Leaver-Modell im Grundsatz im Griff. Neue Mitarbeitende bekommen per Identity Provider Zugriff auf Standardanwendungen, Gruppenmitgliedschaften und erste Rollen. Beim Offboarding wirkt derselbe Mechanismus auf den ersten Blick ebenso klar: Konto deaktivieren, Lizenz entziehen, fertig. Genau hier liegt in SaaS-Landschaften aber ein gefährlicher Trugschluss. Denn zwischen zentralem Identitätskonto, aktiven Sitzungen, gruppenbasierten Berechtigungen, Datenbesitz, API-Zugängen und cloudseitigen Restobjekten liegen heute mehrere Ebenen, die nicht automatisch gemeinsam verschwinden.

Das Problem ist nicht theoretisch. Microsoft beschreibt für Notfallszenarien rund um kompromittierte Accounts oder Mitarbeitertrennungen ausdrücklich, dass Administratoren mehrere Schritte kombinieren müssen, weil Zugang nicht in jeder Anwendung sofort mit dem ersten Sperrschritt endet. Okta zeigt in seiner SCIM-Dokumentation, dass Deprovisioning in vielen Integrationen zunächst auf active=false hinausläuft, also auf Deaktivierung statt tatsächlicher Löschung. Atlassian verweist darauf, dass deaktivierte externe Nutzer trotz Änderungen in SCIM-Gruppen ihren Site-Zugang behalten können. Und Google macht deutlich, dass beim Löschen eines Nutzers nicht nur Datenübergaben nötig sind, sondern sogar Cloud-Ressourcen verwaisen können. Wer Offboarding sauber steuern will, braucht deshalb ein vollständigeres Betriebsmodell.

Das Identitätskonto ist nur der Anfang

Ein deaktivierter Benutzer im zentralen Verzeichnis ist notwendig, aber er beendet nicht automatisch jeden aktiven Zugang. Microsoft unterscheidet in Entra sehr klar zwischen Access Tokens, Refresh Tokens und anwendungsseitigen Session Tokens. Genau daraus folgt ein wichtiger Praxispunkt: Selbst wenn neue Token nicht mehr ausgestellt werden, kann eine bestehende Sitzung in einer Anwendung noch weiterlaufen, bis die Anwendung selbst ihre Session beendet oder neu prüft.

Für ein belastbares Offboarding reicht es deshalb nicht, nur das Konto zu sperren. Microsoft empfiehlt im Ernstfall zusätzlich, Refresh Tokens zu widerrufen und Geräte des Nutzers zu deaktivieren. Das ist operativ relevant, weil sich sonst alte Sitzungen, verwaltete Geräte oder zwischengespeicherte Anmeldungen länger halten als gedacht. Wer Offboarding nur als Identity-Aufgabe betrachtet, blendet genau diese Restlaufzeiten aus.

Im IT-Management sollte daher jede Leaver-Strecke mindestens drei Ebenen unterscheiden: zentrale Kontosperre, Session- beziehungsweise Token-Entzug und Geräte- oder Endpoint-Maßnahmen. Erst zusammen ergibt das einen wirksamen Entzug des Zugangs.

SCIM deprovisioniert oft, aber nicht immer so, wie Teams es erwarten

Viele Häuser verlassen sich darauf, dass SCIM das Problem grundsätzlich löst. Tatsächlich ist SCIM für SaaS-Offboarding ein großer Fortschritt, weil Konten automatisiert erstellt, aktualisiert und deaktiviert werden können. Microsoft Entra beschreibt den eigenen Provisioning-Dienst genau so: über SCIM 2.0, mit automatischer Pflege und Entfernung von Identitäten. Auch Okta positioniert SCIM als Standard für automatisierte Lifecycle-Prozesse.

Der operative Haken steckt im Detail. Okta macht ausdrücklich klar, dass Deprovisioning bei vielen SCIM-Szenarien auf eine Änderung des Attributs active auf false hinausläuft. Noch wichtiger: Wird ein bereits deaktivierter Nutzer später in Okta gelöscht, sendet Okta laut Dokumentation nicht automatisch noch einmal einen Delete-Request an die nachgelagerte SCIM-Anwendung. Für das Zielsystem bleibt also häufig ein deaktiviertes Objekt bestehen, kein sauber entferntes Objekt.

Das ist nicht per se falsch. In vielen Anwendungen ist Deaktivierung sogar sinnvoller als harte Löschung, weil Audit-Trails, Besitzverhältnisse oder spätere Reaktivierungen erhalten bleiben sollen. Problematisch wird es erst, wenn das IT-Team stillschweigend annimmt, dass jede SCIM-Anbindung gleich reagiert. In der Praxis muss für jede geschäftskritische SaaS-Anwendung klar dokumentiert sein, ob Offboarding dort Deaktivierung, Lizenzentzug, Gruppenentfernung, Session-Entzug oder echte Löschung auslöst.

Gruppen, externe Konten und Site-Zugänge brauchen eine zweite Prüfung

Ein weiteres Missverständnis ist die Gleichsetzung von Gruppenentfernung mit vollständigem Zugangsverlust. Atlassian zeigt sehr anschaulich, warum das zu kurz gedacht ist. In der eigenen SCIM-Dokumentation weist Atlassian darauf hin, dass bei externen Nutzern eine Deaktivierung zwar aus den provisionierten Gruppen entfernen kann und dadurch App-Zugänge verloren gehen können, der Nutzer aber trotzdem weiterhin Site-Zugang haben kann. Um diesen Zugang ebenfalls zu entfernen, muss der Nutzer zusätzlich von der Site entfernt werden.

Genau solche Produktbesonderheiten machen SaaS-Offboarding zum Managementthema. Nicht jede Plattform koppelt Identität, Gruppen, Rollen und Inhalte identisch. Manche Anwendungen trennen Site-Zugang, Produktlizenz, Admin-Rolle und Inhaltseigentum. Andere arbeiten mit Gastkonten, externen Identitäten oder manuellen Freigaben außerhalb des IdP-Flows. Wieder andere erlauben direkten Login mit lokaler Anmeldung, auch wenn SSO eingerichtet ist.

Ein gutes Offboarding-Runbook braucht deshalb pro Plattform eine zweite Prüfebene: Welche Rechte bleiben trotz Deaktivierung denkbar bestehen? Dazu gehören etwa Site-Mitgliedschaften, lokale Administratoren, Notfallkonten, Gastzugänge, geteilte Postfächer oder manuell vergebene Produktrollen. Ohne diese Produktsicht endet ein formal korrektes Offboarding mit fachlich offenen Restzugängen.

Daten, Kalender, Dateien und Cloud-Ressourcen müssen aktiv übergeben werden

Viele Offboarding-Prozesse scheitern nicht an Sicherheit, sondern am unklaren Umgang mit Unternehmensdaten. Google beschreibt für Google Workspace sehr deutlich, dass vor dem Löschen eines Nutzers wichtige Daten übertragen werden sollten, etwa E-Mails, Drive-Dateien, Kalenderdaten oder weitere fachliche Inhalte. Gleichzeitig weist Google darauf hin, dass beim Löschen Cloud-Ressourcen verwaisen können und IAM-Bindings auf Ressourcen bis zu 30 Tage bestehen bleiben können.

Das ist für IT-Management besonders wichtig, weil SaaS-Offboarding fast immer auch Eigentumsübergaben einschließt. Wer ist neuer Owner eines Dashboards, eines gemeinsamen Kalenders, einer Wissensseite, einer Automatisierung oder eines Cloud-Projekts? Wenn diese Frage nicht vor der Deaktivierung beantwortet wird, entstehen später Sucharbeit, Betriebsrisiken und im ungünstigen Fall verwaiste Geschäftsobjekte.

Darum sollte jede Offboarding-Strecke nicht nur eine Sicherheitscheckliste, sondern auch eine Übergabeliste enthalten. Sinnvoll sind mindestens diese Felder: Anwendungen mit Datenbesitz, übergabepflichtige Artefakte, neuer Owner, Frist, bestätigt durch Fachseite. Ohne diesen Schritt produziert das Unternehmen formal entfernte Nutzer, aber operativ liegengebliebene Verantwortungen.

Geräte, Cookies, Tokens und nicht-menschliche Zugänge brauchen eigene Runbooks

Besonders häufig unterschätzt werden die Reste außerhalb des sichtbaren Benutzerkontos. Google empfiehlt nach einem Passwort-Reset ausdrücklich auch das Zurücksetzen der Sign-in-Cookies, damit alte Sitzungen nicht weiterlaufen. Microsoft betont, dass Anwendungen ihre eigenen Session Tokens verwalten und diese nicht allein durch den IdP widerrufen werden. Das zeigt ein grundsätzliches Muster: Sitzungen und Token leben oft länger als das Gefühl, der Zugang sei bereits entzogen.

Dazu kommen nicht-menschliche Zugänge. Viele Mitarbeitende besitzen persönliche API-Tokens, App-spezifische Passwörter, CLI-Anmeldungen, OAuth-Freigaben oder Automatisierungen in Integrationsplattformen. Diese Objekte hängen zwar an einem Menschen, verschwinden aber im Offboarding nicht immer automatisch mit dessen Konto. Technisch ist das oft logisch, betrieblich aber riskant.

Deshalb braucht ein reifer Offboarding-Prozess eigene Teil-Runbooks für Geräte und für nicht-menschliche Identitäten. Dazu gehört das Sperren verwalteter Geräte, das Zurücksetzen aktiver Sitzungen, das Widerrufen persönlicher Tokens und das Prüfen, ob Automationen, Servicekonten oder API-Schlüssel an die Person gebunden waren. Gerade in SaaS-lastigen Umgebungen entscheidet sich hier, ob Offboarding tatsächlich wirksam ist oder nur im HR-System abgeschlossen wurde.

Worauf IT-Leitungen jetzt konkret achten sollten

• Plattformweise dokumentieren, ob Offboarding in der Anwendung Deaktivierung, Gruppenentzug, Lizenzentzug oder echte Löschung auslöst.
• Kontosperre, Session-Entzug und Geräte-Maßnahmen trennen, statt alles unter einem Schritt „User deaktivieren“ zu verbuchen.
• Externe Nutzer, Gastkonten und lokale Rollen separat prüfen, weil sie oft nicht sauber am Hauptkonto hängen.
• Daten- und Eigentumsübergaben verbindlich machen, bevor Konten gelöscht oder langfristig deaktiviert werden.
• Persönliche Tokens, OAuth-Freigaben und Automationen in die Leaver-Checkliste aufnehmen, nicht nur sichtbare App-Logins.

Fazit

SaaS-Offboarding ist längst keine reine Verzeichnisaufgabe mehr. Ein deaktiviertes Benutzerkonto ist nur der erste Schritt in einer Kette aus Session-Kontrolle, Gruppen- und Rollenentzug, Datenübergabe, Geräte-Sperrung und Aufräumen von Restzugängen. Wer diese Ebenen nicht zusammendenkt, produziert ein trügerisch sauberes Offboarding mit offenen Flanken in Betrieb und Governance.

Die pragmatische Konsequenz ist klar: IT-Leitungen sollten Offboarding nicht als einheitlichen Standardvorgang betrachten, sondern als produktübergreifendes Betriebsmodell mit verbindlichen Prüfpunkten pro SaaS-Plattform. Genau dort trennt sich administrative Formalität von wirklicher Zugangskontrolle.

Quellen

• Microsoft Learn: Understand how Application Provisioning in Microsoft Entra ID works
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• Okta Developer: Understanding SCIM
• Atlassian: Understand user provisioning
• Google Workspace Admin Help: Delete or remove a user from your organization
• Google Workspace Admin Help: Reset a user’s password