Zugriffe beim Austritt vollständig entziehen und nachweisen

Das Offboarding von Mitarbeitenden ist erst abgeschlossen, wenn die Organisation zeigen kann, dass der Zugriff überall dort, wo er enden sollte, zum vorgesehenen Zeitpunkt beendet wurde und dabei Geschäftsunterlagen und notwendige Zuständigkeiten erhalten blieben. Ein einzelnes Verzeichniskonto zu deaktivieren ist ein wichtiger Schritt, aber kein Nachweis dafür, dass Cloud-Sitzungen, lokale Anwendungskonten, API-Tokens, gemeinsam genutzte Zugangsdaten, Geräte, physische Ausweise und delegierte Zuständigkeiten behandelt wurden.

Ein verlässlicher Prozess richtet HR, Führungskraft, IT, Sicherheit, Facility Management, Rechtsabteilung und die Verantwortlichen der Anwendungen auf ein gemeinsames, maßgebliches Ereignis aus. Er unterscheidet einen geplanten Austritt von einer dringenden oder risikoreichen Beendigung. Er sagt allen, die für ein System verantwortlich sind, was zu tun ist, bestätigt das Ergebnis und erzeugt Nachweise, die später überprüft werden können.

Das Kontrollziel: Ab dem Zeitpunkt, zu dem die Beendigung wirksam wird, kann die ehemals beschäftigte Person keinen unbefugten Zugriff einleiten oder fortsetzen, keine übersehene Identität nutzen, keine Transaktionen genehmigen, keine Unternehmensdaten abrufen und keine Kontrolle über betriebliche Vermögenswerte behalten. Die Organisation kann jede wesentliche Maßnahme nachweisen und jede genehmigte Ausnahme erklären.

Dieser Leitfaden beschreibt ein praxisnahes Betriebsmodell auf Basis aktueller NIST-Kontrollen, aktueller Leitlinien zu Microsoft Entra und einschlägiger EU-Beispiele zur Zugangskontrolle, die am 12. September 2026 geprüft wurden. Er schreibt keine allgemeingültige Zeitregel vor. Die richtige Frist hängt von Risiko, Recht, Beschäftigungsprozess, vertraglichen Pflichten und den betroffenen Systemen ab.

Ein Austritt verursacht mehrere unterschiedliche Probleme

Offboarding wird oft als Liste von Konten behandelt. Das eigentliche Problem hat mindestens sechs Ebenen:

1. Identität: Das Beschäftigungs- oder Vertragsverhältnis endet, und der maßgebliche Status muss sich ändern.
2. Authentifizierung: Passwörter, Zertifikate, Schlüssel, Tokens und aktive Sitzungen können weiter funktionieren.
3. Autorisierung: Gruppen, Rollen, delegierte Rechte und privilegierte Zuweisungen können Kontoänderungen überdauern.
4. Zuständigkeit: Dateien, Postfächer, Automatisierungen, Servicekonten, Repositories und Geschäftsprozesse können noch von der ausscheidenden Person abhängen.
5. Arbeitsmittel und physischer Zugang: Laptops, Telefone, Ausweise, Schlüssel und Wechseldatenträger müssen zurückgeholt oder kontrolliert werden.
6. Nachweise und Aufbewahrung: Geschäftsunterlagen müssen nach festgelegten Aufbewahrungs-, Datenschutz- und Rechtsregeln verfügbar bleiben, ohne dass unnötige Zugriffe aktiv bleiben.

Ein Prozess, der nur die erste Ebene abdeckt, kann im Ticketsystem erfolgreich aussehen, während an anderer Stelle weiter Zugriff besteht.

Das maßgebliche Ereignis festlegen, dann automatisieren

Jeder Austrittsprozess braucht eine vertrauenswürdige Quelle für drei Angaben: wer ausscheidet, wann die Änderung wirksam wird und welcher Risikopfad gilt. Für Mitarbeitende ist üblicherweise HR maßgeblich, während für den Status externer Mitarbeitender der Einkauf, das Lieferantenmanagement oder eine beauftragende Führungskraft zuständig sein kann. Der technische Workflow sollte keinen Beendigungszeitpunkt aus einem E-Mail-Betreff erraten oder darauf warten, dass jemand in der Administration einen Freitext auslegt.

