Die meisten "modernen" Identity-Tools gehen stillschweigend davon aus, dass all Ihre geschäftskritischen Anwendungen SCIM unterstützen.

Schauen Sie auf Ihren echten Stack: Notion, Figma, Linear, Miro, spezialisierte SaaS-Lösungen, etwas On-Premises, einige OT-Systeme. Nur ein Bruchteil ist wirklich automatisierbar.

Diese Anleitung zeigt Schritt für Schritt, wie Sie den kompletten Joiner-Mover-Leaver-Lebenszyklus (JML) automatisieren - inklusive Apps ohne SCIM oder APIs. Echte Lösungen, echte Lücken, die geschlossen werden. Fokus:

  • Identity-Automatisierung, die Ihren gesamten Stack abdeckt
  • Bereitstellung und Entzug von Zugängen ohne Dauer-Feuerwehrmodus
  • Identity-Lifecycle-Management, das das "Mover"-Problem wirklich löst
  • Anwendungsbereitstellung ohne SCIM-Aufschlag
  • SaaS-Sicherheit, die mehr ist als bloßes Governance-Theater

Am Ende haben Sie einen klaren JML-Projektplan für ein schlankes IT-Team - und ein gutes Gefühl dafür, wo Technologien wie Iden ins Bild passen.

Was Sie vor dem Start brauchen

Kein IAM-Imperium nötig. Nur das Wesentliche:

  • SSO im Einsatz (z. B. Okta, Entra) als Authentifizierungs-Rückgrat
  • HRIS oder Personen-Datenquelle (Workday, BambooHR, Personio, Lohnabrechnungssystem)
  • Grob-Liste Ihrer Anwendungen (SaaS, On-Premises, interne Systeme, OT/ICS)
  • Mindestens einen ITSM-/Ticket-Kanal (Jira, ServiceNow, Slack)
  • Management-Sponsoring: JML-Automatisierung ist Priorität, kein Wunschzettel-Punkt

Damit sind Sie gut gerüstet für den Start.

Schritt 1 - Ihren realen JML-Lebenszyklus abbilden

Sparen Sie sich idealisierte Diagramme. Kartieren Sie, was heute tatsächlich passiert.

  1. Identitätstypen auflisten:
    • Mitarbeitende
    • Auftragnehmende/Dienstleister
    • Externe Partner
    • Servicekonten, Bots, KI-Agenten ("neue Identitäts-Spezies")
  2. Reale J-, M-, L-Abläufe dokumentieren:
    • Joiner: Wie informiert HR die IT? Wo werden Zugriffsanfragen gestellt? Wann werden Konten angelegt - vor oder nach dem ersten Arbeitstag?
    • Mover: Wie erfahren Sie von Rollen- oder Vorgesetztenwechseln? Wer entzieht tatsächlich alte Zugriffe? Wie oft passiert das?
    • Leaver: Was löst das Offboarding aus? Wer prüft die Long-Tail-Apps?
  3. Verzögerungen und Fehlerquellen notieren:
    • Fehlende Anfragen/Tickets
    • "Temporäre Zugänge", die nie entfernt werden
    • Ehemalige Mitarbeitende, die Monate später noch in Slack oder GitHub hängen

Häufiger Fehler
Teams modellieren Rollen zu detailliert, bevor sie ihren realen Prozess verstanden haben. Erst die Realität sauber erfassen, dann modellieren.

Ergebnis: Ein prägnantes, einseitiges JML-Flussdiagramm mit Identitätstypen und eingesetzten Tools.

Schritt 2 - Apps inventarisieren und die SCIM-Lücke sichtbar machen

Betrachten Sie Ihren Stack durch eine Governance-Brille, nicht nur durch eine Lizenz-Brille.

  1. Eine einfache Inventur aufbauen (ja, eine Tabelle reicht):
    • Name der Anwendung
    • Fachlicher Owner
    • Benutzeranzahl
    • SSO? (J/N)
    • SCIM? (J/N)
    • Nutzbare API? (J/N)
    • Kritikalität
  2. Integrationsfähigkeit klassifizieren:
    • Stufe A - SCIM über SSO
    • Stufe B - API, aber kein SCIM
    • Stufe C - Kein SCIM, schwache/keine API

