Die vollständige IT-Offboarding-Checkliste: Jeder Schritt, jede App, keine verwaisten Konten

Eine vollständige, strukturierte IT-Offboarding-Checkliste - von SSO über Apps ohne SCIM, OAuth-Token, geteilte Zugangsdaten und MDM bis hin zu Lizenzrückgewinnung und Audit-Belegen - inklusive einer kopierfertigen Vorlage.

13 Min. Lesezeit · Zuletzt aktualisiert August 2026

Jeder Mitarbeiterabgang ist ein Sicherheitsereignis. Das Abschlussgespräch, die Rückgabe des Laptops, die Abschiedsnachricht im Slack-Kanal - all das spielt keine Rolle, solange die Zugriffe noch aktiv sind.

Branchenberichte zeigen, dass mehr als 30 % der Unternehmen länger als drei Tage benötigen, um nach dem Ausscheiden eines Mitarbeiters alle Systemzugriffe vollständig zu entziehen - und manche schließen diesen Prozess nie ab. Eine Umfrage von Beyond Identity ergab, dass 89 % der ehemaligen Mitarbeiter noch immer Zugriff auf mindestens eine Anwendung ihres früheren Arbeitgebers haben. Das ist kein Versagen der Richtlinien. Es ist ein strukturelles Problem - und genau das soll diese Checkliste beheben.

Onboarding und Offboarding in der Praxis

Kurz gezeigt: Wie Zugriffe am ersten Tag automatisch bereitstehen und beim Austritt in Sekunden wieder verschwinden.

Warum Offboarding Ihr risikoreichstes Identity-Ereignis ist

Wenn jemand das Unternehmen verlässt, hinterlässt er einen digitalen Fußabdruck, der sich über den gesamten Stack erstreckt: SSO-Sitzungen, Cloud-App-Zugangsdaten, VPN-Token, API-Keys, OAuth-Berechtigungen, Einträge in gemeinsamen Passwort-Tresoren und SaaS-Seats. Werden diese nicht ordnungsgemäß entzogen, entstehen verwaiste Konten - ein offenes Einfallstor für Insider-Bedrohungen, Datenlecks oder Audit-Verstöße.

Das Problem verschärft sich in SaaS-lastigen Umgebungen. Laut BetterClouds State of SaaS Report 2025 verwalten Unternehmen im Durchschnitt 106 SaaS-Anwendungen. Die meisten dieser Apps wurden von einzelnen Teams eingeführt - häufig außerhalb des Sichtfelds der IT. Wenn jemand das Unternehmen verlässt, weiß die IT nicht immer, welche Apps betroffen sind - SaaS-Offboarding ist daher strukturell unvollständig.

Hinzu kommt ein Zeitproblem. Nur 44 % der Unternehmen stellen sicher, dass alle Zugriffsrechte innerhalb von 24 Stunden nach dem Ausscheiden eines Mitarbeiters entzogen werden. In dieser Lücke passieren Sicherheitsvorfälle. Kompromittierte Zugangsdaten waren laut Verizons DBIR 2025 für 22 % aller Sicherheitsvorfälle verantwortlich.

Die SSO-only-Falle

Viele Teams glauben, dass das Deaktivieren eines SSO-Kontos gleichbedeutend mit dem Entzug aller Zugriffe ist. Das stimmt nicht. Das Deaktivieren eines SSO-Kontos beendet weder bestehende SaaS-Sitzungen noch entfernt es app-spezifische Berechtigungen - API-Keys, gemeinsame Passwörter und lokal gespeicherte Token überleben eine IdP-Deaktivierung vollständig. SSO-Sperrung entfernt einen Authentifizierungspfad; sie schließt nicht den nachgelagerten Zugriffsgraphen.

Das Widerrufen von OAuth-Token und nicht verwaltete SaaS-Apps, die außerhalb der IT beschafft wurden, sind die am häufigsten übersehenen Offboarding-Schritte - sie liegen außerhalb der Reichweite des Identity Providers und erfordern entweder manuelle Checklisten oder eine Orchestrierungsschicht, die Apps jenseits der SSO-Föderation erfasst. Die Lücke bleibt unsichtbar, bis ein Audit oder ein Sicherheitsvorfall sie ans Licht bringt.

