Warum deaktivierte Nutzer oft trotzdem noch Zugriff haben – und wie man das verhindert

Wer im Unternehmen einen Benutzer deaktiviert, geht meist davon aus, dass der Zugriff damit sofort beendet ist. In der Praxis ist das jedoch häufig nicht der Fall. Das Benutzerkonto ist im zentralen Identity Provider zwar gesperrt, doch in angebundenen Anwendungen existieren oft noch aktive Sessions, gültige Tokens oder lokal verwaltete Accounts. Genau darin liegt ein erhebliches Sicherheitsrisiko: Der Nutzer gilt organisatorisch bereits als entfernt, technisch kann er aber unter Umständen weiterhin auf Systeme, Daten oder Anwendungen zugreifen.

Gerade in modernen IT-Landschaften mit Single Sign-on, Cloud-Diensten, föderierten Identitäten und zahlreichen Drittanwendungen ist dieser Effekt keine Ausnahme, sondern ein strukturelles Problem. Wer sauberes Offboarding, belastbare Zugriffskontrolle und konsistente Identity-Security umsetzen will, muss daher mehr tun, als einen Benutzer im Verzeichnis auf „deaktiviert“ zu setzen. Entscheidend ist, dass der Zugriff in allen beteiligten Systemen sofort und systemübergreifend endet.

Warum ein deaktivierter Benutzer oft nicht wirklich „raus“ ist

Der häufigste Irrtum im Identity and Access Management besteht darin, Kontodeaktivierung mit sofortigem Zugriffsentzug gleichzusetzen. Diese beiden Vorgänge hängen zwar zusammen, sind technisch aber nicht identisch. Der Identity Provider kann neue Anmeldungen blockieren, doch bereits bestehende Sitzungen in Zielanwendungen laufen häufig weiter. Viele Anwendungen verwalten ihre Sessions lokal und erfahren nicht automatisch in Echtzeit, dass der Nutzer im führenden System inzwischen gesperrt wurde.

Hinzu kommt die tokenbasierte Authentifizierung. In vielen Umgebungen erhält ein Benutzer nach der Anmeldung Access Tokens oder Refresh Tokens mit definierter Laufzeit. Solange diese Tokens gültig sind, akzeptieren APIs oder Anwendungen die Anfragen unter Umständen weiterhin – selbst wenn der Account im Hintergrund bereits deaktiviert wurde. Das Ergebnis ist eine Lücke zwischen dem administrativen Status und der tatsächlichen Durchsetzung des Zugriffsentzugs.

Ein weiteres Problem entsteht durch lokal angelegte Benutzerobjekte in Drittanwendungen. Viele SaaS-Plattformen oder Fachanwendungen arbeiten nicht rein föderiert, sondern legen aus dem zentralen IAM heraus eigene Benutzerkonten an. Wenn diese Konten beim Offboarding nicht sauber deaktiviert oder gelöscht werden, bleiben Restzugriffe bestehen. Genau hier zeigt sich, dass zentrales Identity Management nur dann wirksam ist, wenn auch die Zielsysteme konsequent angebunden und automatisiert eingebunden sind.

Typische Ursachen für Restzugriffe nach dem Offboarding

In der Praxis entstehen diese Lücken meist nicht durch einen einzelnen Konfigurationsfehler, sondern durch die Architektur selbst. Besonders häufig sind lokale Anwendungssessions problematisch. Ein Benutzer meldet sich einmal per Single Sign-on an, danach verwaltet die Anwendung ihre Session eigenständig. Wird der Account später zentral deaktiviert, merkt die Anwendung davon nicht zwingend sofort etwas. Aus Sicht der IT ist der Nutzer bereits entfernt, aus Sicht der Anwendung ist er aber noch aktiv.

Ebenso kritisch sind lange Session- und Token-Laufzeiten. Sie verbessern die Benutzerfreundlichkeit, verlängern aber gleichzeitig das Zeitfenster, in dem ein eigentlich gesperrter Benutzer technisch noch arbeiten kann. Das betrifft nicht nur Webanwendungen, sondern auch mobile Apps, API-Zugriffe und automatisierte Prozesse, die mit bestehenden Anmeldedaten weiterlaufen.

Dazu kommen organisatorische Verzögerungen. In vielen Unternehmen wird ein Offboarding zwar angestoßen, aber nicht unmittelbar technisch in alle Systeme übertragen. Zwischen HR-Prozess, IAM-Aktion, Provisioning und tatsächlicher Deaktivierung in der Fachanwendung liegen dann Minuten, Stunden oder im schlechtesten Fall sogar Tage. Gerade bei sensiblen Rollen, privilegierten Konten oder externen Dienstleistern ist das aus Sicherheits- und Compliance-Sicht problematisch.

Warum das Thema für Security und Compliance so wichtig ist