Die meisten Teams stellen fest, dass nur 20-40 % der Anwendungen SCIM-fähig sind; der Rest bleibt bei Tickets und Tabellen hängen

Rund 60 % der SaaS-Anwendungen haben keine native SCIM-Unterstützung - damit decken die meisten "modernen IGA"-Tools bestenfalls einen Teil ab.

  1. Long-Tail-Risiken identifizieren:
    • Anwendungen mit Zahlungs-, Code- oder Produktionsdaten - nicht über SCIM integriert
    • Anwendungen, die stark von Zeitarbeitskräften/Auftragnehmenden genutzt werden
    • Administratoren außerhalb der IT (Marketing, Revenue Operations, OT)

Tipp
Versuchen Sie nicht, am ersten Tag 100 % zu erreichen. Priorisieren Sie Non-SCIM-Apps mit sensiblen, produktiven oder umsatzrelevanten Daten - diese bergen das höchste Risiko.

Ergebnis: Eine gestufte Appliste, die Lücken unübersehbar macht.

Schritt 3 - Richtliniengesteuerten Zugriff entwerfen

Automatisieren Sie erst, nachdem klar ist, wer was, wann und warum erhält.

  1. Zugriffspakete nach Attributen definieren - nicht nach Jobtitel:

    • Abteilung/Kostenstelle
    • Standort/gesellschaftliche Einheit
    • Beschäftigungsart (Festangestellt, Auftragnehmend, Partner)
    • Seniorität/Kritikalität

  2. JML-Richtlinien in klarer Alltagssprache formulieren:

    • Joiner: "Alle neuen Engineers in EMEA erhalten am ersten Tag GitHub, Jira, Notion, Slack und bestimmte Kanäle."
    • Mover: "Wenn Vertrieb zu Customer Success wechselt, Salesforce entziehen, Slack behalten, Zendesk hinzufügen."
    • Leaver: "HR stößt das Offboarding an, alle Konten - inklusive Long-Tail - werden innerhalb von 60 Sekunden entzogen."

  3. Trennungsprinzipien (Segregation of Duties, SoD) einziehen:

    • "Niemand genehmigt seine eigenen Finanzanforderungen."
    • "Keine Ingenieurin, kein Ingenieur erhält dauerhaften Schreibzugriff auf Produktion; nur Just-in-Time."

  4. Genehmigungspunkte festlegen:

    • Geburtsrecht-Zugriff (automatisch)
    • Sensible Zugriffe (Vorgesetzte/Datenverantwortliche)
    • Notfall-/Break-Glass-Zugriffe (kurzfristig, immer nachträglich geprüft)

Halten Sie all das in einem Dokument fest, das Sicherheit, IT und HR gemeinsam tragen.

Schritt 4 - Basisautomatisierung für SCIM-fähige Apps

Unstrittig, aber selten vollständig.

  1. HRIS -> SSO -> SCIM-Apps verbinden:

    • HRIS-Ereignis erzeugt eine SSO-Identität
    • SSO weist Gruppen/Attribute zu
    • SCIM übernimmt Provisionierung/Deprovisionierung

  2. Richtlinienkonforme Gruppen verwenden:

    • z. B. dept=engineering, role=support, statt app-spezifischer Gruppen

  3. Leaver automatisieren über HR-Kündigung -> SSO-Deaktivierung -> SCIM-Offboarding

Gute Basis für 20-40 % Ihres Stacks. Jetzt lösen wir die eigentliche Herausforderung - die übrigen 60-80 %.

Häufiger Fehler
Nur die großen SCIM-Apps anbinden und das Projekt dann "fertig" nennen. SCIM ist Pflichtprogramm, aber noch keine vollständige Governance.

Schritt 5 - Non-SCIM-/No-API-Apps mit universellen Konnektoren anbinden

Die meisten SSO-gebundenen Tools hören hier auf. Universelle Konnektoren springen dort ein.

Warum Skripte/RPA nicht ausreichen

Eine einzelne Anwendung zu skripten, ist machbar; 40 Anwendungen zu skripten bedeutet:

  • Zerbrechlichkeit: Bricht bei jedem UI- oder API-Änderchen
  • Blockaden: MFA, CAPTCHA, ungewöhnliche Abläufe
  • Chaos: Unterschiedliche Logs, Fehlerbehandlung und Versionierung

