Der vollständige Leitfaden zum Identity Lifecycle Management (ILM)

Hinter jedem Datenleck steckt eine Zugriffsgeschichte. Ein Konto, das längst hätte entzogen werden sollen. Ein Rollenwechsel, der neue Berechtigungen hinzufügte, die alten aber nie entfernte. Ein Service-Account, an dessen Erstellung sich niemand mehr erinnert. Identity Lifecycle Management (ILM) ist die Disziplin, die diese Lücken schließt - und die meisten Unternehmen decken davon nur die Hälfte ab.

Dieser Leitfaden zeigt das vollständige Bild: Was ILM ist, wie jede Phase funktioniert, wo Programme regelmäßig scheitern und was es braucht, um den Lifecycle über alle Apps im Stack zu automatisieren - einschließlich derer, die kein SCIM unterstützen.

---

Onboarding und Offboarding in der Praxis

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

---

Was ist Identity Lifecycle Management?

Identity Lifecycle Management (ILM) ist der automatisierte, zentral gesteuerte Prozess zur Verwaltung von User-Identities und deren Zugriffsrechten über alle Unternehmensressourcen und Applikationen hinweg - von der Erstellung bis zur Deaktivierung. Es ist die operative Grundlage, die digitale Zugriffe mit der Unternehmensrealität in Einklang hält: Wer ist im Unternehmen tätig, welche Rolle hat diese Person, und benötigt sie noch die Zugriffe, die sie besitzt?

ILM ist Teil des übergeordneten Frameworks für Identity Governance and Administration (IGA). IGA deckt die Richtlinienebene ab - wer sollte Zugriff haben, nach welchen Regeln, und wie wird das auditiert. ILM ist die Ausführungsebene - die Workflows, Konnektoren und Automatisierungen, die diese Richtlinien / Policies in jedem System Wirklichkeit werden lassen. Effektive IGA ist ohne ILM als Fundament nicht möglich.

Der Lifecycle umfasst drei Kernphasen - Joiner, Mover und Leaver - sowie begleitende Prozesse: Zugriffsanfragen, regelmäßige Zertifizierung und Credential-Lifecycle-Management. Jede Phase hat ihre eigenen Fehlermuster, und bei den meisten Unternehmen ist mindestens eine davon ernsthaft defekt.

---

Die Joiner-Phase: Provisionierung aus einer autoritativen Quelle

Die Joiner-Phase beginnt in dem Moment, in dem ein New Hire im HRIS bestätigt wird. Das HRIS - Workday, BambooHR, HiBob oder ein vergleichbares System - ist die autoritative Quelle: das System of Record, das der Identity-Plattform mitteilt, wer existiert, welche Rolle diese Person innehat und welchem Fachbereich sie angehört.

Ein gut konzipierter Joiner-Workflow erledigt Folgendes automatisch:

• Liest den New-Hire-Datensatz aus dem HRIS per Trigger (kein nächtlicher Batch-Lauf)
• Legt die Identität im Verzeichnis an (Active Directory, Entra ID, Okta)
• Ordnet die Rolle einem vordefinierten Birthright-Zugriff zu - dem Basis-Set an Apps und Berechtigungen, das jede Person in dieser Rolle ab dem ersten Tag erhält
• Provisioniert Konten in allen verbundenen Applikationen, nicht nur in den SCIM-fähigen
• Protokolliert jede Aktion mit Zeitstempel für Audit-Zwecke

Birthright-Zugriff bezeichnet das Prinzip, dass bestimmte Zugriffe automatisch und rollengerecht gewährt werden - kein Ticket erforderlich. Eine Ingenieurin erhält GitHub, Jira und die Dev-Slack-Channels. Ein Finance-Analyst bekommt die ERP-Leserolle und das Spesenwerkzeug. Birthright-Zugriff reduziert Reibung am ersten Tag und verhindert die Ad-hoc-Provisionierung, die zu Inkonsistenzen führt.

Das typische Fehlermuster hier ist mangelnde Abdeckung. Die meisten SSO- und SCIM-basierten Tools provisionieren die Apps, mit denen sie verbunden sind, und überlassen den Rest manuellen Prozessen. Wenn der Stack Notion, Figma, Linear oder andere Long-Tail-SaaS-Tools ohne SCIM-Konnektor enthält, werden diese Konten weiterhin per Ticket angelegt - was Verzögerungen, Inkonsistenz und fehlende Audit-Trails bedeutet.

