Das meiste Identity Lifecycle Management besteht aus zwei Systemen, die nichts voneinander wissen.
Das erste ist Ihr IdP: Okta, Entra, Google Workspace. Er übernimmt die Authentifizierung für alles und die Provisionierung für die Applikationen, die SCIM in dem Tarif unterstützen, den Sie bezahlen. Das sind meist zehn bis zwanzig, und die funktionieren gut.
Das zweite ist ein Dokument. Eine Checkliste für das Onboarding, eine Tabelle für das Offboarding, eine Kalendererinnerung, die Austritte des letzten Monats zu prüfen. Es deckt alles ab, was das erste System nicht abdeckt, und das ist in den meisten Umgebungen die größere Hälfte.
Niemand hat das so entworfen. Es ist das, womit man endet, wenn ein Werkzeug ein Drittel des Problems abdeckt und der Rest trotzdem passieren muss.
Warum die zweite Hälfte die schmerzhafte ist
In den Applikationen hinter dem SSO bleiben keine Accounts offen. Dort ist das Deprovisioning am besten, die Verantwortung am klarsten, und wenn etwas schiefgeht, fällt es am schnellsten auf.
Der Schaden entsteht in der anderen Gruppe, und er hat ein bestimmtes Muster.
Das Dokument, das jemand von der letzten Einstellung kopiert und anpasst. Es stimmt, bis sich die Organisation ändert und niemand es nachzieht.
Eine Zeile pro Applikation, von Hand abgehakt. Sie belegt, dass jemand ein Häkchen gesetzt hat, nicht dass ein Account geschlossen wurde.
Eine wiederkehrende Erinnerung, zu prüfen, ob die Austritte des letzten Monats wirklich weg sind. Meistens sind sie es nicht.
Zugriff über eine Gruppe, die vor zwei Umstrukturierungen sinnvoll war und heute mehr freigibt, als irgendwer vorhatte.
Jedes Einzelne davon ist für sich vernünftig. Zusammen ergeben sie ein System ohne Gedächtnis, und das ist das eigentliche Problem. Eine Checkliste hält fest, dass ein Schritt ausgeführt wurde. Sie hält nicht fest, warum der Zugriff bestand. Wechselt die Person also das Team, lässt sich nicht ermitteln, welche ihrer vierzehn Berechtigungen mitgehen sollten und welche nicht.
Also wird nichts entfernt. Zugriffe sammeln sich über eine ganze Laufbahn an, eine stille Beförderung nach der anderen, und das erste Mal, dass jemand genau hinsieht, ist ein Access Review.
Ein Plan pro Person, bei jeder Änderung neu berechnet
Iden führt für jede Identität einen lebenden Datensatz: was sie haben sollte, was sie tatsächlich hat und welches System das gesagt hat.
Das Soll kommt aus der Policy: Abteilung, Position, Führungskraft, Beschäftigungsart, Standort. Das Ist kommt von den Konnektoren, die jede Applikation direkt lesen, statt etwas anzunehmen. Wo beides auseinandergeht, liegt die Arbeit.
Das dreht die Checkliste um, und darauf kommt es an. Eine Checkliste ist eine Liste von Aktionen, die jemand ausführen muss. Ein Plan ist die Beschreibung eines korrekten Zustands, und die Aktionen ergeben sich daraus. Damit kann der Plan eine Frage beantworten, die eine Checkliste nicht beantworten kann: Warum hat diese Person das, und was soll damit passieren, wenn sich ihre Rolle ändert?
Neun Workflows in drei Gruppen. Entscheidend ist die Spalte mit den Applikationen: Das Basis-Onboarding betrifft 32, ein Standortwechsel nur 3.
Workflows sind der Weg, auf dem der Plan angewendet wird, und es gibt drei Gruppen, weil sich ein Datensatz auf drei Arten ändern kann: Eintritt, Wechsel, Austritt. Darunter ist jede dieselbe Operation: neu berechnen, dann die Differenz anwenden.
Onboarding, entschieden vor dem ersten Tag
Eine neue Person erscheint Tage oder Wochen vor dem Start im HRIS. Die meisten Prozesse verschenken diese Zeit, weil es noch nichts zu tun gibt und keinen Ort für eine Entscheidung, die noch nicht eingetreten ist.
Iden baut den Plan in diesem Moment und hält ihn. Die Führungskraft sieht genau, wie der erste Tag aussehen wird, und kann ihn bis zum Morgen der Ausführung ändern. In keiner Applikation existiert etwas vor dem Startdatum, ein verschobener Start kostet also nichts.
Derselbe Workflow als Definition und als Durchlauf. Darunter drei Accounts für eine Einstellung, jeder mit eigener Ticket-ID.
Zwei Dinge in diesem Bild sind erwähnenswert.
Der Workflow ist ein Graph und keine Liste, weil Onboarding Verzweigungen hat, mit denen eine Checkliste schlecht umgeht. Hat diese Person schon ein Google-Konto aus einem früheren Auftrag? Ist die Adresse belegt? Ist sie gesperrt statt abwesend? Eine Liste muss von jemandem gelesen werden, der die Antworten kennt. Ein Graph hält sie einmal fest.
Und jede Provisionierungsaufgabe hat ihre eigene Ticket-ID. Das klingt nach Installationsdetail und ist genau der Punkt: Die Applikation ohne SCIM bekommt eine ID wie die, die eines haben. Es gibt keine zweite Klasse von Applikationen, die auf einer anderen Liste lebt.
Externe Dienstleister sind der schwierigere Fall
Ein Dienstleister ist ein Eintritt mit Enddatum, und das Enddatum ist der Teil, den alle verlieren.
Feste Austritte fallen auf. Jemand kündigt, es gibt ein Gespräch, HR erfasst es. Ein Dienstleisterauftrag endet einfach, oft ohne jedes Ereignis, und der Zugriff überlebt die Person um Monate, weil nie etwas geplant war, das ihn beendet.
Steht das Enddatum im HRIS, setzt Iden es durch. Steht es nicht dort, lohnt sich das vor allem anderen auf dieser Seite, denn es ist die häufigste einzelne Ursache für Accounts, die ihre Person überleben.
Der Rollenwechsel, um den sich niemand kümmert
Ein Eintritt ist sichtbar. Ein Austritt ist dringend. Ein Wechsel ist keines von beidem, also werden die Ergänzungen gemacht und der Entzug nicht.
Wechselt jemand von Sales Ops zu Customer Success, kann eine Checkliste sagen, was Customer Success braucht. Sie kann nicht sagen, welche der bestehenden Berechtigungen aus Sales Ops kamen und welche von woanders, weil sie den Grund nie erfasst hat. Der sichere Weg ist also, das Neue zu ergänzen und das Alte zu lassen, und genau das passiert fast überall.
Iden rechnet neu und erzeugt eine Differenz. Berechtigungen aus der alten Abteilung sind nicht mehr begründet und werden entfernt. Berechtigungen, die aus einem anderen Grund bestehen, eine Projektgruppe, eine bewusst gemachte Ausnahme, bleiben, weil der Datensatz weiß, dass sie nie an die Abteilung gebunden waren.
Diese Unterscheidung ist der ganze Wert daran, einen Plan zu führen statt einen Workflow auszuführen.
Ein Offboarding, das Sie belegen können
Der letzte Tag hat eine Uhr, und hier zeigt sich das Zwei-System-Setup am deutlichsten. Die SSO-Applikationen sind in Sekunden fertig. Der Rest ist eine Tabelle, die jemand abarbeitet, meist neben der eigentlichen Arbeit.
Iden führt den gesamten Satz in einem Durchlauf aus und hält fest, wie jede Applikation geschlossen wurde: per SCIM deprovisioniert, über die Administrationsoberfläche geschlossen, an einen Verantwortlichen übertragen. Das sind unterschiedliche Zusicherungen, und ein einzelnes grünes Häkchen für alle würde genau das verbergen, was Sie eigentlich belegen wollen.
Die Reihenfolge zählt hier, und sie ist nicht offensichtlich. Die Datenübergabe läuft vor dem Löschen, weil ein gelöschtes Google-Konto seine Drive-Inhalte mitnimmt. Sitzungen werden beendet, bevor Zugangsdaten rotieren, weil ein neues Passwort keine Sitzung beendet, die schon offen ist. Umgekehrt ist beides falsch, und beides ist genau die Art Fehler, die jemand macht, der das an einem Freitag um 17 Uhr erledigt.
Was nicht entschieden werden kann, geht mit dem Kontext an den Verantwortlichen der Applikation, und das Offboarding bleibt offen, bis es zurückkommt. Ein unvollständiger Austritt wird nie als abgeschlossener erfasst.
Was sich tatsächlich ändert
Die Zeile, über die es sich zu streiten lohnt, ist die dritte. Alles andere folgt daraus: Wenn die Applikationen ohne SCIM auf einer Checkliste bleiben, bleibt die Checkliste, und mit ihr alles, was dazugehört.
Was das nicht leistet
Es ersetzt Ihren IdP nicht. Die Authentifizierung bleibt, wo sie ist, und die Applikationen, die Okta oder Entra schon gut provisionieren, können dort weiter provisioniert werden. Iden liest aus Ihrem IdP und deckt die Lücke darum herum ab.
Es nimmt Ihnen die Abwägung nicht ab. Ein geteilter Admin-Account ohne klaren Verantwortlichen, eine Lizenz, die teuer genug ist, dass ihre Rückgabe eine Budgetentscheidung ist, eine Applikation, in der die austretende Person der einzige Administrator war: Das sollte einen Menschen erreichen, und das tut es.
Und es repariert kein HRIS, das niemand pflegt. Jeder Mechanismus hier wird davon ausgelöst, dass sich ein Datensatz ändert. Wenn Dienstleister nicht im System sind oder Austrittsdaten eine Woche zu spät erfasst werden, beheben Sie das zuerst. Kein Identity-Tool erledigt das für Sie.