Prüferinnen und Prüfer mögen das nicht. Teams werden es leid. Sicherheitslücken bleiben.

Was "universelle Konnektoren" bedeuten

Eine Plattform mit universellen Konnektoren abstrahiert die Eigenheiten einzelner Apps und bietet richtliniengesteuerte Provisionierung/Änderung/Deprovisionierung - selbst für Anwendungen ohne SCIM oder nutzbare API.

Mit Iden gilt:

  • Jede Anwendung: SCIM, REST oder ohne beides über proprietäre Konnektoren
  • Fein granularer Zugriff: Bis hin zu Slack-Kanälen, GitHub-Repositories, Notion-Seiten, Jira-Projekten
  • Kein Engineering- und Wartungsaufwand: IT schreibt Richtlinien, die Plattform übernimmt Pflege und Selbstheilung

Der Katalog von Iden umfasst über 175 Anwendungen (Notion, Slack, Figma, Linear usw.) sowie schnelle Lieferung neuer Konnektoren

More about Iden

Wie Sie eine Non-SCIM-App anbinden (Beispiel: Notion)

  1. Anwendung verbinden: Admin-Login, der Konnektor entdeckt Benutzer, Gruppen und Arbeitsbereiche
  2. Attribute/Berechtigungen abbilden: HRIS-/SSO-Attribute mit Notion-Arbeitsbereichen/Gruppen verknüpfen, Onboarding-Vorlagen definieren
  3. An JML-Ereignisse binden:
    • Joiner: HRIS -> Notion-Konto anlegen, Arbeitsbereich zuordnen, Wissensbasis teilen
    • Mover: Arbeitsbereich neu zuordnen, alte Team-Seiten entziehen
    • Leaver: Zugriff entfernen, Eigentümerschaft übertragen, Lizenz zurückholen
  4. Testen und live schalten: Zunächst im "Schattenmodus" fahren, Änderungen verifizieren, dann produktiv schalten

Wiederholen Sie das für andere Stufe-B/C-Apps. Beweisen Sie den Nutzen zuerst bei den 5-10 größten Schmerzpunkten.

Tipp
Starten Sie mit Non-SCIM-Apps, die viele Tickets verursachen, viele Auftragnehmende nutzen oder sensible Daten halten.

Schritt 6 - Das Mover-Problem mit ereignisgesteuerten, agentischen Workflows lösen

Joiner/Leaver sind vergleichsweise einfach; Mover sind unordentlich. Hier entscheidet sich, ob Governance wirklich funktioniert.

Typisches Risikomuster:

  • Zugriffe werden sofort hinzugefügt.
  • Alte Zugriffe werden nie entfernt.
  • Mitarbeitende, die "wandern", bauen im Laufe der Zeit immer mehr Rechte auf.

So gehen Sie damit um:

  1. Mehrere Ereignisquellen nutzen: HRIS, Organigramm, ITSM-Tickets
  2. Explizite Mover-Richtlinien definieren:
    • "Abteilung X -> Y: Paket X entfernen, Paket Y zuweisen"
    • "Neue Führungskraft: Genehmigungsrechte erweitern, keine neuen Datenzugriffe"
  3. Automatische Vorher-/Nachher-Vergleiche: Tatsächliche Berechtigungen protokollieren, Genehmigende korrigieren nur Ausnahmen
  4. Agentische (KI-gestützte) Workflows zur Bereinigung nutzen: Berechtigungen laufend gegen Richtlinien prüfen, Abweichungen markieren/entfernen, Menschen nur bei Sonderfällen einbeziehen

So werden Mover von einem blinden Fleck zu einem sauber gesteuerten Ereignis.

Schritt 7 - Die Leaver-Lücke schließen und SaaS-Lizenzen zurückholen

Bei Leavern bricht SaaS-Sicherheit oft ein.

Prüfberichte zeigen regelmäßig Dutzende unbekannte, verwaiste Konten beim ersten automatisierten Offboarding-Durchlauf

