Verwaiste Konten: Offboarding und Deprovisioning richtig abschliessen

Wenn Sie die IT eines Unternehmens mit 50 bis 500 Mitarbeitenden verantworten und eine Zugriffsüberprüfung oder ein ISO-27001-Audit gerade aktive Konten von längst ausgeschiedenen Personen zutage gefördert hat, ist diese Seite für Sie. Wenn Sie nur die Definition von Deprovisioning suchen, liefert der erste Abschnitt sie in dreissig Sekunden.

Deprovisioning ist der Entzug von Zugriffsrechten, Konten und Berechtigungen einer Person, wenn sie das Unternehmen verlässt, die Rolle wechselt oder ein Mandat beendet. Ein verwaistes Konto ist das, was übrig bleibt, wenn dieser Entzug unvollständig war: ein aktives Konto ohne rechtmässigen Eigentümer. Ein sauberer Offboarding-Prozess verhindert neue verwaiste Konten. Er schliesst keines der bereits offenen, und diese liegen überwiegend in Anwendungen, die Ihr Identity Provider nie abgedeckt hat.

Was ist Deprovisioning und was wird dabei genau entzogen?

Deprovisioning ist die operative Hälfte des Identitäts-Lebenszyklus, rückwärts gelesen. Wo das Provisioning eine Identität anlegt, Berechtigungen zuweist und Zugriff gewährt, entzieht das Deprovisioning sie wieder: es deaktiviert die Authentifizierung, widerruft Anwendungsberechtigungen, beendet offene Sitzungen, überträgt Datenbesitz und zieht technische Zugangsdaten wie API-Schlüssel und Tokens ein.

Ausgelöst wird es durch drei Ereignisse, nicht durch eines. Ein Austritt beendet das Arbeitsverhältnis. Ein interner Wechsel verändert die Rolle und sollte die Berechtigungen der alten Rolle entfernen. Ein Mandat oder Dienstleistungsvertrag endet. Beim zweiten und dritten Auslöser scheitern die meisten Unternehmen unbemerkt, weil üblicherweise nur der erste an das HR-System angebunden ist.

Wird ein deprovisioniertes Konto deaktiviert oder gelöscht?

Die Quellen, die zu dieser Frage ranken, widersprechen einander, und der Unterschied hat rechtliche Folgen. Beyond Identity beschreibt einen gleichzeitigen Entzug über alle Systeme. Delinea beschreibt ein deaktiviertes oder gelöschtes Objekt. Saviynt ergänzt den Entzug von Zugangsdaten und personenbezogenen Daten. Die IT-Richtlinie der Fordham University spricht von ausgesetztem oder deaktiviertem Zugriff.

Die Entscheidung ist keine Geschmacksfrage. Nach ISO/IEC 27001:2022, Anhang-A-Massnahme 5.18, ist jede Änderung der Zugriffsrechte eines Benutzers zu protokollieren, und Massnahme 6.5 regelt Pflichten, die das Arbeitsverhältnis überdauern. Für ein gelöschtes Konto können Sie dieses Protokoll nicht vorlegen. Die DSGVO zieht in die andere Richtung: Artikel 5 Absatz 1 Buchstabe e begrenzt, wie lange Daten in identifizierbarer Form aufbewahrt werden.

Die praktikable Antwort für eine IT-Abteilung im Mittelstand: zuerst deaktivieren, dann nach dokumentiertem Zeitplan löschen. Deaktivieren Sie sofort, damit sich das Konto nicht mehr authentifizieren kann, bewahren Sie den Datensatz und seine Zugriffshistorie für die in Ihrem ISMS und Ihrem Verarbeitungsverzeichnis festgelegte Frist auf, und löschen Sie danach. Wer Ihnen rät, am ersten Tag zu löschen, optimiert Ordnung auf Kosten Ihres nächsten Audits.

Was ist ein verwaistes Konto?