Erfassen Sie die stabile Identität der Person, Beschäftigungsart, Führungskraft, Datum und Uhrzeit des Wirksamwerdens, Zeitzone, beschäftigende Gesellschaft, bekannte Aliasnamen, Risikoeinstufung und zur Information berechtigte Personen. Verwenden Sie nur die mindestens erforderlichen personenbezogenen Daten. Details mit hohem Risiko sollten auf die Personen beschränkt werden, die sie benötigen.

Geplante Austritte können schon vor dem letzten Arbeitstag Vorbereitungen auslösen: Inventar der Zuständigkeiten, Datenübergabe, Zeitplan für die Rückgabe der Arbeitsmittel und Überprüfung der Anwendungen. Der eigentliche Entzug der Zugriffsrechte sollte zum genehmigten Zeitpunkt des Wirksamwerdens erfolgen. Sofortige oder unfreiwillige Austritte erfordern ein eng koordiniertes Ereignis, bei dem HR oder eine berechtigte Führungskraft den Prozess startet und die zuständigen Teams handeln, ohne die betroffene Person vorab zu informieren, wo dies notwendig und rechtlich zulässig ist.

Risikostufen statt einer pauschalen Frist

Kein einzelnes Service-Level passt zu jedem Austritt. Eine Person mit Administrationsrechten in der Produktion, Zahlungsbefugnis oder Zugriff auf sensible Forschung stellt ein anderes Risiko dar als eine Saisonkraft mit einer einzigen Anwendung mit geringem Risiko. Definieren Sie Stufen, die sich bei jeder Entscheidung einheitlich anwenden lassen.

Die Organisation sollte für jede Risikostufe und Systemklasse die erwartete Erledigungszeit dokumentieren. NIST SP 800-53 verwendet bewusst einen von der Organisation festgelegten Zeitraum für die Deaktivierung von Konten, die keiner Person mehr zugeordnet sind. Dieser Ansatz verlangt eine vertretbare Festlegung und Messung, kein unbestimmtes Versprechen, „zeitnah“ zu handeln.

Ein Zeitplan, der sich umsetzen lässt

Der folgende Zeitplan trennt Vorbereitung, Entzug und Verifizierung. Passen Sie ihn an Arbeitsrecht, Tarifverträge und interne Richtlinien an.

Vor dem Austrittstag

• Bestätigen Sie den maßgeblichen Austrittseintrag und die genaue Zeitzone.
• Ermitteln Sie alle Konten, Rollen, Gruppen, privilegierten Zuweisungen, Geräte, Zugangsdaten und physischen Zugangsrechte, die mit der Person verbunden sind.
• Bitten Sie die Führungskraft, geschäftliche Dateien, E-Mails, Kalender, Repositories, Automatisierungen und Genehmigungszuständigkeiten zu benennen, die übertragen werden müssen.
• Weisen Sie die Verantwortung für Servicekonten, Anwendungen, kryptografisches Material und Zugangsdaten von Integrationen neu zu.
• Entfernen Sie nicht benötigten privilegierten Zugriff frühzeitig, wenn die Person ihn zur Erledigung ihrer Aufgaben nicht mehr braucht.
• Planen Sie die Rückgabe der Geräte und legen Sie fest, wie Geräte im Remote-Einsatz gesperrt oder zurückgeholt werden.
• Dokumentieren Sie Legal Holds, Aufbewahrungspflichten und berechtigte Zugriffe auf Geschäftsunterlagen.
• Bereiten Sie Kommunikation und Ausnahmebehandlung vor, ohne vertrauliche Informationen über die Beendigung offenzulegen.

Zum Austrittszeitpunkt

• Deaktivieren Sie die maßgebliche Beschäftigtenidentität oder die primäre Verzeichnisidentität.
• Widerrufen Sie Refresh-Tokens und aktive Sitzungen, soweit der Identitätsanbieter dies unterstützt.
• Deaktivieren oder entfernen Sie lokale und föderierte Anwendungszugriffe.
• Entfernen Sie privilegierte Rollen, Cloud-Abonnements, Datenbankrechte, Mitgliedschaften in der Quellcodeverwaltung und Rechte für den Fernzugriff.
• Deaktivieren Sie registrierte Geräte, wo Richtlinie und Risiko es erfordern.
• Widerrufen Sie VPN-Zugänge, Zertifikate, SSH-Schlüssel, API-Tokens und persönliche Zugriffstokens.
• Entfernen Sie den Zugang zu Gebäuden, Rechenzentren und Sperrbereichen.
• Rotieren Sie gemeinsam genutzte Zugangsdaten, die die Person kannte, wenn keine individuelle Zuordnung möglich war.
• Dokumentieren Sie für jede Maßnahme im Zielsystem Erfolg oder Fehlschlag.