Das ist das Long-Tail-Problem: die 60-80 % Ihres Stacks, die kein SCIM unterstützen, nicht mit Ihrem IdP föderiert sind und beim Deaktivieren eines Kontos in Okta oder Entra ID nicht automatisch deprovisioniert werden.

Offboarding in 30 Sekunden abschließen

Die vollständige IT-Offboarding-Checkliste

Verwenden Sie diese Liste als operative Vorlage. Gruppieren Sie jeden Punkt nach Phase, weisen Sie Verantwortliche zu und erfassen Sie Zeitstempel für jede Aktion.

Phase 1 - Auslöser und Timing

Die Offboarding-Uhr beginnt in dem Moment, in dem HR einen Abgang bestätigt - nicht wenn die IT sich darum kümmert.

Verbinden Sie Ihr HRIS mit Ihrer IGA-Plattform. Ein Kündigungsereignis in Workday, BambooHR oder SuccessFactors sollte den Offboarding-Workflow automatisch auslösen. Manuelle Übergaben erzeugen Verzögerungen - und Verzögerungen sind die Schwachstelle.
Streben Sie eine taggleiche Sperrung sensibler Systeme an. Für privilegierte User, Administratoren und alle Personen mit Zugriff auf Finanz-, Gesundheits- oder Kundendaten gilt: innerhalb einer Stunde. Compliance-Frameworks sind konkret: FedRAMP PS-4 setzt ein 4-Stunden-Fenster; SOC 2 CC6.1 und ISO 27001 Anhang A 6.5 behandeln die taggleiche Sperrung als Mindeststandard.
Unfreiwillige Kündigungen gesondert kennzeichnen. Bei Entlassungen oder fristlosen Kündigungen ist das Zeitfenster enger. Eine Analyse von Cyberhaven aus dem Jahr 2024 zeigte einen Anstieg riskanter Datenexfiltrations-Aktivitäten um 720 % kurz vor der Ankündigung von Entlassungen. Entziehen Sie den Zugriff vor - oder gleichzeitig mit - der Benachrichtigung.
Nicht bis zum letzten Tag warten. Wenn das Abgangsdatum im Voraus bekannt ist, bereiten Sie den Workflow vor, damit die Ausführung sofort erfolgen kann.

Phase 2 - SSO und alle nachgelagerten Apps sperren

Deaktivieren Sie das Benutzerkonto im Identity Provider (Okta, Entra ID, Google Workspace).
Beenden Sie alle aktiven SSO-Sitzungen - nicht nur künftige Anmeldungen.
Arbeiten Sie jede App in Ihrem Stack durch, nicht nur die mit SSO föderiert sind. Kennzeichnen Sie Apps nach Unterstützungsgrad: SCIM-fähig, API-fähig, nur Admin-Konsole oder nicht unterstützt. Jede Kategorie erfordert eine andere Sperrmethode.
Für Apps ohne SCIM: Nutzen Sie direkten Admin-Konsolen-Zugriff, API-Aufrufe oder ein geregeltes Runbook mit namentlich benannten Verantwortlichen und einer obligatorischen Abschlussbestätigung.
Entfernen Sie den User aus allen Gruppen, Rollen und Berechtigungssätzen - nicht nur das übergeordnete Konto.

SSO-Offboarding deckt nur die Apps ab, die mit Ihrem IdP verbunden sind – in der Regel 20–40 % Ihres Stacks. Die verbleibenden Apps erfordern eine separate, explizite Sperrung. Wenn Ihr Offboarding-Prozess beim IdP endet, haben Sie eine strukturelle Lücke – kein abgeschlossenes Offboarding.

Phase 3 - Konten deaktivieren (nicht löschen)

Deaktivieren, nicht löschen. Das sofortige Löschen von Konten vernichtet den Audit-Trail und kann Dateneigentumsketten unterbrechen. Zuerst deaktivieren; löschen erst nach Ablauf der in Ihrer Richtlinie festgelegten Aufbewahrungsfrist.
Sperren Sie Konten in jeder App, auf die der User direkten Zugriff hatte - einschließlich Apps, in denen möglicherweise ein lokales Konto außerhalb von SSO erstellt wurde.
Bestätigen Sie den Kontostatus in jedem System. Ein deaktiviertes Konto im IdP garantiert kein deaktiviertes Konto in der nachgelagerten App.