---

Die Mover-Phase: Die schwierigste und am meisten vernachlässigte Phase

Wenn Joiner und Leaver die Klammern sind, ist die Mover-Phase das unordentliche Mittelstück - und genau hier scheitern die meisten Identity-Programme still und leise.

Ein Mover-Ereignis tritt auf, wenn ein Mitarbeitender Rolle, Team, Fachbereich oder Vorgesetzte wechselt, dabei aber im Unternehmen bleibt. Es ist das häufigste Lifecycle-Ereignis nach Volumen und der wichtigste Treiber von Privilege Creep: der schrittweisen Anhäufung von Zugriffsrechten, die über den aktuellen Aufgabenbereich einer Person hinausgehen.

So funktioniert der Mechanismus: Wenn jemand vom Engineering ins Produktmanagement wechselt, provisioniert die IGA-Plattform (idealerweise) die Zugriffe der neuen Rolle. Aber die alten Engineering-Berechtigungen - GitHub-Repo-Zugriff, Dev-Environment-Zugangsdaten, CI/CD-Pipeline-Rollen - bleiben häufig aktiv. Niemand hat sie explizit entzogen. Die alte Führungskraft ging davon aus, dass die IT sich darum kümmert. Die IT ging davon aus, dass die neue Führungskraft die Änderung anfordert. Das Ergebnis: Der Mover hält nun die Vereinigungsmenge aller Rollen, die er je innehatte.

Mover - Mitarbeitende, die Rollen, Teams oder Fachbereiche wechseln, dabei aber im Unternehmen bleiben - erzeugen den größten blinden Fleck bei der Berechtigungsanhäufung. Joiner starten mit 8-15 Apps auf Rollen-Baseline; Mover setzen nicht zurück. Sie akkumulieren in beide Richtungen gleichzeitig.

Mover sind der mit Abstand größte Treiber von Privilege Creep in jedem Unternehmen. Und das Risiko wächst mit der Betriebszugehörigkeit: Je länger jemand im Unternehmen ist, desto mehr Rollen hat er bekleidet und desto mehr Zugriffe hat er über Systeme angesammelt, die niemand jemals auditiert hat.

So sieht ein korrekter Mover-Workflow aus:

1. Das HRIS löst ein Rollenwechsel-Ereignis aus (Änderung von Fachbereich, Titel, Vorgesetzten oder Kostenstelle)
2. Die IGA-Plattform ordnet die neue Rolle dem vordefinierten Berechtigungs-Set zu
3. Die Berechtigungen der neuen Rolle werden provisioniert
4. Die Berechtigungen der alten Rolle werden explizit entzogen - nicht davon ausgegangen, dass das anderswo erledigt wird
5. Zugriffe, die weder zur alten noch zur neuen Rollen-Baseline passen, werden zur Manager-Zertifizierung markiert
6. Das gesamte Delta wird protokolliert

Ein gut konzipierter Mover-Workflow empfängt die Rollenänderung aus dem HR-System, ordnet die neue Rolle einem vordefinierten Berechtigungs-Set zu, provisioniert diese Entitlements und entzieht die Berechtigungen der vorherigen Rolle. Der gesamte Prozess ist protokolliert, auditierbar und erfordert keinen manuellen Eingriff des Help Desks.

Der Grund, warum das in der Praxis selten passiert: Die meisten IGA-Tools sind besser darin, Zugriffe hinzuzufügen, als sie zu entfernen. Provisionierung ist ein Create-Vorgang; Deprovisionierung erfordert zu wissen, was in jedem verbundenen System zu entfernen ist - und zwar mit der Gewissheit, dass das Entfernen nichts kaputt macht. Das ist schwieriger - und deshalb ist die Mover-Phase der Ort, an dem sich Zugriffe anhäufen.

---

Die Leaver-Phase: Deprovisionierung mit Geschwindigkeit

