Warum "Mover" der schwierigste Teil von JML sind (und wie man das Problem löst)

Zusammenfassung: Die meisten JML-Projekte konzentrieren sich auf Onboarding und Offboarding. Das eigentliche Risiko und die operative Last liegen jedoch in der Mitte - wenn Menschen Rollen, Teams und Projekte wechseln. Hier ist der Grund, warum Mover in SaaS-lastigen Umgebungen so schwer zu steuern sind, warum reine SCIM-Tools immer wieder scheitern und wie wirksame Automatisierung für schlanke IT-Teams aussieht.

JML 101: Warum Mover wichtiger sind, als Sie denken

Joiner-Mover-Leaver (JML) ist der Branchenstandard für das Identitäts-Lebenszyklusmanagement: Zugriffe bereitstellen, anpassen und entziehen - über die gesamte Beschäftigungsdauer eines Nutzers hinweg.

In der Theorie ist das simpel:

• Joiner (Eintritt): Vom ersten Tag an die richtigen Zugriffe gewähren.
• Mover (Wechsel): Zugriffe anpassen, wenn sich Rollen oder der Kontext ändern.
• Leaver (Austritt): Zugriffe sauber und vollständig entziehen, wenn jemand das Unternehmen verlässt.

In der Praxis bricht die Phase "Mover" häufig auseinander:

• Menschen wechseln deutlich häufiger Rolle, Team, Standort und Projekte, als dass sie das Unternehmen verlassen.
• Jeder Wechsel berührt Dutzende Systeme, Rollen und feingranulare Berechtigungen.
• Klassische IGA-Lösungen und "moderne" SCIM-only-Tools sind für dieses Veränderungstempo schlicht nicht ausgelegt.

Ein Trainingsmaterial zum Identitäts-Lebenszyklusmanagement weist explizit darauf hin, dass Mitarbeitende in realen Organisationen häufiger die Rolle wechseln als das Unternehmen zu verlassen; Beförderungen, horizontale Wechsel, temporäre Projekte und Abteilungswechsel sind der Ort, an dem der Großteil der Pflege von Zugriffsrechten stattfindet

Joiner: Laut, aber vorhersehbar

Joiner fallen auf. HR eröffnet ein Ticket. Ein Startdatum steht fest. Fehlende Zugriffe sind sofort sichtbar.

Die meisten Teams landen bei einem "gut genug"-Prozess:

• Grundlegende Startberechtigungen über HRIS-IdP-Synchronisation
• SCIM-basierte Benutzerbereitstellung für Kernanwendungen
• Standardisierte Onboarding-Checkliste

Lücken bleiben oft bestehen, aber der Prozess ist wiederholbar.

Leaver: Kritisch, aber gut checklistenfähig

Leaver sind risikoreich, aber stark prozessorientiert:

• HR markiert eine Beendigung im HRIS
• Der IdP deaktiviert das Konto
• Jemand (hoffentlich) arbeitet eine Offboarding-Checkliste ab

Auch wenn unvollständiges Offboarding und verwaiste Konten weiter vorkommen: Der Auslöser ist klar und tritt nur einmal pro Person auf.

Mover: Wo sich Risiko leise aufaddiert

Bei Movern ist es anders:

• Rollenwechsel verlaufen oft schleichend (Einarbeitung im Schatten, Doppelrollen, temporäre Projekte).
• Alte Zugriffe werden selten konsequent entfernt.
• Viele Veränderungen laufen an HR vorbei (Projektbeteiligung, temporäre Verantwortlichkeiten, Nebentätigkeiten).

Eine Umfrage von Ivanti ergab, dass 45 % der Befragten angeben, dass unnötige Zugriffsrechte nicht entfernt werden, wenn Mitarbeitende die Rolle wechseln Das ist nicht nur ein Compliance-Thema; so wird Berechtigungsaufblähung zum Alltag.

Das Ergebnis: Die Phase "Mover" treibt leise die breiteste Angriffsfläche und sorgt für die chaotischsten Auditergebnisse.