Phase 4 - Geteilte Zugangsdaten, API-Keys und Service-Account-Secrets rotieren

Das ist der Schritt, den die meisten Offboarding-Checklisten übersehen - und der am wahrscheinlichsten im Nachhinein ausgenutzt wird.

Identifizieren Sie alle geteilten Zugangsdaten, die der ausscheidende Mitarbeiter kennen könnte: Passwort-Tresor-Einträge, Team-Zugangsdaten, Service-Account-Passwörter, SSH-Keys, Cloud-Provider-Zugriffsschlüssel.
Rotieren Sie alle davon. Den Tresor-Zugang zu entziehen reicht nicht aus, wenn der Mitarbeiter das Passwort bereits kennt.
Identifizieren Sie alle API-Keys, Service-Accounts oder Automatisierungs-Zugangsdaten, die der Mitarbeiter erstellt hat oder auf die er Zugriff hatte. Prüfen Sie, ob jeder noch benötigt wird. Falls ja: Eigentümerschaft übertragen und rotieren. Falls nein: stilllegen.
OWASPs Non-Human Identities Top 10 (2025) stuft Improper Offboarding auf Position NHI1:2025 ein - das höchste Einzelrisiko im gesamten Framework - definiert als unzureichende Deaktivierung von Service-Accounts, API-Keys, OAuth-Token und Zertifikaten, wenn die Person, die sie verwaltet hat, das Unternehmen verlässt.
Die Cloud Security Alliance stellte fest, dass nur 20 % der Unternehmen formale Prozesse für das Offboarding und den Entzug von API-Keys haben. Wenn Sie keinen Prozess haben, fangen Sie hier an.

Phase 5 - OAuth-Berechtigungen, aktive Sitzungen und Token widerrufen

MFA stoppt kein aktives Token. Sobald ein Token ausgestellt wurde, funktioniert es als Bearer-Credential - wer es besitzt, kann es nutzen, unabhängig davon, ob das zugrunde liegende Konto deaktiviert wurde.

Erfassen Sie alle OAuth-Berechtigungen, die der User autorisiert hat - Integrationen, die er verbunden hat, Drittanbieter-Apps, die er genehmigt hat, Automatisierungstools, die er verknüpft hat.
Widerrufen Sie alle aktiven OAuth-Token und Refresh-Token. Refresh-Token können außerhalb von SSO-Kontrollen unbegrenzt bestehen bleiben.
Beenden Sie alle aktiven Browser-Sitzungen und Session-Cookies.
Prüfen Sie Integrationen, die der User im Namen des Teams eingerichtet hat (Zapier-Workflows, Slack-App-Verbindungen, GitHub-Actions-Token) - diese überleben die Kontodeaktivierung und laufen weiter.

Der Salesloft-Drift-Vorfall 2025 zeigte, wie ein kompromittiertes OAuth-Token über nachgelagerte Integrationen die Daten von mehr als 700 Unternehmen betraf - MFA wurde nie ausgelöst, weil der Authentifizierungsmoment bereits bei der ursprünglichen Autorisierung der Integration stattgefunden hatte.

Phase 6 - Geräte einziehen und MDM-Aktionen auslösen

Bestätigen Sie, dass alle unternehmenseigenen Geräte zurückgegeben oder per MDM remote gelöscht wurden (Jamf, Intune, Kandji).
Für Remote-Mitarbeiter: Remote-Löschung vor oder unmittelbar nach dem letzten Arbeitstag einleiten.
Gerätezertifikate widerrufen und das Gerät aus der MDM-Registrierung entfernen.
Für BYOD: Gerät aus dem MDM abmelden und bestätigen, dass Corporate-Data-Container gelöscht wurden.
VPN-Zertifikate widerrufen und den User aus VPN-Gruppen entfernen.

Phase 7 - SaaS-Lizenzen zurückfordern und neu zuweisen

Offboarding ist auch ein Kosteneinsparungsereignis. Verschwendete SaaS-Lizenzen ausgeschiedener Mitarbeiter können bis zu 30 % der gesamten SaaS-Lizenzkosten ausmachen.