Die Leaver-Phase ist die sicherheitskritischste und zeitkritischste. Wenn ein Mitarbeitender das Unternehmen verlässt - freiwillig oder nicht -, ist jede Minute fortbestehenden Zugriffs ein Risikofenster.

Verwaiste Konten sind die ungesicherten Hintertüren des Unternehmens. Sie verfügen über gültige Zugangsdaten, oft mit erhöhten Berechtigungen, aber keinen aktiven Eigentümer. Angreifer wissen das und nutzen es aus. Reale Beispiele sind der Colonial-Pipeline-Angriff, bei dem Angreifer über einen inaktiven VPN-Account eindrangen, sowie ein Fertigungsunternehmen, das 2025 durch Akira-Ransomware über einen "Ghost"-Drittanbieter-Account kompromittiert wurde, der nicht deaktiviert worden war.

Ein führender Identity-Governance-Bericht aus dem Jahr 2026 ergab, dass 89 % der CISOs in Großunternehmen verwaiste Konten als eines der drei größten SaaS-Security-Governance-Probleme einstufen - gleichauf mit Privilege Escalation und Shadow-IT.

Ein vollständiger Leaver-Workflow muss:

• Sofort beim HRIS-Kündigungsereignis ausgelöst werden - nicht bei einem nächtlichen Sync
• Das SSO/IdP-Konto deaktivieren (was den Verbundzugriff auf SCIM-Apps unterbricht)
• Zusätzlich jede Nicht-SCIM-App direkt deprovisionieren - weil die SSO-Session-Revokation Apps mit eigenem Login nicht erreicht
• API-Keys, Tokens und geteilte Zugangsdaten des Users entziehen
• Eigentümerschaft von Dateien, Repos und geteilten Ressourcen übertragen
• Das Konto vor der Löschung für die Audit-Aufbewahrung archivieren
• Die vollständige Deprovisionierungskette mit Zeitstempeln protokollieren

Die Lücke, die die meisten Tools hinterlassen: SSO-basierte Deprovisionierung funktioniert nur für Apps, die SSO erzwingen. Wenn ein User einen direkten Login zu einer App hat - oder wenn die App aktive Sessions bei IdP-Deaktivierung nicht beendet -, bleibt der Zugriff bestehen. Bei einem Stack mit 50 Apps, von denen 20 SCIM unterstützen und 30 nicht, lässt ein reines SCIM-Offboarding-Tool 30 Türen offen.

---

Begleitende Prozesse: Zugriffsanfragen, Zertifizierung und Credential-Lifecycle

ILM beschränkt sich nicht auf Joiner-Mover-Leaver. Drei begleitende Prozesse vervollständigen das Bild:

Zugriffsanfragen decken den Zugriff ab, den Birthright-Zugriff nicht umfasst - projektspezifische Tools, erhöhte Berechtigungen, temporärer Zugriff für Auftragnehmer. Ein geregelter Zugriffsanfrageprozess leitet Anfragen an geeignete Genehmiger weiter, setzt Zeitlimits für temporäre Zugriffe durch und protokolliert jede Gewährung und Ablehnung.

Regelmäßige Access-Reviews (auch Zugangszertifizierungen oder Rezertifizierungen genannt) sind der planmäßige Prozess, bei dem Führungskräfte oder Ressourceneigentümer bestätigen, dass bestehende Zugriffe noch angemessen sind. Regelmäßige, verpflichtende Überprüfung von User-Entitlements durch Führungskräfte - mit automatischer Revokation bei fehlender Zertifizierung - ist der Mechanismus, der Drift zwischen Lifecycle-Ereignissen erkennt: Zugriffe, die sich durch Projektgenehmigungen, Ausnahmeregelungen und Mover-Lücken angesammelt haben.

Credential-Lifecycle umfasst Passwörter, MFA-Faktoren, API-Keys, Zertifikate und Tokens. Jedes hat seinen eigenen Rotationsplan, seine Ablaufrichtlinie und seinen Revokationspfad. Der Credential-Lifecycle ist der Bereich, in dem sich ILM und PAM (Privileged Access Management) überschneiden.

---

Der Lifecycle nicht-menschlicher Identitäten: Der blinde Fleck, den ILM-Programme übersehen