Die eigentlichen Ursachen des Mover-Problems

1. Rollen-Kriechen und Berechtigungs-Wildwuchs

Beim Onboarding lässt sich noch halbwegs gut abschätzen, was jemand benötigt. Nach mehreren Rollenwechseln weiß kaum jemand, welche Zugriffe sich bereits angesammelt haben.

Typische Muster:

• Nur hinzufügen: Für neue Rollen werden Berechtigungen ergänzt, aber nichts entfernt.
• Geschichtete Gruppen: Nutzende sammeln Gruppenmitgliedschaften aus früheren Rollen.
• Projektüberbleibsel: Temporäre Zugriffe auf Repositories oder Dashboards laufen nie aus.

Branchenanalysen zeigen, dass Berechtigungswildwuchs und Rollen-Kriechen entstehen, wenn Nutzende im Zeitverlauf Zugriffe anhäufen - vor allem durch schwaches Deprovisioning und schlechte Rollenhygiene, insbesondere bei Rollenwechseln

Genau das verursachen Mover: häufige, unübersichtliche Änderungen, die sich nur schwer aufräumen lassen.

2. Abdeckungslücken - die SCIM-Mauer und der SaaS-Long Tail

Typische "moderne" Identity-Lifecycle-Diagramme zeigen:

• Okta oder Entra als IdP
• SCIM-basierte Bereitstellung für einige wenige zentrale SaaS-Anwendungen
• Gruppen-/Rollenabbildung aus HR-Daten

Was sie nicht zeigen:

• Die 40-80 Long-Tail-SaaS-Apps und internen Tools, die per Tickets und Tabellen verwaltet werden
• Anwendungen, bei denen SCIM nur in 5- bis 10-mal teureren Enterprise-Plänen enthalten ist (die SCIM-Steuer)
• OT/ICS, On-Prem- und Eigenentwicklungen - ohne moderne API

Interne und externe Analysen sind sich einig: Nur etwa 20-40 % der Anwendungen in den meisten Organisationen sind automatisiert. Der Rest - Legacy, On-Prem, spezialisierte SaaS, OT/ICS - bleibt vollständig manuell und bündelt sowohl die operative Arbeit als auch das Risiko

Aus den eigenen Daten von Iden:

Rund 60 % der SaaS-Anwendungen unterstützen SCIM nicht nativ. Bei bekannten Tools (Notion, Slack, Figma) liegt SCIM oft hinter teuren Enterprise-Tarifen, sodass die meisten Unternehmen entweder die SCIM-Steuer zahlen oder auf manuelle Prozesse setzen

Mover verstärken diese Lücken: Per Definition berühren sie mehr Systeme als Joiner oder Leaver - häufig genau die am wenigsten automatisierten Teile des Stacks.

3. Neue Identitätstypen und projektbasierte Arbeit

Mover umfassen weit mehr als Festangestellte, die ihren Titel wechseln:

• Externe Dienstleistende, die Teams oder Kund:innen wechseln
• Partnerunternehmen mit gezielt begrenztem, zeitlich befristetem Zugriff
• Bots, CI-Jobs und KI-Agenten, die für neue Zwecke eingesetzt werden

Moderne Governance-Empfehlungen betonen, dass nicht-menschliche Identitäten - Dienstkonten, Bots, Pipelines, virtuelle Agenten - heute einen wesentlichen Teil des Zugriffsrisikos ausmachen und ebenso streng gesteuert werden müssen wie menschliche Identitäten.

Dennoch gehen die meisten JML-Flows implizit von "Mensch + HR-Datensatz" aus - und lassen diese Identitäten außerhalb der Mover-Prozesse.

4. Statische Kontrollen in einer Welt kontinuierlicher Veränderung

Traditionelle Governance stützt sich auf:

• Jährliche oder vierteljährliche Zugriffsüberprüfungen
• Statische RBAC-Modelle, die per Ticket gepflegt werden
• HR-getriebene Ereignisse als Trigger