Identifizieren Sie jeden bezahlten Seat, den der ausscheidende Mitarbeiter innehatte - einschließlich Long-Tail-Tools wie Figma-Viewer, Loom Pro, Linear-Contributor-Zugänge und Vercel-Teams, die selten zurückgefordert werden.
Geben Sie jeden Seat sofort frei oder weisen Sie ihn neu zu. Warten Sie nicht bis zum nächsten Verlängerungszyklus.
Hinweis: Viele SaaS-Apps stellen deaktivierte oder gesperrte Konten weiterhin in Rechnung, als wären sie aktiv. Deaktivieren ist nicht dasselbe wie den Seat freigeben - prüfen Sie das Abrechnungsmodell jedes Anbieters.
Ein strukturierter Offboarding-Prozess mit zeitnaher Lizenzrückgewinnung kann die SaaS-Ausgaben mittelgroßer Unternehmen jährlich um 15-30 % senken.

Phase 8 - Daten und Dateieigentümerschaft übertragen

Übertragen Sie die Eigentümerschaft von Google Drive-, OneDrive-, Notion- oder Confluence-Inhalten auf den Vorgesetzten des Mitarbeiters oder eine benannte Nachfolgeperson.
Weisen Sie GitHub-Repositories, Figma-Dateien, Linear-Projekte und alle anderen Arbeitsartefakte, bei denen der User Eigentümer war, neu zu.
Bewahren Sie Daten gemäß Ihrer Aufbewahrungsrichtlinie auf - löschen Sie keine Dateien, bevor die Eigentümerschaft bestätigt und die Aufbewahrungsfrist abgelaufen ist.
Dokumentieren Sie, was übertragen wurde, an wen und wann.

Phase 9 - Postfach, Weiterleitung und Kalender verwalten

Richten Sie eine Abwesenheitsantwort mit dem entsprechenden Ansprechpartner ein.
Konfigurieren Sie die E-Mail-Weiterleitung an den Vorgesetzten oder ein gemeinsames Postfach für die definierte Aufbewahrungsfrist.
Weisen Sie Kalendertermine und wiederkehrende Meetings neu zu.
Archivieren oder löschen Sie das Postfach nach Ablauf der Aufbewahrungsfrist gemäß Ihrer Datenaufbewahrungsrichtlinie.
Entfernen Sie den User aus Verteilerlisten und gemeinsamen Postfächern.

Phase 10 - Audit-Belege erfassen

Ein Offboarding, das nicht dokumentiert wurde, hat nicht stattgefunden - zumindest nicht aus Sicht Ihrer Auditoren.

Protokollieren Sie jede durchgeführte Aktion: wer sie ausgeführt hat, welches System betroffen war, was das Ergebnis war und wann.
Erfassen Sie Zeitstempel für jeden Sperrschritt - nicht nur einen einzelnen "Offboarding abgeschlossen"-Ticket-Abschluss.
ISO/IEC 27001, SOC 2 und das NIST Cybersecurity Framework 2.0 verlangen alle Nachweise über die zeitnahe Sperrung von Zugriffen; ein Offboarding-Ticket, das nur einen IdP-Zeitstempel enthält, ist nach modernen Auditor-Erwartungen in der Regel nicht ausreichend.
Speichern Sie Belege in einem unveränderlichen, abfragbaren System. Audit-Logs, die bearbeitet werden können, sind keine Audit-Logs.
Bewahren Sie Belege für den Zeitraum auf, der von Ihren anwendbaren Frameworks vorgeschrieben wird (SOC 2, ISO 27001, DSGVO, HIPAA usw.).

Manuelles vs. automatisiertes Offboarding

Manuelles vs. automatisiertes Offboarding: Wichtige Kennzahlen

Manuelles Offboarding scheitert in den meisten Stacks an denselben Stellen: HRIS-Verzögerungen, SCIM-Abdeckungslücken, Sequenzierungsfehler, offline Geräte und abteilungsübergreifende Übergaben, die nie protokolliert werden. Jede Ebene geht davon aus, dass das nächste System den Rest erledigt hat - so wird aus einem sauber geschlossenen Ticket ein unübersichtlicher Audit-Trail.