Nach dem Austrittszeitpunkt

• Gleichen Sie die Identität mit den Zielsystemen ab; verlassen Sie sich nicht nur auf erfolgreiche Workflow-Rückmeldungen.
• Untersuchen Sie aktive Sitzungen oder anwendungsspezifische Tokens, die der zentrale Identitätsanbieter nicht widerrufen kann.
• Validieren Sie Übertragungen von Zuständigkeiten und geplante Jobs.
• Bestätigen Sie Geräterückgabe, Fernsperrung oder eine genehmigte Ausnahme.
• Überwachen Sie gemäß Richtlinie Anmeldeversuche und auffällige Nutzung.
• Stellen Sie den verantwortlichen Personen einen Ausnahmebericht bereit.
• Schließen Sie den Fall erst, wenn kritische Maßnahmen verifiziert sind und für offene Punkte Verantwortliche und Fristen feststehen.

Die Deaktivierung der Identität beendet nicht immer die Sitzung

Moderne Authentifizierung nutzt verschiedene Arten von Tokens und Sitzungen. Der zentrale Identitätsanbieter kann neue Anmeldungen blockieren und Tokens widerrufen, die er kontrolliert, aber Anwendungen können eigene Sitzungscookies führen. Die aktuellen Entra-Leitlinien von Microsoft erläutern, dass eine Anwendung das von ihr ausgestellte Sitzungstoken kontrolliert und dass Entra ID diese Anwendungssitzung nicht direkt widerrufen kann. Manche Anwendungen prüfen die Autorisierung häufig neu; andere kehren möglicherweise nicht zum Identitätsanbieter zurück, solange eine Sitzung gültig bleibt.

Für Microsoft Entra umfasst das dokumentierte Notfallvorgehen die Deaktivierung des Benutzerkontos und den Widerruf der Anmeldesitzungen. In hybriden Umgebungen können zusätzlich Maßnahmen im lokalen Active Directory, an registrierten Geräten und in verbundenen Diensten nötig sein. Diese Schritte sind Beispiele für eine einzelne Plattform, kein vollständiger Offboarding-Prozess für das gesamte Unternehmen.

Erstellen Sie einen Anwendungskatalog, der folgende Fragen beantwortet:

• Hängt die Anmeldung vom zentralen Identitätsanbieter ab?
• Was geschieht mit einer bestehenden Anwendungssitzung, nachdem das zentrale Konto deaktiviert wurde?
• Hat die Anwendung lokale Benutzerkonten, Wiederherstellungsmethoden oder API-Tokens?
• Kann die Organisation Sitzungen über eine API widerrufen?
• Wer ist für einen manuellen Ersatzweg verantwortlich, wenn der automatisierte Widerruf fehlschlägt?
• Wie wird der Endzustand abgeglichen?

Diese Informationen machen aus einer abstrakten Aufgabe „Benutzer deaktivieren“ eine testbare Kontrolle.

Zugriffe finden, die Identitätsanbieter nicht sehen

Der gefährlichste verbleibende Zugriff liegt oft außerhalb des primären Verzeichnisses. Beispiele sind:

• lokale Administrator- und Datenbankkonten;
• persönliche Zugriffstokens und Deploy Keys in der Quellcodeverwaltung;
• Cloud-Zugriffsschlüssel, Service Principals und Workload-Zugangsdaten;
• SaaS-Konten, die mit einer privaten oder zweiten E-Mail-Adresse angelegt wurden;
• Einträge in Passwort-Tresoren und gemeinsam genutzte Secrets;
• VPN-Profile und Client-Zertifikate;
• SSH-Schlüssel, die auf Server oder Netzwerkgeräte kopiert wurden;
• Sitzungen mobiler Anwendungen;
• Supportportale, die von Dienstleistern betrieben werden;
• physische Ausweise, Schlüssel und Besuchersysteme;
• delegierte Befugnisse für Postfächer, Kalender, Zahlungen und Genehmigungen.