Ein verwaistes Konto ist ein aktives Konto ohne erkennbaren Eigentümer, meist zurückgeblieben nach unvollständigem Deprovisioning. Es unterscheidet sich vom ruhenden Konto, das einen Eigentümer, aber keine aktuelle Aktivität hat, und vom inaktiven Konto, das schlicht ungenutzt ist. Verwaist ist die gefährliche Kategorie, weil niemand da ist, um eine Anmeldung zu bemerken. Der Eigentümer kann eine ehemalige Mitarbeiterin sein, ein ehemaliger Dienstleister, oder niemand, wenn es sich um ein Servicekonto handelt, dessen Ersteller das Unternehmen verlassen hat. Die vollständige Definition steht im Glossareintrag zu Deprovisioning.

Ihr Offboarding ist sauber. Ihr Kontenbestand ist es nicht.

Das meiste, was zu diesem Thema veröffentlicht wird, behandelt Deprovisioning als Prozessproblem: den HR-Auslöser richtig verdrahten, den Identity Provider anbinden, die Checkliste abarbeiten. Dieser Rat ist richtig und er löst den Fluss. Am Bestand ändert er nichts.

Der Bestand sind die Konten, die heute bereits offen sind, angelegt bevor Ihr Prozess verschärft wurde, in Anwendungen, die dieser Prozess nie abgedeckt hat. Für sie wird kein Austrittsereignis ausgelöst, weil es keinen Austrittsdatensatz gibt, aus dem es entstehen könnte. Man findet sie durch Inventur, nicht durch Workflow.

Wie gross diese Lücke ist, zeigen die veröffentlichten Corma-Kundenberichte. In jedem Fall hatte das Unternehmen ein Inventar, das es für korrekt hielt, und die Discovery lieferte eine andere Zahl.

Satelia ist der klarste Fall, weil die Folge dokumentiert ist. Das Unternehmen kam bei den Zertifizierungen ISO 27001 und SOC 2 nicht weiter, solange ein prüfbarer Überblick über die tatsächlich genutzten SaaS-Anwendungen fehlte, und der eigene Bericht führt die Auflösung genau darauf zurück. Die vollständige Geschichte steht im Kundenbericht zur Identity Governance bei Satelia.

Lesen Sie die Tabelle als Verhältnis, nicht als absolute Zahlenreihe. In jeder Grössenordnung von 30 bis 340 Mitarbeitenden war der reale Anwendungsbestand deutlich grösser als der erfasste. Jede Anwendung in dieser Differenz kann Konten enthalten, die Ihr Austrittsprozess nie berührt hat.

Eine Warnung zu den Risikozahlen, die Ihnen bei der Recherche begegnen. Die derzeit auf Platz eins rankende englischsprachige Seite, der OneLogin-Leitfaden zu Provisioning und Deprovisioning, nennt weiterhin durchschnittliche Kosten von 148 Dollar pro Datensatz und 7,91 Millionen Dollar pro Datenschutzverletzung in den USA, auf einer Seite, deren Metadaten eine Änderung am 21. August 2026 ausweisen. Diese Zahl stammt von IBM aus dem Jahr 2018, und IBM rechnet längst nicht mehr in Kosten pro Datensatz. Die Ausgabe 2026 des IBM Cost of a Data Breach Report, veröffentlicht am 29. Juli 2026, nennt einen weltweiten Durchschnitt von 4,99 Millionen Dollar. Prüfen Sie den Jahrgang jeder Breach-Statistik, bevor sie in eine Vorlage für die Geschäftsleitung wandert.

Woher kommen verwaiste Konten wirklich?

Aus vier Quellen, und nur eine davon beschreiben die meisten Artikel.

Anwendungen, die Ihr Identity Provider nie abgedeckt hat

Ihr Identity Provider ist massgeblich für die Anwendungen, die an ihn angebunden sind. Zu allem anderen schweigt er. Ein Team kauft ein Tool auf die Firmenkarte, meldet sich mit E-Mail und Passwort an, und das Tool taucht nie im SSO-Katalog auf. Beim Austritt schliesst die Deaktivierung des Verzeichniskontos die Vordertür und lässt dieses Tool unberührt.

Das ist kein Gedankenspiel. Auf r/sysadmin beschrieb ein Administrator mit Okta als SSO rund 40 Anwendungen, die nie sauber in den Identity-Stack integriert wurden, darunter interne Engineering-Werkzeuge. Genau dort überleben verwaiste Konten, und das Schliessen dieser Lücke verlangt eine Discovery, die innerhalb und ausserhalb des SSO-Perimeters arbeitet, über Browser und Endgerät statt allein über das Verzeichnis.