BetterClouds State of SaaS Report 2025 ergab, dass 33 % der IT-Teams noch immer mehr als 24 Stunden benötigen, um Offboarding-Schritte abzuschließen - und dabei aktive Sitzungen und Lizenzen offenlassen. Unternehmen mit automatisierten Offboarding-Prozessen reduzieren Sicherheitsvorfälle um 34 %.

Automatisierung schließt nicht nur die zeitliche Lücke. Sie schließt die Abdeckungslücke - und stellt sicher, dass jede App im Stack, einschließlich des Long-Tails ohne SCIM, im selben Workflow mit demselben Beweisstandard behandelt wird.

Das Problem mit Auftragnehmern und Nicht-HRIS-Beschäftigten

Standard-JML-Automatisierung wird durch HR-System-Ereignisse ausgelöst. Auftragnehmer sind nicht im HRIS erfasst. Es wird nie ein Kündigungsereignis weitergeleitet - der Zugriff des Auftragnehmers bleibt daher unbegrenzt bestehen, weil kein automatisiertes System weiß, dass das Engagement beendet wurde.

Das ist eine strukturelle Lücke, kein Prozessfehler. Die Tools, die die meisten Teams verwenden, wurden nicht dafür entwickelt, dieses Problem zu lösen. Auftragnehmer, Freelancer und projektbasierte Mitarbeiter benötigen einen eigenen geregelten Lifecycle: einen definierten Sponsor, ein explizites Enddatum und einen Offboarding-Auslöser, der nicht von einem HRIS-Ereignis abhängt.

Lesen Sie unseren Leitfaden zum Onboarding und Offboarding von Auftragnehmern für den vollständigen Workflow und Den vollständigen Leitfaden zu Joiner-Mover-Leaver, um zu erfahren, wie Sie einen Lifecycle aufbauen, der jeden Identitätstyp abdeckt - menschlich, nicht-menschlich und alles dazwischen.

Ungenutzte Lizenzen finden

Schätzen Sie Ihr Offboarding-Risiko mit diesem Widget

Die Offboarding-Checklisten-Vorlage (kopierfertig)

Verwenden Sie dies als Ausgangspunkt. Passen Sie es an Ihren Stack an, weisen Sie jedem Abschnitt Verantwortliche zu und fügen Sie es Ihrem ITSM oder Runbook hinzu.

MITARBEITER-OFFBOARDING-CHECKLISTE
Mitarbeiter: _______________  Letzter Arbeitstag: _______________
Initiiert von: _______________  Datum/Uhrzeit: _______________

PHASE 1 - AUSLÖSER & TIMING
[ ] HRIS-Kündigungsereignis bestätigt
[ ] Offboarding-Workflow ausgelöst (automatisiert oder manuell)
[ ] Kennzeichnung als unfreiwillige Kündigung gesetzt (falls zutreffend)
[ ] Sperrzeitfenster für sensible Systeme bestätigt (Ziel: taggleich / ≤1 Std. für privilegierte User)

PHASE 2 - SSO & SPERRUNG NACHGELAGERTER APPS
[ ] IdP-Konto deaktiviert (Okta / Entra ID / Google Workspace)
[ ] Alle aktiven SSO-Sitzungen beendet
[ ] SCIM-verbundene Apps deprovisioniert (Liste: _______________)
[ ] Apps ohne SCIM über Admin-Konsole gesperrt (Liste: _______________)
[ ] User aus allen Gruppen, Rollen und Berechtigungssätzen entfernt

PHASE 3 - KONTO DEAKTIVIEREN (NICHT LÖSCHEN)
[ ] Konten in allen nachgelagerten Systemen deaktiviert
[ ] Lokale/direkte Konten identifiziert und deaktiviert
[ ] Kontostatus in jedem System bestätigt (nicht angenommen)

PHASE 4 - GETEILTE ZUGANGSDATEN & API-KEYS
[ ] Passwort-Tresor-Zugang entzogen
[ ] Alle dem Mitarbeiter bekannten geteilten Zugangsdaten - rotiert
[ ] Vom Mitarbeiter erstellte oder genutzte API-Keys - inventarisiert
[ ] Noch benötigte API-Keys - Eigentümerschaft übertragen + rotiert
[ ] Nicht mehr benötigte API-Keys - stillgelegt
[ ] Service-Accounts geprüft und Eigentümerschaft übertragen