Ein Anwendungsinventar ist nur nützlich, wenn es Systeme mit Verantwortlichen und Identitätsquellen verknüpft. Für Schatten-SaaS ist kein verlässliches Offboarding möglich, solange diese Dienste im Katalog fehlen. Die Ermittlung sollte Beschaffungsunterlagen, Single-Sign-on-Protokolle, Browser- oder Endgerätedaten (soweit rechtlich zulässig), Spesendaten, das Wissen der Führungskräfte und regelmäßige Zugriffsüberprüfungen nutzen. Ziel ist eine verhältnismäßige Abdeckung der geschäftlichen Zugriffe, keine Überwachung ohne Zweck.

Privilegierter Zugriff ändert die Reihenfolge

Austritte mit hohem Risiko erfordern ein Runbook, das kein Zeitfenster zwischen einer Vorwarnung der Person und dem Entzug offenlässt und verhindert, dass eine Kontrolle eine andere außer Kraft setzt. Wenn die Person die Identitätsinfrastruktur administriert, muss das Team, das das Offboarding durchführt, unabhängige Konten und verifizierte Break-Glass-Verfahren nutzen. Wenn die Person Deployment-Pipelines, Tresore oder Verschlüsselungsschlüssel kontrolliert, sollten Zuständigkeit und Wiederherstellung vor dem finalen Ereignis nachgewiesen sein.

Ziehen Sie für ausscheidende Personen mit privilegiertem Zugriff folgende Maßnahmen in Betracht:

1. dauerhafte, berechtigte (eligible) und zeitlich befristete Rollen ermitteln;
2. alternative Konten und Aliasnamen ermitteln;
3. die Zuständigkeit für Automatisierungen und Zugangsdaten übertragen;
4. nicht benötigte dauerhafte Privilegien gegebenenfalls schon vor dem Austritt entfernen;
5. den finalen Entzug über Verzeichnis, Cloud, Netzwerk, Endgeräte und physischen Zugang hinweg koordinieren;
6. Zugangsdaten rotieren, die sich nicht einzelnen Personen zuordnen lassen;
7. jüngste privilegierte Aktivitäten im Rahmen eines autorisierten Insider-Risiko- oder Sicherheitsprozesses überprüfen; und
8. den Notfallzugang nach Änderungen der Zuständigkeit testen.

Schaffen Sie keinen geheimen Parallelprozess ohne klare Verantwortlichkeit. Auch Fälle mit hohem Risiko brauchen eine autorisierte Einleitung, Funktionstrennung, Zeitstempel und einen überprüfbaren Eintrag.

Geschäftsdaten nach genehmigten Regeln übertragen

Offboarding sollte die Geschäftskontinuität sichern, ohne Führungskräften uneingeschränkten Zugriff auf persönliche oder irrelevante Inhalte zu geben. Legen Sie Regeln für Postfächer, Laufwerke, Chats, Kundendaten, Quellcode-Repositories, Notizbücher und lokale Dateien fest. Rechts-, Datenschutz- und Records-Management-Teams müssen unter Umständen entscheiden, was aufbewahrt wird, wer darauf zugreifen darf, zu welchem Zweck und wie lange.

Die Übertragung von Zuständigkeiten ist etwas anderes als die Beibehaltung von Zugriff. Ein Workflow kann die Zuständigkeit für ein gemeinsames Postfach, ein Repository oder eine Automatisierung übertragen und gleichzeitig das Konto der Person deaktivieren. Halten Sie das frühere Konto nicht nur deshalb aktiv, weil ein geplanter Job oder eine Dateifreigabe davon abhängt. Wandeln Sie anfällige persönliche Abhängigkeiten in gesteuerte Dienstidentitäten oder Ressourcen in Teamverantwortung um.

Die Löschung sollte eine separate, spätere Entscheidung sein. Eine sofortige Löschung kann Nachweise vernichten, Aufbewahrungspflichten verletzen oder die Wiederherstellung erschweren. Auch eine unbegrenzte Aufbewahrung kann gegen Richtlinien oder Datenschutzanforderungen verstoßen. Dokumentieren Sie die Aufbewahrungsfrist und das autorisierte Lösch- oder Anonymisierungsereignis.

Auch externe Mitarbeitende, befristet Beschäftigte und Dritte scheiden aus

Beim Zugriff externer Mitarbeitender versagt die Kontrolle oft, weil kein System ein verlässliches Endereignis liefert. Ein Sponsor beantragt den Zugriff zu Projektbeginn, aber niemand erfasst das tatsächliche Ende. Das Konto bleibt bestehen, bis eine regelmäßige Überprüfung es entdeckt.