Service-Accounts, API-Keys, OAuth-Berechtigungen, CI/CD-Pipeline-Zugangsdaten und KI-Agenten sind allesamt Identitäten. Sie authentifizieren sich gegenüber Systemen, halten Berechtigungen und erzeugen Risiken, wenn sie nicht verwaltet werden. Und keine von ihnen erscheint im HRIS.

Nicht-menschliche Identitäten (NHIs) übersteigen in den meisten Unternehmen die Anzahl menschlicher Identitäten, wobei Verhältnisse von 40:1 bis 80:1 häufig genannt werden. Traditionelle IGA-Programme wurden nie für diesen Maßstab konzipiert.

97 % der NHIs verfügen über übermäßige Berechtigungen, was unbefugten Zugriff begünstigt und die Angriffsfläche vergrößert. Nur 20 % der Unternehmen haben formale Prozesse für das Offboarding und den Entzug von API-Keys - und noch weniger haben Verfahren für deren Rotation.

KI-Agenten fügen eine neue Komplexitätsebene hinzu. Der Unterschied zwischen einem Service-Account und einem KI-Agenten ist Autonomie: Ein Service-Account führt vordefinierte Anweisungen aus, während ein Agent Ziele interpretiert und Aktionen wählt. Deshalb benötigen Agenten die umfassendere Governance-Behandlung - Eigentümerschaft, begrenzte Berechtigungen und Lifecycle-Management - und nicht nur Credential-Hygiene.

Die grundlegendste Governance-Lücke bei nicht-menschlichen Identitäten ist das Fehlen klarer Eigentümerschaft. Eine menschliche Identität ist an eine Person gebunden, deren Beschäftigungsstatus, Rollenänderungen und Zugriffsbedarfe über HR-Systeme nachverfolgt werden können. Wenn ein menschlicher Mitarbeitender das Unternehmen verlässt, kann seine Identität über einen definierten Offboarding-Workflow deprovisioniert werden. Nicht-menschliche Identitäten haben diesen Anker nicht. Sie werden von Entwicklern, Automatisierungssystemen oder KI-Agenten selbst erstellt und überleben häufig das spezifische Projekt, die Pipeline oder den Agenten-Deployment, der ihre Existenz ursprünglich rechtfertigte.

Der NHI-Lifecycle erfordert ein paralleles Framework zum JML-Modell:

NHI-Lifecycle-Phase	Menschliches Äquivalent	Wichtige Kontrollen
Erstellung	Joiner	Benannter Eigentümer, definierter Zweck, begrenzte Berechtigungen
Änderung	Mover	Neuzuschnitt bei Projekt-/Teamwechsel, Eigentümerübertragung
Außerbetriebnahme	Leaver	Entzug bei Projektende, Rotation vor Löschung
Rotation	(kein Äquivalent)	Geplante Credential-Rotation, Ablauferzwingung

---

Manuelles vs. automatisiertes ILM

Die meisten Unternehmen befinden sich irgendwo auf einem Spektrum zwischen vollständig manuell und vollständig automatisiert. So sieht das in der Praxis aus:

Das Argument für Automatisierung ist nicht nur sicherheitsbezogen - es ist operativ. Eine Identity-Governance-Studie aus dem Jahr 2025 ergab, dass die manuelle Bereinigung verwaister Identitäten im Durchschnitt mehr als 2 Stunden pro Woche und Umgebung kostet. Diese Last skaliert schlecht, sobald Dutzende von SaaS-Apps verwaltet werden müssen. Und manuelle Provisionierung führt häufig zu einem "Produktivitätsverlust", bei dem New Hires tagelang oder wochenlang auf notwendige Zugriffe warten.

---

Wichtige ILM-Kennzahlen

Zu den wichtigsten Kennzahlen gehören die Bereitstellungszeit für die Deprovisionierung (primäre Kennzahl zur Risikoreduktion) und die Bereitstellungszeit für die Provisionierung (die den Einfluss auf die Produktivität neuer Mitarbeitender und die Time-to-Value misst).

Verfolgen Sie diese vier Zahlen, um zu wissen, ob Ihr ILM-Programm tatsächlich funktioniert:

• Bereitstellungszeit (Provisionierung) - Von der HRIS-Einstellungsbestätigung bis zum vollständigen Zugriff. Ziel: noch am selben Tag oder vor dem ersten Arbeitstag. Same-Day- oder Pre-Day-One-Provisionierung ist der anzustrebende Benchmark.
• Bereitstellungszeit (Deprovisionierung) - Vom Kündigungsereignis bis zum vollständigen Entzug aller Zugriffe. Alles über wenige Stunden hinaus ist ein erhebliches Risikoexposure. Best-in-Class-Programme erreichen durch Automatisierung eine vollständige Revokation in unter 30 Minuten.
• Rate verwaister Konten - Prozentualer Anteil aktiver Konten, die zu Personen gehören, die nicht mehr im Unternehmen sind. Ziel: so nah wie möglich an null, kontinuierlich gemessen.
• % der abgedeckten Apps - Welcher Anteil des App-Stacks wird durch das ILM-Programm abgedeckt (nicht nur SCIM-verbundene Apps). Ein Programm, das 20 von 50 Apps abdeckt, hat einen 60-prozentigen blinden Fleck.

Zwei weitere Kennzahlen, die es wert sind, verfolgt zu werden: Volumen manueller zugangsbezogener Help-Desk-Tickets (ein direktes Maß für den ROI / Return on Investment der Automatisierung) und die Abschlussrate von Access-Reviews (der Prozentsatz geplanter Zertifizierungen, die fristgerecht abgeschlossen werden).

---

ILM innerhalb von IGA: Wie beides zusammenpasst

ILM ist der operative Kern von IGA, aber IGA ist umfassender. So lässt es sich einordnen:

• ILM beantwortet: Hat die richtige Person gerade die richtigen Zugriffe?
• IGA beantwortet: Wird der Zugriff durch Richtlinien / Policies gesteuert, ist er auditierbar und compliant?

IGA fügt die Richtlinienebene hinzu (Rollendefinitionen, SoD-Regeln, Risikobewertung), die Zertifizierungsebene (regelmäßige Reviews) und die Reporting-Ebene (Audit-Belege, Compliance-Dashboards). ILM liefert die Ausführung - die Provisionierungs-, Deprovisionierungs- und Änderungs-Workflows, die Richtlinien Wirklichkeit werden lassen.

Ein ausgereiftes IGA-Programm ohne starkes ILM darunter produziert schöne Dashboards, die die Realität nicht widerspiegeln. Starkes ILM ohne IGA-Governance produziert Automatisierung ohne Verantwortlichkeit. Beides wird benötigt.

---

Wo die meisten ILM-Programme scheitern

Die Abdeckungslücke ist das häufigste Versagen. Ein ILM-Programm, das SCIM-verbundene Apps automatisiert und den Rest manuell belässt, ist kein vollständiges Programm - es ist partielle Automatisierung mit einem manuellen Schwanz, der wächst, je größer der SaaS-Stack wird.

Bei einem typischen Stack von 50-100 Apps in einem 200-Personen-Unternehmen werden weniger als die Hälfte dieser Apps SCIM unterstützen. Der Rest - die Projektmanagement-Tools, die Design-Plattformen, die Kommunikationskanäle, die internen Wikis - erfordert entweder direkte API-Integration oder einen Konnektor, der in die App schreiben kann, ohne SCIM. Wenn die IGA-Plattform diese nicht erreichen kann, hat der Leaver-Workflow Lücken, der Mover-Workflow hat Lücken, und die Rate verwaister Konten ist höher als gedacht.

Das zweite Versagen ist das oben beschriebene Mover-Problem: neue Zugriffe provisionieren, ohne alte zu entziehen. Berechtigungen, die als sicher und compliant eingestuft wurden, sanken von 70 % im Jahr 2024 auf 55 % im Jahr 2025, während nicht verwaltete Berechtigungen von 5 % auf 28 % des Gesamtvolumens anstiegen. Das ist kein Joiner- oder Leaver-Problem - es ist ein Mover-Problem, das sich über die Zeit aufbaut.