Restzugriffe sind nicht nur ein technisches Ärgernis. Sie berühren zentrale Anforderungen aus Informationssicherheit, Datenschutz und Governance. Wenn ehemalige Mitarbeiter, externe Partner oder intern gesperrte Benutzer weiterhin Zugriff auf Anwendungen oder Daten haben, entsteht ein unmittelbares Risiko für Vertraulichkeit, Integrität und Nachvollziehbarkeit.

Besonders relevant wird das in regulierten Umgebungen. Dort muss der Entzug von Berechtigungen nicht nur dokumentiert, sondern auch tatsächlich wirksam umgesetzt werden. Ein deaktiviertes Konto im Verzeichnis reicht in Audits oder Sicherheitsanalysen nicht aus, wenn in Drittanwendungen noch aktive Sitzungen oder lokale Benutzerobjekte vorhanden sind. Unternehmen brauchen deshalb Prozesse und technische Mechanismen, die den Zugriff nicht irgendwann, sondern sofort beenden.

Wie man verhindert, dass deaktivierte Nutzer weiter Zugriff haben

Die wirksame Lösung besteht nicht in einem einzelnen Feature, sondern in einem abgestimmten Zusammenspiel mehrerer Standards und Mechanismen. Im Kern geht es um drei Ebenen: lokale Konten deaktivieren, aktive Sessions beenden und Sicherheitsereignisse in Echtzeit auswerten. Erst wenn alle drei Bereiche sauber adressiert sind, wird aus einer administrativen Deaktivierung ein echter, technisch durchgesetzter Zugriffsentzug.

SCIM-Deprovisioning: lokale Konten in Zielsystemen automatisch abschalten

Ein zentraler Baustein ist SCIM-Deprovisioning. Der SCIM-Standard sorgt dafür, dass Benutzerkonten in angebundenen Drittanwendungen automatisiert verwaltet werden können. Wird ein Benutzer im führenden Identity-System deaktiviert, lässt sich dieser Status an die Zielanwendung weitergeben, sodass dort das lokale Benutzerobjekt ebenfalls auf inaktiv gesetzt wird.

Das ist für ein sauberes Offboarding essenziell. Denn viele Restzugriffe entstehen genau dort, wo das zentrale Konto zwar gesperrt wurde, das Konto in der Fachanwendung aber weiter existiert. SCIM schließt diese Lücke, indem die Deaktivierung systematisch in die angebundenen Anwendungen übertragen wird. So werden Schattenkonten vermieden, und die Konsistenz zwischen Identity Provider und Zielsystemen steigt deutlich.

Im COMPRISE-Kontext ist das besonders relevant für heterogene IT-Landschaften mit vielen angebundenen Anwendungen, Diensten und Integrationspunkten. Dort reicht es nicht, Identitäten nur zentral zu verwalten. Entscheidend ist, dass Änderungen am Benutzerstatus zuverlässig in die operativen Systeme durchgereicht werden. Genau an dieser Stelle gewinnen standardisierte Provisioning- und Deprovisioning-Prozesse strategische Bedeutung.

Back-Channel Logout: bestehende Sessions serverseitig sofort beenden

SCIM allein löst allerdings nur einen Teil des Problems. Denn selbst wenn das lokale Benutzerkonto in der Zielanwendung deaktiviert wurde, kann unter Umständen noch eine bestehende Sitzung aktiv sein. Genau dafür ist Back-Channel Logout relevant. Dieser Mechanismus informiert Anwendungen serverseitig darüber, dass eine Sitzung beendet wurde oder beendet werden muss. Die Anwendung kann ihre lokale Session daraufhin sofort invalidieren.

Der entscheidende Vorteil liegt darin, dass die Beendigung nicht vom Browser oder von einer manuellen Benutzeraktion abhängt. Gerade in sicherheitskritischen Szenarien ist das wichtig. Wenn ein Benutzer deaktiviert wird, muss die Anwendung nicht warten, bis ein Logout irgendwann im Frontend ankommt. Stattdessen kann sie die Sitzung unmittelbar serverseitig beenden.

Für Unternehmen bedeutet das: Offboarding wird nicht nur im Verzeichnis und in den Konten wirksam, sondern auch in den laufenden Sessions. Das reduziert das Risiko erheblich, dass ein bereits gesperrter Nutzer mit einer noch offenen Anwendungssitzung weiterarbeiten kann. In modernen SSO-Architekturen gehört diese Fähigkeit deshalb zu den entscheidenden Qualitätsmerkmalen einer belastbaren Identity-Integration.

CAEP: sicherheitsrelevante Ereignisse in Echtzeit auswerten

Der dritte Baustein geht noch einen Schritt weiter. Mit Continuous Access Evaluation Profile (CAEP) lassen sich sicherheitsrelevante Ereignisse in Echtzeit an Anwendungen oder empfangende Systeme übermitteln. Dazu zählen beispielsweise der Entzug einer Sitzung, eine Änderung am Credential-Status oder andere Zustandsänderungen, die eine sofortige Neubewertung des Zugriffs erforderlich machen.