Rollenänderungen und schleichende Abweichungen passieren jedoch kontinuierlich.

Aktuelle Kommentare von Anbietern im Bereich Identity Security sind eindeutig: JML steuert nur Anfang und Ende des Lebenszyklus, aber "alles, was in der Cloud-Sicherheit wirklich zählt, passiert in der Mitte" - dort, wo Echtzeit-Identitätsintelligenz und sofortige Zugriffsänderungen wichtiger sind als geplante Lifecycle-Events

Für Mover ist diese "Mitte" der eigentliche Lebenszyklus.

Warum reine SCIM- und SSO-Ansätze bei Movern scheitern

Klassisches SSO und SCIM lösen das Zugriffsproblem von gestern - sicheres Onboarding zu einigen wenigen Anwendungen. Mover im SaaS-Dschungel sind eine neue Risikoklasse.

Joiner vs. Mover vs. Leaver im typischen Stack

Die am schlechtesten automatisierte Phase ist zugleich die häufigste und komplexeste.

Die Designgrenzen von SCIM bei Movern

SCIM funktioniert gut für:

• Anlegen und Löschen von Konten
• Anpassen grundlegender Attribute und Gruppenmitgliedschaften

SCIM stößt an Grenzen bei:

• Feingranularen Berechtigungen (bestimmte Slack-Kanäle, Zugriffe auf einzelne Repositories/Projekte)
• Komplexen, kontextabhängigen Zugriffsmodellen (temporäre Zugriffe, SoD-bewusste Berechtigungen)

Fachleute weisen darauf hin: SCIM stellt Identitätsdaten bereit, war aber nie dafür gedacht, sämtliche Anwendungs-Berechtigungen modellieren zu können.

Genau in diesen feingranularen Berechtigungen versteckt sich das Mover-Risiko.

Die harte Realität für reine SSO-/SCIM-Stacks

Rückmeldungen aus der Praxis:

• Okta und Entra funktionieren gut, wenn Sie 100 % SAML-/SCIM-Abdeckung haben - was selten der Fall ist.
• Teams stellen fest, dass SCIM "bei der Hälfte der SaaS-Apps scheitert" oder nur mit Enterprise-Tarifen nutzbar ist, die sich nicht begründen lassen.
• Eigenentwickelte Skripte und Orchestrierung schließen Lücken nur für eine Handvoll besonders kritischer Anwendungen.

Eine Studie stellte fest, dass 71 % der Organisationen die mangelnde Kompatibilität mit nicht standardisierten Legacy-Anwendungen als zentrales Hindernis für die Modernisierung ihrer Identity-Systeme nennen

Wenn Mover auf diese Legacy- oder Nicht-SCIM-Anwendungen treffen, bricht der Prozess zusammen in:

• Jira-Tickets
• Slack-Anfragen
• Manuelle Admin-Anpassungen von Zugriffsrechten

Das ist keine Governance - das ist Hoffen und Bangen.

Gleichzeitig setzen Angreifer zuerst bei Identitäten an

Branchenzahlen schätzen, dass rund 80 % aller Cyberangriffe identitätsbasierte Techniken nutzen. Die Zahl menschlicher und maschineller Identitäten soll sich innerhalb eines Jahres um mehr als 200 % erhöhen

Wenn Identitäten die wichtigsten Angriffsvektoren sind:

• Sind Mover mit Berechtigungswildwuchs ideale Ziele.
• Reine SCIM-Synchronisation und jährliche Reviews sind unzureichend.
• Kontinuierliche, feingranulare Steuerung ist unverzichtbar - gerade dort, wo SCIM/SSO nicht greifen.

Wie Mover-Automatisierung aussehen muss, damit sie wirklich funktioniert

Wie sieht funktionierende Mover-Automatisierung für ein SaaS-lastiges Unternehmen mit schlankem IT-Team aus?

1. Mover an Ereignisse aus führenden Systemen ankern