Verlangen Sie für jede externe Identität einen Sponsor, einen Zweck und ein Ablaufdatum. Bevorzugen Sie einen automatischen Ablauf mit kontrollierter Verlängerung statt eines unbefristeten Zugriffs. Wenn der Dienstleister namentlich benanntes Personal einsetzt, verlangen Sie eine rechtzeitige Benachrichtigung, sobald sich dieses Personal ändert. Prüfen Sie Fernzugriff, privilegierten Zugriff und Zugriff auf Produktionssysteme genauer. Wenn ein Sponsor ausscheidet, weisen Sie die Identitäten, für die diese Person verantwortlich ist, neu zu oder setzen Sie sie aus.

Dasselbe Prinzip gilt für Personen im Praktikum, Leiharbeitskräfte, Ehrenamtliche und befristet Beschäftigte. Die Beschäftigungsart kann ändern, wer das Ereignis liefert; sie sollte nicht die Notwendigkeit von Zuständigkeit, Ablaufdatum und Nachweisen aufheben.

Gemeinsam genutzte Konten und Secrets müssen rotiert werden

Einzelne Konten lassen sich in der Regel deaktivieren. Gemeinsam genutzte Zugangsdaten erfordern eine andere Reaktion, weil die ausscheidende Person das Authentifizierungsmerkmal weiterhin kennen kann. NIST SP 800-53 AC-2 fordert einen Prozess, der die Authentifizierungsmerkmale gemeinsam genutzter Konten oder Gruppenkonten ändert, wenn Personen aus der Gruppe entfernt werden.

Die erste Verbesserung besteht darin, gemeinsam genutzte Konten zu reduzieren und personalisierte Identitäten, delegierten Zugriff oder ein System für privilegierten Zugriff zu nutzen, das die Nutzung zuordnet. Wo eine gemeinsame Nutzung notwendig bleibt, dokumentieren Sie die verantwortliche Person für das Konto, die berechtigten Personen, die Ausgabemethode, die erreichten Systeme, den Auslöser für die Rotation und die Nachweise. Das Offboarding sollte automatisch eine Rotationsaufgabe anlegen und prüfen, ob die nachgelagerten Systeme das neue Secret übernommen haben.

API-Schlüssel, Signaturschlüssel, Zertifikate und Wiederherstellungscodes erfordern dieselbe Überlegung. Wer eine Person aus einem Repository entfernt, macht einen kopierten Deployment-Schlüssel nicht ungültig. Wer eine Tresor-Mitgliedschaft entfernt, ändert damit kein Passwort, das die Person zuvor abgerufen hat.

Nachweise aufbauen, die vier Fragen beantworten

NIST SP 800-53 AC-2 verknüpft die Kontoverwaltung mit den Prozessen für die Beendigung und die Versetzung von Personal. Die Erweiterungen dieser Kontrolle behandeln automatisierte Kontoverwaltung, die Deaktivierung von Konten, automatisierte Audit-Aktionen und Personen mit hohem Risiko. NIST SP 800-53A übersetzt diese Gedanken in prüfbare Ziele, unter anderem, ob die für die Kontoverwaltung Zuständigen Benachrichtigungen über Beendigungen innerhalb festgelegter Fristen erhalten und ob Deaktivierung und Entfernung der Richtlinie folgen.

Ein Offboarding-Eintrag sollte folgende Fragen beantworten:

Wer hat das Ereignis autorisiert?

Bewahren Sie das maßgebliche HR-, Vertrags- oder Sicherheitsereignis, den Zeitpunkt des Wirksamwerdens, die Risikostufe und die autorisierte einleitende Person auf. Beschränken Sie sensible Angaben zum Grund auf den zuständigen Personenkreis.

Was gehörte zum Umfang?

Erfassen Sie die verbundenen Systeme, gefundenen Konten, privilegierten Rechte, Geräte, physischen Zugänge und Ressourcen, für die die Person verantwortlich war. Dokumentieren Sie bekannte Systeme, die außerhalb der Automatisierung liegen.

Was ist tatsächlich passiert?

Bewahren Sie für jede Maßnahme Anforderungszeitpunkt, Ausführungszeitpunkt, Antwort des Zielsystems, Wiederholungsversuche, die manuell verantwortliche Person und den Endzustand auf. Unterscheiden Sie „Workflow gesendet“ von „im Zielsystem verifiziert“.