Dienstleister, die nie im HR-System angelegt wurden

Freelancer, Agenturpersonal und externe Spezialisten werden häufig ausserhalb der Personalabteilung eingebunden. Sie erhalten Konten, das Mandat endet, ein Austrittsdatensatz entsteht nie, also wird kein Auslöser aktiv. Die regulatorische Einordnung ist eindeutig: Verordnung (EU) 2024/2690 verlangt, Zugriffsrechte Dritter wie Lieferanten und Dienstleister in Umfang und Dauer zu begrenzen, was voraussetzt, dass Sie von ihnen wissen.

Interne Wechsel, die Austritte, die niemand meldet

Ein interner Wechsel ist ein teilweiser Austritt. Die Person behält ihre Identität und sollte einen Satz Berechtigungen verlieren. In der Praxis sammeln sie sich an. Nach zwei oder drei Wechseln hält eine Person Rechte, die eine Laufbahn abbilden statt einer Stelle, und jede aufgegebene Berechtigung ist eine verwaiste Rechtezuweisung an einem lebenden Konto. Die Zugriffsüberprüfung ist die Kontrolle, die sie sichtbar macht.

Was, wenn der Anbieter für SSO extra verlangt?

Dieser Einwand kommt ständig und fast niemand schreibt darüber. Ein IT-Leiter formulierte es auf r/ITManagers so: Wenn der Anbieter SSO nicht unterstützt oder es einer teureren Stufe vorbehält, kann das Team auf der Identitätsebene nichts ausrichten. Das ist eine Budgetgrenze, keine Sicherheitsentscheidung, und sie erzeugt dauerhaft Konten ausserhalb des Perimeters.

Die Antwort besteht nicht darin, gegen die Preisliste anzukämpfen. Behandeln Sie diese Anwendungen als benannte Ausnahmeliste mit einem eigenen manuellen oder agentengestützten Offboarding-Schritt, und halten Sie diese Liste bewusst kurz. Corma beschreibt die technischen Optionen im Leitfaden zum Offboarding von Anwendungen ohne SCIM, SAML oder SSO.

Die Konten ohne Austrittsdatum

Servicekonten, API-Tokens, OAuth-Integrationen und KI-Agenten sind Identitäten. Sie authentifizieren sich, halten Berechtigungen und bewegen Daten. Sie haben weder Arbeitsvertrag noch Vorgesetzte noch einen letzten Arbeitstag, weshalb kein HR-gesteuerter Prozess sie je deprovisionieren wird.

Nikolai Fomm, COO und Mitgründer von Corma, benannte das Problem in einem Beitrag vom 17. August 2026 direkt: Diese Identitäten wurden nie über den Identity Provider provisioniert, sie tauchen in keiner Austritts-Checkliste auf, und die meisten haben keinen Eigentümer. Die vollständige Argumentation steht im Corma-Leitfaden zur Sicherheit nicht-menschlicher Identitäten, ergänzt durch den Glossareintrag zum Identitäts-Lebenszyklus-Management.

Überraschend ist für IT-Teams vor allem das Volumen. Obsidian Security berichtet, dass Kunden typischerweise mit rund 900 OAuth-Integrationen zu Google, 750 zu Microsoft und 150 zu Salesforce starten, und dass über 70 Prozent dieser Integrationen seit 90 Tagen oder länger inaktiv sind, ohne ihre erteilten Berechtigungen zu verlieren. Ein API-Schlüssel, 2022 für eine einmalige Migration erstellt, in eine Tabelle kopiert und nie widerrufen, ist faktisch ein dauerhaftes Zugangsmittel ohne Ablauf.

Wie Sie die bereits vorhandenen verwaisten Konten finden

Discovery ist ein Abgleich. Gesucht sind Konten, die in einer Anwendung existieren, denen aber keine aktive Person in Ihrem Führungssystem gegenübersteht. Fünf Schritte, in dieser Reihenfolge.