PHASE 5 - OAUTH-BERECHTIGUNGEN, SITZUNGEN & TOKEN
[ ] Alle vom User autorisierten OAuth-Berechtigungen - erfasst
[ ] OAuth-Access-Token und Refresh-Token - widerrufen
[ ] Aktive Browser-Sitzungen und Session-Cookies - beendet
[ ] Vom User eingerichtete Team-Integrationen - geprüft und neu zugewiesen

PHASE 6 - GERÄTE & MDM
[ ] Unternehmensgeräte zurückgegeben oder Remote-Löschung eingeleitet
[ ] Gerät aus MDM-Registrierung entfernt
[ ] BYOD-Corporate-Data-Container gelöscht
[ ] VPN-Zertifikate widerrufen, User aus VPN-Gruppen entfernt

PHASE 7 - LIZENZRÜCKGEWINNUNG
[ ] Alle bezahlten SaaS-Seats identifiziert (einschließlich Long-Tail-Apps)
[ ] Seats sofort freigegeben oder neu zugewiesen
[ ] Abrechnungsauswirkungen mit jedem Anbieter bestätigt

PHASE 8 - DATEN & DATEIEIGENTÜMERSCHAFT
[ ] Drive/Cloud-Dateieigentümerschaft übertragen
[ ] Repositories, Projekte und Arbeitsartefakte neu zugewiesen
[ ] Daten gemäß Aufbewahrungsrichtlinie gesichert

PHASE 9 - POSTFACH & KALENDER
[ ] Abwesenheitsantwort konfiguriert
[ ] E-Mail-Weiterleitung eingerichtet (an Vorgesetzten oder gemeinsames Postfach)
[ ] Kalendertermine neu zugewiesen
[ ] Mitgliedschaft in Verteilerlisten entfernt

PHASE 10 - AUDIT-BELEGE
[ ] Zeitstempel pro Schritt protokolliert (wer, was, wann, Ergebnis)
[ ] Belege in unveränderlichem Audit-Log gespeichert
[ ] Offboarding-Nachweis gemäß Compliance-Framework-Anforderungen aufbewahrt
[ ] Offboarding durch IT-Verantwortlichen als abgeschlossen bestätigt: _______________

So sieht automatisierte Deprovisionierung in der Praxis aus

Ein gut aufgebauter Offboarding-Workflow beginnt nicht mit einem Ticket. Er beginnt mit einem HRIS-Ereignis - einem Kündigungsdatensatz in Workday oder BambooHR - das automatisch eine richtliniengesteuerte Sequenz auslöst: IdP-Deaktivierung, SCIM-Deprovisionierung für föderierte Apps, API-basierte Sperrung für Apps ohne SCIM, OAuth-Token-Bereinigung, Sitzungsbeendigung und Lizenzfreigabe. Jeder Schritt wird mit einem Zeitstempel und einem Abschlussstatus protokolliert. Der Audit-Trail ist unveränderlich und exportierbar.

Genau das macht Iden - über Ihren gesamten Stack hinweg, einschließlich der Apps, die weder SCIM noch APIs unterstützen. Nicht nur die 20-40 % der Apps, die Ihr SSO abdeckt. Alle.

Sicherheitslücken beim Offboarding schließen

Fazit

Offboarding ist kein HR-Prozess mit einer angehängten IT-Checkliste. Es ist ein sicherheitskritischer, zugriffsorientierter Vorgang, der Präzision auf jeder Ebene Ihres Stacks erfordert - SSO, nachgelagerte Apps, OAuth-Berechtigungen, geteilte Zugangsdaten, Geräte, Lizenzen und Audit-Belege.

Die Lücke zwischen "wir haben das Konto deaktiviert" und "der Zugriff ist vollständig entzogen" ist der Ort, an dem Sicherheitsvorfälle entstehen. Diese Lücke zu schließen erfordert die Abdeckung jeder App - nicht nur der Apps, die Ihr IdP kennt - und eine Automatisierung, die in dem Moment greift, in dem HR einen Abgang bestätigt, nicht wenn die IT sich darum kümmert.

Manuelle Checklisten sind ein Ausgangspunkt. Automatisierte, vollständige Stack-Deprovisionierung ist der Standard.