Was ist offen geblieben?

Führen Sie Ausnahmen, geschäftliche Begründung, kompensierende Kontrollen, verantwortliche Person und Ablaufdatum auf. Ein Fall sollte nie als abgeschlossen gekennzeichnet werden, solange ein kritischer Fehler in einer unüberwachten Warteschlange liegt.

Den Prozess messen, ohne Abkürzungen zu belohnen

Sinnvolle Kennzahlen sind:

• Median und Maximum der Zeit vom wirksamen Beendigungszeitpunkt bis zum verifizierten Entzug, nach Risikostufe;
• Anteil der kritischen Maßnahmen in Zielsystemen, die innerhalb der Richtlinienvorgaben abgeschlossen wurden;
• Anzahl fehlgeschlagener oder manuell abgeschlossener Maßnahmen;
• Anzahl der Konten, die nach Abschluss des Falls entdeckt wurden;
• aktive Konten ohne maßgebliche Identität oder verantwortliche Person;
• privilegierte Rechte, die nach dem Austritt bestehen bleiben;
• Sitzungen oder Tokens, die die Deaktivierung des primären Kontos überdauern;
• gemeinsam genutzte Zugangsdaten, deren Rotation aussteht;
• Arbeitsmittel, die nicht bis zur vereinbarten Frist zurückgegeben wurden; und
• überfällige Übertragungen von Zuständigkeiten und Ausnahmen.

Belohnen Sie Teams nicht allein dafür, Tickets schnell zu schließen. Ein schneller Abschluss mit nicht verifizierten nachgelagerten Konten ist schlechter als ein transparenter Fall mit einer klar zugeordneten Ausnahme. Messen Sie Vollständigkeit und Nachweisqualität neben der Geschwindigkeit.

Den Austrittsprozess vor dem Ernstfall testen

Wählen Sie eine Testidentität, die eine realistische beschäftigte Person abbildet, und verbinden Sie sie mit repräsentativen Systemen. Spielen Sie einen geplanten Austritt durch und verifizieren Sie dann jede Ebene: Quellstatus, Verzeichnis, SaaS, Cloud, privilegierter Zugriff, Tokens, Geräte und physischer Zugang. Versuchen Sie, wo es gefahrlos möglich ist, eine autorisierte Testanmeldung nach dem Entzug. Prüfen Sie, ob der Nachweis für jemanden verständlich ist, der den Workflow nicht ausgeführt hat.

Wiederholen Sie die Tests nach größeren Änderungen an Integrationen, HR, Verzeichnis oder Anwendungen. Beziehen Sie Fehlerszenarien ein: ein nicht erreichbares Zielsystem, eine ungültige Kontozuordnung, ein API-Ratenlimit und ein System ohne automatisierten Konnektor. Der Workflow muss eine sichtbare Ausnahme und Eskalation erzeugen, statt stillschweigend einen Gesamterfolg zu melden.

Spielen Sie bei Prozessen mit hohem Risiko die Koordination zwischen HR, Sicherheit, IT und Facility Management als Planspiel durch. Klären Sie, wer das Ereignis einleiten darf, wer handeln kann, wenn die Person, die sonst administriert, selbst ausscheidet, und wie Notfall-Zugangsdaten kontrolliert werden.

Praktische Abschluss-Checkliste

Bestätigen Sie vor dem Schließen eines Austrittsfalls:

• die maßgebliche Identität zeigt den korrekten Beendigungsstatus und -zeitpunkt;
• neue Anmeldungen sind in zentralen und relevanten lokalen Identitätsspeichern blockiert;
• zentrale Refresh-Tokens und unterstützte Sitzungen sind widerrufen;
• anwendungseigene Sitzungen und lokale Konten sind behandelt;
• privilegierte, Notfall- und delegierte Rollen sind entfernt;
• VPN-Zugänge, Zertifikate, SSH-Schlüssel, API-Tokens und persönliche Zugriffstokens sind widerrufen;
• gemeinsam genutzte Authentifizierungsmerkmale, die die ausscheidende Person kannte, sind rotiert;
• Geräte sind zurückgegeben, deaktiviert, gesperrt oder durch eine genehmigte Ausnahme abgedeckt;
• der physische Zugang ist entzogen;
• Geschäftsunterlagen und Zuständigkeiten sind nach genehmigten Regeln übertragen;
• Dienstidentitäten und Automatisierungen haben verantwortliche Personen;
• die Zielsysteme sind mit dem erwarteten Zustand abgeglichen;
• Fehler und Ausnahmen haben Verantwortliche, Fristen und Eskalation; und
• der Nachweis wird gemäß dem geltenden Aufbewahrungsplan aufbewahrt.