Der Unterschied zu klassischen Modellen ist erheblich. Traditionell wird Zugriff oft nur beim Login geprüft. Danach gilt eine Sitzung oder ein Token bis zum Ablauf als vertrauenswürdig. CAEP verschiebt dieses Prinzip in Richtung kontinuierlicher Zugriffskontrolle. Anwendungen und Dienste können auf Statusänderungen direkt reagieren und den Zugriff entziehen, sobald sich die Sicherheitslage ändert.

Für Zero-Trust-orientierte Architekturen ist das besonders interessant. Vertrauen wird dort nicht einmalig vergeben, sondern fortlaufend überprüft. Genau deshalb sind ereignisgesteuerte Mechanismen wie CAEP so relevant: Sie helfen dabei, die Lücke zwischen Identitätsstatus und technischer Zugriffsdurchsetzung zu schließen.

Die eigentliche Lösung ist eine durchdachte IAM-Architektur

Unternehmen sollten das Problem nicht isoliert betrachten. Es geht nicht nur darum, einen Standard wie SCIM, CAEP oder Back-Channel Logout zu aktivieren. Es geht darum, eine IAM-Architektur aufzubauen, in der diese Mechanismen sauber ineinandergreifen. Ein robustes Modell beginnt im führenden Identity-System, propagiert Statusänderungen automatisiert in die Zielsysteme, beendet laufende Sessions und bewertet sicherheitsrelevante Ereignisse kontinuierlich neu.

Genau hier liegt auch ein typischer Mehrwert im COMPRISE-Umfeld. In vielen Organisationen besteht die Herausforderung nicht darin, dass Standards unbekannt wären, sondern darin, dass sie in gewachsenen Systemlandschaften nicht durchgängig umgesetzt sind. Unterschiedliche Anwendungen, proprietäre Schnittstellen, historisch gewachsene Berechtigungsmodelle und uneinheitliche Integrationsstände führen dazu, dass Zugriffsentzug zwar vorgesehen, aber nicht überall technisch sauber durchgesetzt wird.

Ein praxisorientierter Ansatz muss deshalb sowohl die Architektur als auch die operative Umsetzung berücksichtigen. Dazu gehören die Auswahl geeigneter Standards, die Analyse der Zielanwendungen, die Prüfung der tatsächlichen Unterstützung von Provisioning- und Logout-Mechanismen sowie die Definition klarer Offboarding-Prozesse. Nur so wird aus einem Identity-Konzept ein belastbarer Sicherheitsprozess.

Worauf Unternehmen jetzt konkret achten sollten

Wer das Risiko von Restzugriffen reduzieren will, sollte zunächst prüfen, welche Anwendungen überhaupt lokale Benutzerkonten anlegen und wie diese verwaltet werden. Danach ist zu klären, ob automatisiertes Deprovisioning per SCIM unterstützt wird und ob bestehende Sessions bei Deaktivierung eines Benutzers sofort beendet werden können. Ebenso wichtig ist die Frage, wie lang Tokens und Sessions gültig bleiben und ob sicherheitsrelevante Statusänderungen an Anwendungen in Echtzeit propagiert werden.

In der Praxis zeigt sich oft, dass gerade die kritischen Systeme keine vollständige Standardunterstützung besitzen. Dann braucht es entweder kompensierende Maßnahmen oder eine priorisierte Modernisierung der Integrationen. Aus Security-Sicht ist es sinnvoll, privilegierte Zugänge, administrative Konten, externe Benutzer und hochsensible Anwendungen zuerst zu betrachten. Dort sind die Auswirkungen von Restzugriffen besonders gravierend.

Fazit: Deaktivierung ist nur dann wirksam, wenn der Zugriff überall endet

Deaktivierte Nutzer behalten oft deshalb noch Zugriff, weil Identitätsstatus, Zielanwendungen, Sessions und Tokens in verteilten Umgebungen nicht automatisch synchronisiert werden. Wer nur den zentralen Account sperrt, stoppt nicht zwangsläufig bestehende Sitzungen, lokale Konten oder bereits ausgestellte Zugriffsartefakte. Genau daraus entstehen die gefährlichen Zeitfenster, in denen ehemalige oder gesperrte Nutzer technisch noch aktiv sein können.

Die Lösung liegt in einem ganzheitlichen Vorgehen: SCIM-Deprovisioning reduziert lokale Restkonten, Back-Channel Logout beendet aktive Sessions und CAEP ermöglicht eine kontinuierliche, ereignisgesteuerte Zugriffsbewertung. Erst dieses Zusammenspiel sorgt dafür, dass Offboarding nicht nur administrativ dokumentiert, sondern auch technisch wirksam wird.

Für Unternehmen, die ihre IAM- und Security-Architektur modernisieren wollen, ist das kein Randthema. Es ist ein zentraler Bestandteil belastbarer Zugriffskontrolle. Im COMPRISE-Kontext zeigt sich besonders deutlich: Erst durch saubere Integration, standardisierte Schnittstellen und durchgängige Automatisierung wird aus einer Deaktivierung ein echter, sofort wirksamer Zugriffsentzug.