Beginnen Sie mit den Systemen, die Sie kontrollieren:

• HRIS: Rolle, Abteilung, Standort, Vorgesetzte:r
• Verzeichnis/IdP: Gruppen, Organisationseinheiten, dynamische Regeln
• ITSM: Formale Change-Requests

Jede wesentliche HR-Attributänderung (Rolle, Abteilung, Kostenstelle, Beschäftigungsart) sollte ein Access-Delta-Ereignis erzeugen. Dieses eine Ereignis wird zur zentralen Steuergröße für Mover-Workflows über alle Anwendungen hinweg - nicht nur über diejenigen mit SCIM.

2. Zugriffe als Rollen + feingranulare Berechtigungen modellieren

Klassisches RBAC: "Sales-Rep" erhält Rechtspaket A, "Support Engineer" erhält Paket B.

Für Mover kommt hinzu:

• Rollen-Bundles: Klar definierte Berechtigungspakete je Funktion (z. B. Sales bekommt CRM + bestimmte Finanz-Dashboards)
• Feingranulare Overlays: Temporäre, projektbezogene oder ressourcenspezifische Zugriffe

Die Logik für Mover sollte:

• Zugriffe bei Rollenwechsel komplett neu berechnen - alle Berechtigungen entfernen, die im neuen Rollen-Bundle nicht enthalten sind, sofern sie nicht explizit als Ausnahme markiert wurden.
• Zeitlich befristete Overlays für Übergangsphasen und Doppelrollen nutzen.

So wird Rollen-Kriechen aktiv verhindert.

3. Agentische Workflows statt Menschen für Provisionierung einsetzen

Agentische Workflows = KI-gestützte, weitgehend autonome Abläufe, die:

• Autoritative Systeme auf Mover-Trigger überwachen
• Erforderliche Hinzufügungen/Entfernungen berechnen
• Änderungen - in allen Systemen - über standardisierte Konnektoren oder Bots ausführen

Sie wollen folgendes Muster:

1. HR ändert "Support Engineer -> Customer Success Manager".
2. Eine Richtlinie berechnet hinzuzufügende und zu entfernende Berechtigungen und prüft Ausnahmen.
3. Der agentische Workflow aktualisiert Salesforce, Slack, Support-Tools und Wissensdatenbanken - in SCIM- und Nicht-SCIM-Anwendungen.
4. Alle Änderungen werden in unveränderbaren Audit-Logs protokolliert.

Daten von Iden zeigen: Kund:innen reduzieren manuelle Zugriffstickets um etwa 80 % innerhalb von 60 Tagen, nachdem sie Lifecycle- und Access-Workflows automatisiert haben. Für Mover bedeutet das: weniger Tickets, weniger Sonderfälle.

4. Mover fest in kontinuierliche Governance einbetten

Verlassen Sie sich nicht ausschließlich auf HR-Daten.

Wirksame Mover-Automatisierung nutzt zusätzlich:

• Nutzungs-Signale: Unbenutzte Berechtigungen entfernen
• Risikohinweise: Plötzliche Nutzungsspitzen oder SoD-Konflikte markieren
• Kontext: Änderungen bei Vorgesetzten, Kostenstellen oder Projekten berücksichtigen

Der aktuelle Best-Practice-Ansatz: ereignisgesteuerte Reviews bei Einstellungen, Versetzungen, Beförderungen, Kündigungen - nicht nur jährliche Rezertifizierungen. Mover brauchen genau diese eventgetriebene, kontextreiche Bereinigung.

Wie universelle Abdeckung + feingranulare Steuerung das Mover-Problem lösen

Fähigkeits-Checkliste für Mover-Automatisierung

Eine moderne Governance-Schicht muss in der Lage sein:

• Sich mit jeder relevanten Anwendung zu verbinden - ob SCIM, API oder gar nichts davon
• Berechtigungen auf der Ebene zu steuern, auf der sie tatsächlich vergeben werden (Projekt, Kanal, Repository)
• Echtzeit-, richtlinienbasierte Entscheidungen bei Zugriffsänderungen zu treffen
• Unveränderbare Audit-Protokolle sämtlicher Zustandsänderungen von Berechtigungen zu führen