Die Checkliste ist ein Abschlusskriterium, nicht der eigentliche Betriebsprozess. Erst Automatisierung, klare Zuständigkeiten und Abgleich machen jeden Haken glaubwürdig.

Wo Identity Governance hilft

Identity Governance kann maßgebliche Austrittsereignisse mit Konten und Berechtigungen verknüpfen, richtlinienbasierte Workflows ausführen, die Verantwortlichen der Anwendungen koordinieren, Genehmigungen und Ausnahmen protokollieren und Ergebnisse abgleichen. Besonders wertvoll ist das in heterogenen Umgebungen, in denen eine Person Zugriff auf Verzeichnisse, SaaS, Infrastruktur und Geschäftsanwendungen hat.

Die Plattform braucht trotzdem verlässliche Daten und klare Zuständigkeiten. Sie kann den Zugriff über ein unbekanntes Konto nicht entziehen, keine rechtmäßige Aufbewahrungsfrist ableiten und ohne Vorgaben der Verantwortlichen nicht entscheiden, wer für einen Geschäftsprozess zuständig sein soll. Die Implementierung sollte Lücken und Fehler sichtbar machen, statt sie hinter einem grünen Dashboard zu verbergen.

Das beste Ergebnis lässt sich einfach erklären: Die Organisation weiß, wann das Verhältnis endete, weiß, welche Zugriffe und Arbeitsmittel betroffen waren, hat die erforderlichen Maßnahmen abgeschlossen, den Endzustand verifiziert und kann den Nachweis vorlegen. Genau dadurch wird das Offboarding von Mitarbeitenden von einer administrativen Checkliste zu einer Sicherheits- und Governance-Kontrolle.

Vor der Wahl einer Plattform den Produktumfang prüfen

Verfolgen Sie in einem easyIGA-Pilotprojekt einen Austritt über die vorgesehenen Konnektoren bis zum resultierenden Kontozustand. Beziehen Sie eine nicht erreichbare Anwendung ein, damit Sie sehen, wie ein nicht abgeschlossener Entzug dokumentiert wird. Die Nachweisübersicht erläutert erfasste Genehmigungen, extern vergebene Zugriffe und fehlende Historie. Die Erfahrung unseres Teams aus mindestens 14 midPoint-Einführungen unterstützt die Gestaltung eines Prozesses, der den Entzug bis zum dokumentierten Ergebnis verfolgt.

Weiter mit der Umsetzung

Das übergeordnete Betriebsmodell erläutert unser Artikel darüber, was Identity Governance and Administration bedeutet. Für Finanzunternehmen lohnt sich ein Vergleich dieses Playbooks mit den Anforderungen von DORA an die Zugangskontrolle.

Quellen und Prüfvermerk

Produktumfang und redaktionelle Formulierungen aktualisiert am 24. September 2026. Die unten genannten Datumsangaben beziehen sich weiterhin auf die ursprüngliche Prüfung der Quellen.

Die Prüfung aller Quellen und der Bildlizenz erfolgte am 12. September 2026.

1. NIST SP 800-53 Revision 5 (including Release 5.2.0), Security and Privacy Controls for Information Systems and Organizations
2. NIST SP 800-53A Revision 5, assessment procedures
3. Revoke user access in an emergency in Microsoft Entra ID, Microsoft Learn
4. Microsoft Entra ID Governance deployment guide for employee lifecycle automation
5. Automate employee offboarding tasks with Lifecycle Workflows, Microsoft Learn
6. Delegierte Verordnung (EU) 2024/1774 der Kommission, Artikel 19 bis 21, EUR-Lex
7. Foto von Vitaly Gariev, Unsplash, frei nutzbar gemäß der Unsplash License

Dieser Artikel bietet Orientierung zu operativer Sicherheit und Identity Governance. Regeln zu Beschäftigung, Datenschutz, Aufzeichnungen und Überwachung unterscheiden sich je nach Rechtsraum. Klären Sie diese Anforderungen mit den zuständigen Verantwortlichen aus Recht, HR und Compliance.