Iden wurde entwickelt, um beide Lücken zu schließen. Die universelle Konnektor-Technologie erreicht jede App im Stack - SCIM, API oder keines von beidem -, sodass Joiner-, Mover- und Leaver-Workflows vollständig und nicht nur teilweise ausgeführt werden. Feingranulare Zugriffskontrolle geht tiefer als Gruppenmitgliedschaft: Berechtigungen auf Channel-, Repo- und Projektebene werden mit derselben Automatisierung provisioniert und entzogen. Und dasselbe Lifecycle-Framework erstreckt sich auf nicht-menschliche Identitäten (NHIs) - Service-Accounts, Tokens und KI-Agenten, die nie im HRIS erscheinen.

Erfahren Sie, wie Iden den vollständigen Lifecycle über den gesamten App-Stack automatisiert - einschließlich des Non-SCIM-Long-Tails:

---

ILM-Reifegradcheckliste

Nutzen Sie diese Checkliste, um den aktuellen Stand Ihres Programms zu bewerten. Ein ausgereiftes ILM-Programm erfüllt jeden Punkt.

Joiner

• Das HRIS ist die einzige autoritative Quelle für alle Identitätsereignisse
• Die Provisionierung wird automatisch beim HRIS-Einstellungsereignis ausgelöst (keine manuelle Benachrichtigung)
• Birthright-Zugriff ist nach Rolle definiert, nicht nach individueller Anfrage
• Alle Apps im Stack - einschließlich Nicht-SCIM-Apps - sind durch den Joiner-Workflow abgedeckt
• Pre-Day-One-Provisionierung ist für Standardrollen erreichbar

Mover

• HRIS-Rollenwechselereignisse (Fachbereich, Titel, Vorgesetzte) lösen Mover-Workflows automatisch aus
• Zugriffe der neuen Rolle werden provisioniert UND Zugriffe der alten Rolle werden im selben Workflow explizit entzogen
• Zugriffe, die weder zur alten noch zur neuen Rollen-Baseline passen, werden zur Zertifizierung markiert
• Mover-Workflows decken alle Apps ab, nicht nur SCIM-verbundene
• Regelmäßige Access-Reviews erkennen Drift zwischen Mover-Ereignissen

Leaver

• Das Kündigungsereignis löst die Deprovisionierung sofort aus (kein nächtlicher Batch-Lauf)
• Das SSO/IdP-Konto wird innerhalb von Minuten nach der Kündigung deaktiviert
• Nicht-SCIM-Apps werden direkt deprovisioniert, nicht davon ausgegangen, dass SSO sie abdeckt
• API-Keys, Tokens und geteilte Zugangsdaten werden entzogen
• Die vollständige Deprovisionierungskette wird mit Zeitstempeln protokolliert
• Ziel-Bereitstellungszeit für die Deprovisionierung: unter 1 Stunde

Nicht-menschliche Identitäten

• Alle Service-Accounts haben einen benannten menschlichen Eigentümer
• API-Keys und Tokens haben definierte Ablauf- und Rotationspläne
• KI-Agenten-Identitäten sind inventarisiert und getrennt von Service-Accounts verwaltet
• NHI-Lifecycle-Ereignisse (Erstellung, Änderung, Außerbetriebnahme) werden in der IGA-Plattform nachverfolgt
• Verwaiste NHIs werden kontinuierlich erkannt und behoben

Kennzahlen und Governance

• Bereitstellungszeit (Provisionierung) wird gemessen und verfolgt
• Bereitstellungszeit (Deprovisionierung) wird gemessen und verfolgt
• Rate verwaister Konten wird kontinuierlich gemessen (nicht nur zum Audit-Zeitpunkt)
• % der durch automatisiertes ILM abgedeckten Apps ist bekannt und wird verbessert
• Abschlussrate von Access-Reviews wird verfolgt und liegt über 90 %
• Manuelle Zugriffstickets nehmen Quartal für Quartal ab

---

Einen tieferen Einblick in das Joiner-Mover-Leaver-Framework bietet unser Vollständiger Leitfaden zu Joiner-Mover-Leaver. Wenn Sie sich speziell auf die Leaver-Phase konzentrieren, bietet die IT-Offboarding-Checkliste für Mitarbeitende eine Schritt-für-Schritt-Vorlage für die Same-Day-Deprovisionierung über alle Apps im Stack.