Iden erfüllt diese Anforderungen:

• Universelle Konnektor-Technologie für jede Anwendung - SCIM, API oder keine - und deckt damit die 80 % der Anwendungen ab, die andere Tools manuell lassen
• Unterstützung für über 175 Anwendungen out of the box; neue Konnektoren werden bei Bedarf innerhalb von 48 Stunden geliefert
• Granulares Berechtigungsmanagement bis auf Kanal-/Repository-/Projektebene (weit über die Möglichkeiten von Basis-SCIM hinaus)
• Vollständige Lifecycle-Automatisierung für menschliche und nicht-menschliche Identitäten, unveränderbare Audit-Logs, richtliniengesteuerte Workflows

Mover in einer Welt mit universeller Abdeckung: Reale Szenarien

Szenario 1: Engineer -> Security Engineer

Heute:

• Eine Engineer-Person sammelt GitHub-Repositories, Staging-/Produktivzugriffe, Slack-Kanäle.
• Wechselt ins Security-Engineering.
• Neue Zugriffe kommen hinzu; alte Zugriffe bleiben weitgehend bestehen.

Mit richtliniengesteuerter, universeller Automatisierung:

1. HR ändert die Rolle auf "Security Engineer".
2. Die Policy-Engine entfernt unnötige Repositories, schränkt Produktivzugriffe ein, lässt aber temporäre Overlays für Wissensübergabe bestehen.
3. Universelle Konnektoren setzen Änderungen in allen Tools um - auch in Nicht-SCIM-Anwendungen - über agentische Workflows.
4. Das Audit-Log hält fest, was geändert wurde und warum.

Szenario 2: Support Rep -> Customer Success Manager

Heute:

• Eine Support-Person baut Zugriffe auf Support- und Debug-Tools sowie weitreichende Kanalrechte auf.
• Nach und nach kommen kundenseitige Tools dazu; alte Zugriffe bleiben jedoch bestehen.

Mit universeller Mover-Automatisierung:

• HR löst den Mover-Workflow aus.
• Support-Berechtigungen werden entzogen, Customer-Success-Rechte gewährt.
• Überlappende Zugriffe werden passend neu zugeschnitten; zeitlich befristete Überschneidungen laufen automatisch aus.

Die Kernaussage: Mover werden langweilig. Es ist nur noch ein weiterer Policy-Event - kein wochenlanger Ticket-Marathon.

Vergleich: SCIM-only vs. universell + feingranular

Fazit: Machen Sie Mover wieder langweilig

Wer Mover ignoriert, kämpft dauerhaft mit:

• Berechtigungsaufblähung und überprivilegierten Konten
• anstrengenden Audits
• Ticket-Chaos bei jeder Reorganisation, Beförderung oder jedem neuen Projekt

So kommen Sie da raus:

1. Erkennen Sie Mover als Kernproblem an. Sie treten häufiger und komplexer auf als Joiner oder Leaver.
2. Hören Sie auf, sich nur auf SCIM zu verlassen. SCIM ist reine Leitungsinfrastruktur, keine Governance-Intelligenz.
3. Streben Sie universelle Abdeckung an. Bringen Sie jede Anwendung unter Lifecycle-Automatisierung.
4. Modellieren Sie Rollen + feingranulare Berechtigungen. Arbeiten Sie mit Bundles und Overlays, nicht nur mit Gruppen.
5. Lassen Sie agentische Workflows die Fleißarbeit erledigen. Menschen definieren Policies, die Plattform kümmert sich um das Volumen.
6. Machen Sie Mover zum Auslöser kontinuierlicher Governance. Jede Mover-Änderung ist eine Chance, alte Berechtigungen zu entfernen und Least-Privilege zu stärken.