So schließen Sie die Lücke:

  1. Einen Offboarding-Trigger festlegen: HRIS-"Enddatum" oder dringender Sicherheitsflag
  2. Leaver-Aktionen automatisieren:
    • SSO deaktivieren
    • Alle App-Konten (SCIM & universelle Konnektoren) deprovisionieren
    • Geteilte Zugriffe und Eigentümerschaft (Slack, Notion, GitHub) entziehen/übertragen
    • Lizenzen zurückholen
  3. Verifizieren, dass alles passiert ist:
    • Unveränderliches Prüfprotokoll: Wer, wann, wie
    • Fehlgeschlagene Schritte zur manuellen Nacharbeit markieren

Iden-gestützte Deprovisionierung beseitigt Teil-Offboardings über SCIM- und Non-SCIM-Apps hinweg, auf Basis von HR-Ereignissen und universellen Konnektoren

Automatisierte Lizenzrückgewinnung plus das Umgehen von SCIM-Aufpreis-Upgrades senkt SaaS-Ausgaben um bis zu 30 %

Häufiger Fehler
Offboarding heißt oft nur "Okta deaktivieren und hoffen". SSO ist lediglich die Haustür; Long-Tail-Apps bleiben häufig sperrangelweit offen.

Schritt 8 - Auf kontinuierliche Governance statt Einmal-Skripte setzen

Statische, vierteljährliche CSV-Exporte schützen nicht vor durchgängigen Angriffen.

Stellen Sie auf kontinuierliche Governance um:

  1. Benutzerzugriffsprüfungen (User Access Reviews, UARs) automatisieren: Momentaufnahmen nach Benutzer/App/Berechtigung, risikoreiche Zugriffe vorab markiert; Entzüge automatisiert

Automatisierte UARs und Nachweise sparen schlanken IT-Teams rund 120 Stunden pro Quartal bei der Vorbereitung auf SOC 2/ISO 27001

  1. Unveränderliche Prüfprotokolle führen: Jede Änderung mit Akteurin/Akteur, Kontext und Begründung
  2. Richtlinien kontinuierlich mit der Realität abgleichen:
    • Agentische Workflows erkennen und beheben Berechtigungsabweichungen in Echtzeit

Hier übernehmen KI-gestützte, agentische Workflows: Prüfungen, Nachweissammlung, Deprovisionierung - alles in autonomen Zyklen.

Schritt 9 - Wirkung messen und iterativ verbessern

Wenn sich keine echten Kennzahlen bewegen, ist es nur Theater.

Messen Sie:

  • Manuelle Zugriffs-Tickets pro Woche
    Kundinnen und Kunden von Iden verzeichnen über 80 % weniger Tickets innerhalb von 60 Tagen nach Automatisierung von SCIM- und Non-SCIM-Apps
  • Time-to-Onboard: Von HRIS-Anlage bis zur erteilten Berechtigung
  • Time-to-Offboard: Von HR-Kündigung bis zum bestätigten Entzug
  • Verwaiste Konten pro Audit
  • Vermeidete "SCIM-Tax"-Ausgaben (im Vergleich zu Konnektor-Lizenzen)

Eine Organisation mit 320 Mitarbeitenden und einem 2-köpfigen IT-Team senkte Tickets um 78 % und gewann über 50 % IT-Zeit zurück - mithilfe universeller JML-Workflows

Nutzen Sie diese Kennzahlen, um:

  • den Wert der Automatisierung zu belegen
  • erweiterte Abdeckung zu rechtfertigen
  • überteuerten, reinen SCIM-Enterprise-Plänen zu widersprechen

Alles zusammenführen: Jenseits von SCIM

"Jenseits von SCIM" ist kein Schlagwort. Es bedeutet:

  • SSO + HRIS als Identitäts-Rückgrat
  • SCIM für alle abgedeckten Anwendungen
  • Universelle Konnektoren für jede weitere Anwendung
  • Richtliniengesteuerte, agentische Workflows für die fortlaufende Angleichung an die Realität
  • Unveränderliche Logs & automatisierte Prüfungen für lückenlose Compliance

Teams, die nach diesem Modell arbeiten, reduzieren Tickets um 80 %, sparen pro Quartal über 120 Stunden Compliance-Aufwand und senken SaaS-Ausgaben um bis zu 30 % - mit schlanker IT, ganz ohne IAM-Großprojekt