1. Legen Sie eine Datenquelle als massgeblich fest. Exportieren Sie den aktuellen aktiven Personalbestand aus dem HR-System, dazu eine getrennte Liste aktiver Dienstleister. Ohne diese Liste ist alles Weitere Raten.
2. Exportieren Sie jedes Konto aus jeder angebundenen Anwendung. Beginnen Sie beim Identity Provider, gehen Sie dann Anwendung für Anwendung durch den SSO-Katalog. Das ist die einfache Hälfte.
3. Finden Sie die Anwendungen, die nicht im Katalog stehen. Gleichen Sie Spesenabrechnungen und Kartenumsätze ab, prüfen Sie die OAuth-Berechtigungslisten in Google Workspace und Microsoft 365, ziehen Sie DNS- oder Proxy-Logs heran und nutzen Sie Browser- oder Endgeräte-Telemetrie. Dieser Schritt macht aus 30 bekannten Anwendungen 160, und genau ihn überspringen manuelle Audits.
4. Abgleichen und einordnen. Stellen Sie jedes Konto dem Personalbestand gegenüber. Jedes nicht zuordenbare Konto fällt in eine von vier Kategorien: Austritt, Dienstleister mit beendetem Mandat, interner Wechsel mit Restberechtigungen, oder nicht-menschliche Identität ohne Eigentümer. Weisen Sie jeder nicht-menschlichen Identität einen Eigentümer zu oder markieren Sie sie zur Stilllegung.
5. Dokumentieren Sie den Befund, bevor Sie handeln. Erfassen Sie Konto, Anwendung, letzte Anmeldung und Fundtag. Dieser Datensatz ist Ihr Auditnachweis und Ihre Ausgangsbasis für die nächste Prüfung.

An Schritt 3 scheitert der manuelle Ansatz, denn man inventarisiert keine Anwendungen, von deren Existenz man nichts weiss, und die Liste ändert sich monatlich. Dies als wiederkehrende Kontrolle statt als einmaliges Projekt zu führen, entscheidet über ein sauberes Audit oder eine wiederkehrende Feststellung. Die automatisierten Access Reviews von Corma bringen Konten ohne Eigentümer planmässig ans Licht und erzeugen die Entscheidungen der Prüfenden als Nachweis, also genau das Artefakt, nach dem ein Auditor fragt.

Wie Sie die Konten schliessen, ohne etwas zu zerstören

Wer ein Konto löscht, dem eine geteilte Ablage, eine Abrechnungsbeziehung oder eine produktive Integration gehört, verursacht einen Ausfall. Arbeiten Sie in dieser Reihenfolge.

1. Zuerst die Authentifizierung deaktivieren. Konto sperren, offene Sitzungen beenden. Das stoppt das Risiko sofort und bleibt umkehrbar, falls Sie sich vertan haben.
2. Prüfen, was dem Konto gehört. Dokumente, Kalender, Repositories, Abrechnungsplätze, Integrationen und Automatisierungen. Übertragen Sie den Besitz, bevor Sie weitergehen.
3. Zugangsdaten separat widerrufen. Ein deaktiviertes Benutzerkonto beendet nicht zwingend die API-Tokens, persönlichen Zugriffstokens und OAuth-Berechtigungen, die dieses Konto erstellt hat. Widerrufen Sie sie ausdrücklich.
4. Lizenz zurückholen. Ein verwaistes Konto ist meist ein bezahlter Platz. Dieser Teil der Übung finanziert sich selbst.
5. Nach Plan löschen, nicht aus dem Impuls heraus. Wenden Sie die in Ihrer Richtlinie festgelegte Aufbewahrungsfrist an, löschen Sie danach und protokollieren Sie die Löschung.

Die Zeitersparnis je Vorgang ist real, aber überschaubar, und genau deshalb wiegt der Bestand schwerer als der Fluss. Ein E-Commerce-Unternehmen mit 30 Personen berichtet mit Corma von 20 bis 30 Prozent Zeitgewinn je Onboarding und Offboarding. Auf einen Rückstand von mehreren hundert nicht zuordenbaren Konten angewendet, macht dieses Verhältnis die Bereinigung überhaupt erst abschliessbar.

Was ISO 27001, NIS2 und die DSGVO nach dem Fund erwarten

Verwaiste Konten zu finden begründet eine Pflicht. Auditoren bewerten nicht die Entdeckung, sondern was danach geschah und ob Sie es belegen können. Die drei Rahmenwerke behandeln zwei Risiken unterschiedlich: unbefugten Zugriff durch jemanden, der ihn nicht mehr haben dürfte, und die Unfähigkeit nachzuweisen, dass der Zugriff überhaupt entzogen wurde.