Wenn Sie bereits SSO und etwas Automatisierung haben, brauchen Sie kein neues Architekturdecks - Sie brauchen Abdeckung und Tiefe. Ob mit Iden oder einer anderen Plattform: Setzen Sie Ihren Standard so, dass Mover-Ereignisse als Normalfall, nicht als Ausnahme behandelt werden - mit vollständiger Abdeckung.

Häufig gestellte Fragen

Worin unterscheidet sich die Phase "Mover" aus Risikosicht von Joinern und Leavern?

Joiner/Leaver sind klar abgegrenzte Ereignisse, die sich über Checklisten steuern lassen. Mover passieren dagegen häufig und oft informell - Projektwechsel, neue Vorgesetzte, Teamwechsel. Bei jedem Wechsel kommen neue Zugriffe hinzu, alte werden selten entfernt. So entstehen Rollen-Kriechen und Berechtigungswildwuchs. Wird ein Mover kompromittiert, verfügt diese Person oft über deutlich mehr Zugriffe als ein typischer Joiner oder Leaver.

Kann ich das Mover-Problem nicht einfach mit einem strengeren RBAC-Modell lösen?

Ein besseres RBAC hilft, reicht aber alleine nicht aus. Zusätzlich brauchen Sie:

• Ereignisgesteuerte Automatisierung, ausgelöst durch HRIS-/IdP-Änderungen
• Konnektoren für alle Anwendungen - nicht nur für solche mit SCIM
• Feingranulares Berechtigungsmanagement (Kanäle, Repositories, Projekte)

Ohne universelle Abdeckung und Automatisierung bleiben Mover ein riesiger Berg manueller Arbeit.

Wie verändert universelle Anwendungsabdeckung die Mover-Workflows?

Mit universeller Abdeckung werden Mover von spontanen Feuerwehreinsätzen zu standardisierten, automatisierten Abläufen:

• HR oder Vorgesetzte lösen eine Rollenänderung aus.
• Richtlinien berechnen die passenden Zugriffe neu.
• Konnektoren setzen Änderungen in allen Anwendungen um.
• Audit-Logs dokumentieren jede Änderung.

Die IT wandelt sich von einer "manuellen Provisionierungsschicht" hin zu einem Policy-Design-Team - und ermöglicht echte kontinuierliche Governance.

Brauche ich einen kompletten Neuaufbau, um Mover zu automatisieren?

Nein. Der schlanke Ansatz:

1. Identifizieren Sie 5-10 Anwendungen mit besonders großem Mover-Schmerz.
2. Definieren Sie Rollen-Bundles und zentrale Richtlinien.
3. Binden Sie diese Anwendungen über eine Governance-Plattform mit universellen Konnektoren an.
4. Schalten Sie ereignisgesteuerte Mover-Workflows scharf.
5. Verfeinern Sie Sonderfälle und weiten Sie die Abdeckung aus.

So erzielen Sie schnell greifbare Ergebnisse - ohne Großprojekt und Komplettneuentwurf.

Wie wirken sich Mover auf Audits und Compliance (SOC 2, ISO 27001, HIPAA usw.) aus?

Auditor:innen wollen belastbare Nachweise sehen:

• Wer wann worauf Zugriff hatte
• Wie sich Zugriffe bei Rollenwechseln verändern
• Wie SoD-Verstöße verhindert und erkannt werden

Wenn Mover-Änderungen über Tickets oder Admin-Einzelaktionen laufen, ziehen sich Audit-Zyklen über Wochen. Mit automatisierten Workflows und unveränderbaren Logs gilt dagegen:

• Jede Hinzufügung/Entfernung ist mit Zeitstempel und Kontext nachvollziehbar.
• Rollenänderungen lösen automatisch passende Zugriffsanpassungen aus.
• SoD-Prüfungen und Ausnahmebehandlungen sind in einem einzigen Dashboard sichtbar.

Statt Unsicherheit gibt es klare, sofort verfügbare Antworten für Audit- und Compliance-Teams.