Jedes schnell wachsende Tech-Unternehmen stößt an denselben Punkt: Onboarding und Offboarding, die früher "ausreichend" waren, werden plötzlich zum Sicherheitsrisiko und zur Quelle endloser Tickets.
Neue Entwickler warten Tage auf Zugänge zu GitHub und Notion. Ausgeschiedene Mitarbeitende tauchen noch immer in Jira auf. Ihr schlankes IT-Team wird zur menschlichen Bereitstellungsschicht zwischen Menschen und Werkzeugen.
Eine Studie unter ehemaligen Mitarbeitenden in den USA, Großbritannien und Irland ergab, dass 83 % nach ihrem Ausscheiden weiterhin Zugriff auf mindestens ein Firmenkonto hatten. Das ist nicht nur schlechtes Personalmanagement - es trifft Sicherheit, Compliance und SaaS-Kosten direkt ins Mark.
Dieser Leitfaden führt Sie Schritt für Schritt durch einen praxisnahen Ansatz, um:
- spontane Bereitstellung in wiederholbare, automatisierte Onboarding-Prozesse zu verwandeln
- Offboarding so zu bauen, dass Zugriffe wirklich geschlossen werden
- externe Dienstleister, Bots und jede neue "Identitäts-Spezies" abzudecken
- all das ohne zusätzliches Personal zu schaffen - mit Iden, wenn Sie vollständige Abdeckung wollen
Was Sie vor dem Start brauchen
Sie brauchen kein eigenes IAM-Team. Aber Sie brauchen:
- Ein Identitäts-Rückgrat - einmalige Anmeldung oder Identitätsanbieter wie Okta oder Microsoft Entra oder zumindest ein zentrales Verzeichnis
- Ein führendes Personalsystem - HRIS (BambooHR, Personio, Workday usw.)
- Ein App-Inventar - die 20-40 Anwendungen, die Ihr Tech-Team tatsächlich nutzt (Slack, GitHub, Jira, Notion, Figma usw.)
- Klare Teamstrukturen - grundlegende Rollen (Backend Engineer, SRE, Data Engineer, Externe/r, usw.)
- Rückhalt im Management - die Bereitschaft, Zugriffsverwaltung zu standardisieren
Tipp
Wenn Sie davon noch nichts haben, fangen Sie mit dem App-Inventar und einfachen Rollen an. Chaos lässt sich nicht automatisieren.
Schritt 1 - Den realen Lebenszyklus Ihrer Tech-Belegschaft abbilden
Die meisten Probleme beim Onboarding und Offboarding entstehen, weil niemand genau weiß, was heute tatsächlich passiert.
- Joiner, Mover, Leaver dokumentieren.
- Joiner: Neueinstellungen, Praktikanten, Externe.
- Mover: Beförderungen, Teamwechsel, Wechsel von Vorgesetzten/Standorten.
- Leaver: Kündigungen, Entlassungen, Vertragsende.
- Aktuelle Auslöser erfassen.
- Wer informiert die IT über eine Neueinstellung? HR, ein Ticket, eine Slack-Nachricht?
- Bei Leavern: Welches System erfährt es zuerst - HR, Führungskraft, Lohnbuchhaltung?
- Jeden Kontaktpunkt auflisten.
Für eine kürzlich eingestellte Entwicklerperson jeden Schritt von Vertragsunterschrift bis zum ersten Deploy dokumentieren: Konten, Gruppen, Repositories, bereitgestellte SaaS-Tools.
Häufiger Fehler
Dies zu überspringen und direkt in Tools zu investieren. Wenn Sie Ihren echten Prozess nicht verstehen, automatisieren Sie nur den falschen - schneller.
Schritt 2 - Rollen und Zugriffsprofile standardisieren
Sie können Bereitstellung nicht skalieren, wenn jede Person ein Sonderfall ist.
- Einige wenige Standardrollen definieren.
Beispiel:- Backend Engineer
- Frontend Engineer
- SRE / Platform
- Data Engineer
- Customer Support Engineer
- Externe/r Dienstleister (Engineering)
- "Grundausstattungs"-Zugriffsprofile für jede Rolle erstellen.
Für jede Rolle festlegen:- Anwendungen, die sie immer erhalten (E-Mail, Slack, Confluence, Jira, GitHub, Feature-Flag-Tools usw.)
- Die jeweilige Zugriffsebene (Slack-Kanäle, GitHub-Repositories, Jira-Projekte, Rollen im Data Warehouse)
- Kontextregeln ergänzen.
- Standort (z. B. EU- vs. US-Datenzugriff)
- Team (Platform vs. Product Engineering)
- Seniorität (wer Produktionszugriff freigeben darf)
Tipp
Halten Sie Profile bewusst klar und schlank. "Engineer (Product)" plus ein paar Zusatzpakete lässt sich viel leichter automatisieren als 50 Mikro-Rollen, die niemand pflegt.
Schritt 3 - Quellen der Wahrheit verbinden und Lebenszyklus-Ereignisse definieren
Onboarding-Automatisierung hängt von sauberen Ereignissen ab.
- Primäre Quelle der Wahrheit für Personen wählen.
Für die meisten Tech-Unternehmen ist das das HRIS (Personio, BambooHR, Rippling, Workday usw.). - Diese mit Ihrer Identitätsschicht verbinden.
- Neueinstellung im HRIS -> Identität im IdP (Okta/Entra) wird angelegt
- Rollen- oder Abteilungswechsel -> aktualisiert Gruppen/Rollen
- Beendigungsdatum gesetzt -> löst Entzug von Zugriffsrechten aus
- Ereignisse in Klartext definieren.
Beispiel:event = new_employee UND department = Engineering-> Profil "Engineer (Product)" zuweisenevent = employment_status = terminated-> vollständigen Offboarding-Workflow ausführen
Häufiger Fehler
Sich darauf zu verlassen, dass Führungskräfte Offboarding-Tickets eröffnen. So entstehen verwaiste Konten.
Schritt 4 - Onboarding schrittweise automatisieren
So kommen Sie von manueller Bereitstellung zu echter Onboarding-Automatisierung.
Apps der ersten Woche priorisieren.
Starten Sie mit 10-15 Werkzeugen, die jede Entwicklerperson braucht: SSO, E-Mail, Slack/Teams, GitHub/GitLab, Jira/Linear, Notion/Confluence, CI/CD, Observability.Entscheiden, wie jede App bereitgestellt wird.
- SCIM-fähige Anwendungen: über IdP oder IGA-Plattform anbinden
- Nur-API-Anwendungen: über moderne IGA-Lösung oder eigene Automatisierung einbinden
- Keine SCIM, keine API: über universelle Konnektoren oder agentische Workflows (KI-gesteuerte, autonome Abläufe, die wie ein menschlicher Operator handeln)
Eine Analyse von 721 populären SaaS-Anwendungen ergab, dass 57 % keinerlei SCIM-Unterstützung zu irgendeinem Preis bieten - weshalb so viele Stacks an der "SCIM-Mauer" zerschellen.
Ihre Automatisierungs-Engine wählen.
Sie können selbst skripten, die Lebenszyklusfunktionen Ihres IdP nutzen oder eine vollständige Plattform wie Iden wählen.- Iden verbindet sich mit SCIM- und Nicht-SCIM-/Nicht-API-Tools über Plug-and-Play-Konnektoren.
- Richtlinien wählen den passenden Zugriff für jede Neueinstellung; agentische Workflows führen die vollständige Bereitstellung aus.
Mit einem Team pilotieren.
Starten Sie mit Product Engineering, messen Sie Zeit bis zum ersten Commit und Ticketvolumen - und weiten Sie dann aus.
Tipp
Instrumentieren Sie alles. Messen Sie "HRIS-Anlage -> Entwickler hat Zugriff" und "Tickets pro Neueinstellung". Wenn die Automatisierung das nicht verbessert, ist sie nicht fertig.
Schritt 5 - Offboarding sofortig und vollständig machen
Die meisten Sicherheitsvorfälle durch ehemalige Mitarbeitende sind die Folge von unvollständigem Offboarding.
Untersuchungen in Unternehmen in den USA und Europa zeigen, dass nur etwa ein Viertel strenge Prozesse zum Zugriffsentzug nach dem Ausscheiden befolgt. Die Mehrheit räumt ein, dass Ex-Mitarbeitende weiterhin auf Konten zugreifen können.
Offboarding sollte eine Sicherheitskontrolle sein, keine HR-Checkliste.
- Offboarding aus HR oder IdP heraus auslösen.
Wenn eine Beendigung erfasst wird (oder ein Vertrag ausläuft):- Hauptkonto deaktivieren (SSO/IdP)
- Sitzungen und Token ungültig machen
- Entzug in allen Anwendungen einreihen
- Jeden Zugangspfad entziehen.
- SSO-Apps
- Direkte Logins
- Geteilte Konten
- Git-Repos, Cloud-Konsolen, CI/CD, Monitoring-Werkzeuge
- Lizenzen und Schlüssel zurückholen.
- SaaS-Sitzplätze entfernen
- API-/SSH-Schlüssel und persönliche Token drehen
- Ressourcenübernahme organisieren (Repos, Dashboards, Projekte)
- Audit-Nachweise automatisieren.
Protokollieren, wer wann aus welchen Systemen nach welcher Richtlinie entfernt wurde. Iden speichert dies in unveränderlichen Audit-Logs - damit Sie jederzeit wissen, "wer wann worauf Zugriff hatte".
Häufiger Fehler
Offboarding als Checkliste in irgendeiner Notion-Seite zu führen. Wenn diese Person krank ist oder das Unternehmen verlässt, bricht Ihr Prozess zusammen.
Mit Iden wird Offboarding berührungslos: Eine Beendigung im HRIS oder IdP löst vollständigen Entzug aus - inklusive der SaaS-Tools, die vom SSO nicht erfasst werden. Über alle Iden-Kunden hinweg beseitigen automatisierte Workflows innerhalb der ersten 60 Tage rund 80 % der manuellen Zugriffs-Tickets, indem sie manuelles Onboarding und Offboarding drastisch reduzieren.
Schritt 6 - Externe, Bots und andere neue Identitäten abdecken
Schnell wachsende Teams stützen sich auf:
- Externe und Agenturentwickler
- Dienstkonten und CI/CD-Bots
- KI-Agenten und Automatisierungstools
Diese passen selten in rein HR-gesteuerte Lebenszyklen.
- Nicht-Mitarbeitende in eine Quelle der Wahrheit aufnehmen.
Nutzen Sie das Modell für Zeitarbeitskräfte Ihres HRIS oder ein leichtgewichtiges Verzeichnis mit:- Verantwortliche/r (interne/r Sponsor/in)
- Zweck
- Ablaufdatum
- Dieselben Zugriffsregeln anwenden.
- Standardprofile (z. B. "Contract Engineer - Nur Lesen")
- Zeitlich begrenzter Zugriff für hochkritische Systeme
- Automatischer Entzug zum Enddatum
- Für jede nicht-menschliche Identität eine/n Owner verlangen.
Kein Owner, kein Zugriff.
Tipp
Geben Sie einem Bot Produktionszugriff nur mit klarem Zweck, streng abgegrenztem Umfang und expliziter Überprüfung - so wie bei einer Senior-Engineer-Rolle.
Die einheitliche Sicht von Iden auf menschliche und nicht-menschliche Identitäten macht das praktikabel - alle Identitäten, alle Berechtigungen, eine Steuerungsebene.
Schritt 7 - Kontinuierliche Governance und prüfbereite Nachweise ermöglichen
Vierteljährliche Zugriffsüberprüfungen und Einzel-Audits kommen mit permanenten Angriffsversuchen nicht mehr mit.
Ziel ist kontinuierliche Governance:
- Echtzeit-Entscheidungen: Zugriffsanfragen werden auf Basis von Richtlinien und Kontext bewertet - nicht per E-Mail durchgewunken.
- Automatisierte Zugriffsüberprüfungen: Führungskräfte bestätigen oder entziehen Zugriffe aus einer einzigen Ansicht, Audit-Nachweise werden sofort erzeugt.
- Agentische Workflows: KI-gesteuerte Workflows in Iden markieren ruhende Zugriffe, Verstöße gegen Funktionstrennung (Segregation of Duties, SoD) und verwaiste Konten - und beheben oder eskalieren diese.
Automatisierte Zugriffsüberprüfungen sparen mittelständischen Teams im Jahresverlauf rund 120 Stunden - und machen die nächste Prüfungsrunde zur Routine.
Lizenizrückgewinnung und das Vermeiden von teuren Enterprise-Upgrades, die nur SCIM freischalten, können die SaaS-Ausgaben schnell wachsender Unternehmen um bis zu 30 % senken.
Nächste Schritte: das Ganze in Ihrem Unternehmen umsetzen
Wenn Sie ein schlankes IT-Team in einem Tech-Unternehmen mit 50-2.000 Mitarbeitenden sind, brauchen Sie kein einjähriges IAM-Großprojekt - Sie brauchen einen konkreten 90-Tage-Plan:
- Wochen 1-2: Joiner-Mover-Leaver-Flows abbilden; 5-8 Rollen definieren.
- Wochen 3-6: HRIS mit IdP verbinden; Onboarding für die 10 wichtigsten Apps automatisieren.
- Wochen 7-10: Berührungsloses Offboarding einführen, inklusive nicht-menschlicher Identitäten.
- Wochen 11-12: Kontinuierliche Zugriffsüberprüfungen und Nachweiserfassung ergänzen.
Plattformen wie Iden liefern vollständige Abdeckung (SCIM- und Nicht-SCIM-Apps), fein granulare Steuerung bis auf Kanal-/Repo-/Projektebene und Automatisierung, die schlanke IT-Teams problemlos betreiben können.
Iden automatisiert derzeit die Bereitstellung für mehr als 175 Anwendungen: GitHub, Notion, Slack, Figma, Linear und viele mehr - mit neuen Konnektoren in teils weniger als 48 Stunden.
Wenn Sie es leid sind, das menschliche Bindeglied zwischen HR-Tickets und SaaS-Apps zu sein, ist es Zeit, richtliniengesteuerte, agentische Workflows die repetitive Identitätsarbeit übernehmen zu lassen - damit Ihr Team wieder bauen kann, statt Benutzer anzulegen.
FAQ: Onboarding und Offboarding skalieren
Ab welcher Größe wird das wirklich wichtig?
Wenn Sie 5-20 Personen pro Monat einstellen - oder mehr als etwa 20 geschäftskritische SaaS-Tools betreiben - beginnt manuelles Onboarding und Offboarding zu bröckeln. Sie sehen längere Wartezeiten, uneinheitliche Berechtigungen und "Zombie-Konten". Für die meisten Tech-Unternehmen in den USA, Großbritannien und dem DACH-Raum tritt dieser Effekt zwischen 50 und 300 Mitarbeitenden auf.
Brauchen wir ein dediziertes IAM-Team, um das Benutzerlebenszyklus-Management zu automatisieren?
Nein. Moderne Plattformen wie Iden sind für schlanke IT-Teams gebaut. Richtlinien und Konnektoren erledigen die Hauptarbeit; die IT definiert Regeln und behandelt Ausnahmen - statt Skripte zu babysitten oder Integrationen von Hand zu bauen.
Sollte HR oder IT das Onboarding und Offboarding verantworten?
HR verantwortet, wann Ereignisse eintreten (Einstellung, Wechsel, Austritt). Die IT verantwortet, wie sich diese Ereignisse in Zugriffsänderungen übersetzen. Der sauberste Ablauf: HR aktualisiert das HRIS, das wiederum richtliniengesteuerte Änderungen in Ihrer Identitätsschicht auslöst.
Wie gehen wir mit Mitarbeitenden um, die Teams oder Rollen wechseln?
Behandeln Sie Mover als gleichwertige Ereignisse, nicht als Ad-hoc-Anfragen. Ein Rollenwechsel im HRIS sollte:
- das neue Zugriffsprofil hinzufügen
- das alte entfernen - statt Rechte immer weiter anzusammeln
- für hochkritische Systeme eine Managerprüfung anstoßen
Was ist mit Bots, CI/CD-Konten und KI-Agenten?
Behandeln Sie sie wie Benutzer:
- Sie sind in einer Quelle der Wahrheit erfasst
- Sie haben eine/n Owner und ein Ablaufdatum
- Sie erhalten minimal notwendige, zeitlich begrenzte Rechte
- Sie sind in kontinuierliche Überprüfungen einbezogen
So verhindern Sie, dass eine "neue Spezies von Identitäten" zu Ihrer größten Blindstelle wird.