Zwei Details der NIS2-Durchführungsverordnung lohnen genaues Lesen, weil kaum ein Anbieterinhalt sie aufgreift. Erstens verlangt Anhang-Punkt 11.5.1, den gesamten Lebenszyklus der Identitäten von Netz- und Informationssystemen und ihrer Benutzer zu verwalten, womit Servicekonten und Maschinenidentitäten in die Pflicht rücken statt blosse gute Praxis zu bleiben. Zweitens verlangt Anhang-Punkt 12.5, dass ein Asset, das bei Beendigung des Arbeitsverhältnisses weder zurückgegeben noch gelöscht werden kann, jedenfalls keinen Zugriff mehr auf die Systeme haben darf. Das ist eine unmittelbare Anweisung zu genau dem Restzugriff, um den es hier geht.

Eine oft übergangene Einschränkung zum Geltungsbereich: Verordnung (EU) 2024/2690 legt diese technischen Anforderungen für eine definierte Liste von Einrichtungsarten fest, darunter Cloud-Anbieter, Rechenzentrumsdienstleister, Managed-Service-Provider, Online-Marktplätze und Vertrauensdiensteanbieter. Artikel 21 Absatz 2 der Richtlinie greift weiter. In Deutschland richten sich Umsetzung und Aufsicht nach dem nationalen Recht, mit dem BSI als zuständiger Behörde, während für den Datenschutzteil die BfDI und die Landesbehörden zuständig sind. Prüfen Sie, welcher Rahmen Sie trifft, bevor Sie der Geschäftsleitung eine Absatznummer nennen.

Corma ist nach ISO/IEC 27001:2022 zertifiziert, wird jährlich von unabhängiger Stelle auditiert und hostet Kundendaten in der EU.

Die Deprovisioning-Checkliste gegen neue verwaiste Konten

Ist der Rückstand abgearbeitet, besteht die Aufgabe darin, ihn nicht neu aufzubauen. Diese Checkliste deckt das Austrittsereignis selbst ab.

• Der Austrittsdatensatz im HR-System ist der einzige Auslöser, und er startet automatisch.
• Verzeichniskonto gesperrt und alle Sitzungen beendet am letzten Arbeitstag, nicht in der Woche darauf.
• Zugriff in jeder angebundenen Anwendung entzogen, die Ausnahmeliste ohne SSO ausdrücklich behandelt statt vergessen.
• Besitz an Dokumenten, Kalendern und Repositories an eine namentlich benannte Person übertragen.
• API-Tokens, persönliche Zugriffstokens, OAuth-Berechtigungen und geteilte Zugangsdaten des Kontos widerrufen oder erneuert.
• Lizenzen zurückgeholt und die Einsparung erfasst.
• Mandats- und Vertragsenden von Dienstleistern wie Austritte behandelt, mit demselben Workflow.
• Ein Nachweis je Austritt automatisch erzeugt, damit der Beleg vorliegt, bevor jemand danach fragt.

Die vollständige Mechanik dieses Aufbaus, einschliesslich der Verdrahtung von HR-System und Identity Provider sowie der SCIM- und SAML-Grundlagen, behandelt der Corma-Leitfaden zur Automatisierung von IT-Onboarding und Offboarding. Jener Leitfaden behandelt den Fluss. Diese Seite behandelt den Bestand, und beide gehören zusammen.

Warum Corma

Corma ist eine europäische Plattform, die SaaS-Management und Identity and Access Management (IAM) in einem Produkt vereint, und genau das macht das Bestandsproblem lösbar. Die meisten IAM-Werkzeuge steuern, was ihnen bereits angebunden ist, ihr Blick auf Ihren Bestand ist also exakt so vollständig wie Ihre Integrationen. Corma findet zuerst, was nicht angebunden ist, und steuert es dann, weshalb die Compliance-Berichte den realen Bestand abbilden statt den katalogisierten.