Wenn Ihre Tools nur SCIM automatisieren, betreiben Sie Identitäts-Theater. Risiko, Tickets und Kosten verstecken sich in den 60-80 %, die außen vor bleiben.

Nächste Schritte

Schnell wachsender SaaS-Anbieter, schlanke IT? Ihr weiterer Weg:

  • Wählen Sie 5-10 besonders wirkungsstarke Non-SCIM-Apps (Notion, Figma, Linear, Finanztools)
  • Formulieren Sie klare JML- und Mover-Richtlinien
  • Testen Sie eine Plattform mit universellen Konnektoren wie Iden
  • Messen Sie Tickets, Bereitstellungszeiten und verwaiste Konten vor und nach dem Pilot

Überspringen Sie 12-Monats-Großprojekte. Starten Sie einen fokussierten Automatisierungs-Pilot. Beweisen Sie Governance über Ihren gesamten Stack - ohne SCIM-Aufschlag, ohne Altlasten.

Hören Sie auf, die menschliche API zu sein. Automatisieren Sie jeden Joiner, Mover, Leaver - über jede Anwendung hinweg, nicht nur über SCIM-abgehakte Kästchen.

FAQ

Wie unterscheidet sich die Automatisierung von JML für Non-SCIM-Apps von reiner SCIM-Nutzung?

SCIM ist dort hervorragend, wo es vorhanden ist. Doch in der Regel deckt es nur 20-40 % Ihres Stacks ab. Der Rest - oft genau die Anwendungen mit den sensibelsten Daten - wird über manuelle Tickets und Tabellen verwaltet.

Universelle Konnektoren erlauben eine einheitliche Richtlinien-Engine für alle Anwendungen. Sie steuern Konten und fein granulare Berechtigungen - selbst für Apps ohne native Provisionierung.

Warum nicht einfach RPA nutzen, um sich durch Oberflächen zu klicken?

RPA funktioniert für einen einzelnen Ablauf, bricht aber bei:

  • UI-Änderungen
  • MFA/CAPTCHA
  • Komplexen Berechtigungsmodellen
  • Fehlenden Audit-Trails

Universelle Konnektoren bringen Modellierung, Fehlertoleranz, Protokollierung und Drift-Erkennung standardmäßig mit - ohne 40 fragile Bots zu bauen.

Brauche ich eine vollständige IGA-Plattform, wenn ich bereits Okta oder Entra habe?

Okta und Entra decken Authentifizierung ab. Sie bieten etwas Lifecycle-Management, aber nur dort, wo SCIM oder APIs vorhanden sind. Tiefe Berechtigungssteuerung und Non-SCIM-/Legacy-Tools bleiben außen vor. Identity-Governance-Plattformen (wie Iden) schließen diese Lücke: vollständige, fein granulare, kontinuierliche Governance - ohne SCIM-Aufschlag, ohne Lücken.

Wie hilft das bei Audits wie SOC 2 oder ISO 27001?

Prüfende wollen im Kern zwei Antworten: "Wer hatte wann worauf Zugriff?" und "Können Sie nachweisen, dass Zugriffe entzogen wurden, als Personen gingen oder Rollen wechselten?"

Universelles JML plus unveränderliche Logs bedeutet:

  • Jede Änderung ist dokumentiert - Akteurin/Akteur, Grund, Kontext
  • UARs werden automatisch erzeugt, zugewiesen und bestätigt
  • Audit-Nachweise sind "schlüsselfertig" - kein hektisches Zusammentragen von Screenshots

Auftragnehmende, Dienstleister, Bots - abgedeckt?

Diese entziehen sich oft den Standard-HR-Abläufen und sind deshalb besonders anfällig für verwaiste Konten. Behandeln Sie sie in Ihrem Design als Erstbürger:

  • Lebenszyklus-Steuerung basierend auf Attributen, Verträgen und Projekten
  • Zeitlich begrenzte Zugriffe mit automatischem Ablauf
  • Gesteuert durch dieselben Richtlinien und Konnektoren wie für Mitarbeitende

Joiner-Mover-Leaver gilt hier genauso - nur, dass HR-Trigger durch Vertrags- oder Systemereignisse ersetzt werden.

Book a call