• Discovery innerhalb und ausserhalb des SSO, über Browser und Endgerät ebenso wie über API-Konnektoren, wodurch Anwendungen sichtbar werden, die ein Verzeichnisexport nicht zeigt.
• Automatisierte Access Reviews, die Konten ohne Eigentümer und ohne Zuordnung in festem Rhythmus melden und die Entscheidungen der Prüfenden als Nachweis festhalten.
• Joiner-Mover-Leaver-Workflows ohne manuelle Schritte, gestützt auf native Konnektoren zu Google Workspace, Microsoft Entra ID, Okta und JumpCloud, sodass Corma oberhalb Ihres Identity Providers steuert, statt ihn zu ersetzen. Siehe automatisiertes User Provisioning.
• Erkennung nicht-menschlicher Identitäten und von Schatten-KI, also der OAuth-Berechtigungen, Servicekonten und Agenten, die kein Austrittsprozess erreicht.
• EU-Hosting und ISO/IEC 27001:2022, mit DSGVO- und NIS2-Bezug im Reporting statt nachträglich angebaut.

Häufige Fragen

Was ist der Unterschied zwischen Deprovisioning und dem Löschen eines Kontos?

Deprovisioning entzieht den Zugriff: es deaktiviert die Authentifizierung, widerruft Berechtigungen und beendet Sitzungen. Löschen entfernt den Kontodatensatz selbst und mit ihm die Zugriffshistorie. Deprovisioning sollte sofort erfolgen. Das Löschen gehört später, nach dokumentierter Aufbewahrungsfrist, weil der Datensatz der Nachweis ist, nach dem ein ISO-27001- oder SOC-2-Prüfer fragt.

Was bedeutet deprovisioniert?

Deprovisioniert bedeutet, dass Zugriffsrechte, Berechtigungen und Anwendungszuweisungen eines Kontos entzogen wurden, weil die Person oder das System sie nicht mehr benötigt. Auslöser sind üblicherweise ein Austritt, ein Rollenwechsel oder ein Vertragsende, und der Entzug muss jede berührte Anwendung erfassen, nicht nur das Verzeichnis.

Wie finde ich verwaiste Konten in Anwendungen ohne SSO-Anbindung?

Gleichen Sie ausserhalb des Identity Providers ab. Ziehen Sie Spesen- und Kartendaten heran, um gekaufte Tools zu finden, prüfen Sie die OAuth-Berechtigungslisten in Google Workspace und Microsoft 365, sichten Sie DNS- oder Proxy-Logs und nutzen Sie Browser- oder Endgeräte-Discovery. Vergleichen Sie dann die Benutzerliste jeder Anwendung mit Ihrem aktiven Personalbestand. Konten ohne zugehörige aktive Person sind Ihre Kandidaten.

Was tue ich, wenn der Anbieter für SSO extra verlangt?

Behandeln Sie diese Anwendungen als benannte Ausnahmeliste, statt so zu tun, als wären sie abgedeckt. Weisen Sie jeder einen Eigentümer zu, ergänzen Sie den Austritts-Workflow um einen ausdrücklichen manuellen oder automatisierten Schritt und prüfen Sie die Liste quartalsweise. Die Liste kurz und sichtbar zu halten wirkt besser, als jedes SSO-Upgrade zu bezahlen.

Wie lange darf ein verwaistes Konto offen bleiben, bevor es zur Auditfeststellung wird?

Eine allgemeingültige Karenzzeit gibt es nicht, Prüfende messen an Ihrer eigenen dokumentierten Richtlinie. Für Einrichtungen im Anwendungsbereich der Verordnung (EU) 2024/2690 sind nicht mehr benötigte Identitäten unverzüglich zu deaktivieren. In der Praxis werden privilegierte Konten am selben Tag entzogen, und ein dauerhafter Bestand nicht zuordenbarer Konten ist eine Feststellung, unabhängig vom Alter des einzelnen Kontos.

Sind Servicekonten und API-Tokens verwaiste Konten?

Sie werden dazu, sobald sie niemandem gehören, was häufig vorkommt, weil ihnen ein Austrittsdatum als Prüfauslöser fehlt. Verordnung (EU) 2024/2690 erfasst ausdrücklich den Lebenszyklus der Identitäten von Netz- und Informationssystemen ebenso wie den ihrer Benutzer, sie gehören also zur Governance und sind kein Zusatz.