Dormante Accounts sind kein IT-Hygienethema. Sie sind Governance-Schulden. Und anders als viele technische Altlasten bleiben sie nicht einfach irgendwo im Hintergrund liegen. Sie wachsen still mit, bis sie im denkbar ungünstigsten Moment sichtbar werden: im Audit, nach einem Sicherheitsvorfall oder in einer Managementrunde, in der plötzlich niemand eine saubere Antwort geben kann.
Im ersten Blog haben wir aufgezeigt, dass Identity Entropy kein Ausnahmefall ist, sondern ein strukturelles Problem. IT-Umgebungen verändern sich laufend. Governance hält selten im gleichen Tempo mit. Dormante Accounts sind eines der klarsten Symptome dieser Lücke und zugleich eines der Themen, die in vielen Unternehmen am leichtesten übersehen werden.
In jedem seit einigen Jahren bestehenden Tenant gibt es sie: ehemalige Mitarbeitende, deren Konten nie sauber entfernt wurden. Externe Partner mit Zugang, obwohl das Projekt längst beendet ist. Alte Projekt- oder Migrationskonten, die niemand mehr aktiv anschaut. Fast alle wissen, dass diese Konten existieren. Nur die Wenigsten behandeln sie als das, was sie sind: ein Governance-Problem.
Ein dormanter Account ist nicht einfach ein Benutzerkonto, das sich seit längerer Zeit nicht mehr angemeldet hat. Es ist eine Identität, die im Tenant weiterhin vorhanden ist, oft weiterhin Berechtigungen hat und in vielen Fällen noch immer Zugriff auf Daten oder Systeme hat. Das kann heissen:
Der entscheidende Punkt ist aber ein anderer: Oft gibt es keinen klaren Owner.
Und genau das macht dormante Accounts heikel. Ein Account ohne klare Verantwortung ist nicht einfach inaktiv. Er ist unverwaltet. Wenn niemand verbindlich bestätigen kann, ob dieser Account noch benötigt wird, welche Berechtigungen er noch haben darf und wer für seinen Lebenszyklus zuständig ist, dann gibt es in der eigenen Kontrollumgebung einen blinden Fleck.
Kein KMU würde so mit Finanzen, Verträgen oder produktionskritischen Systemen umgehen. Bei digitalen Identitäten passiert es trotzdem dauernd.
Dormante Accounts entstehen selten aus Nachlässigkeit. Meist sind sie das Resultat ganz normaler organisatorischer Reibung.
Typische Ursachen sind:
Jeder einzelne Schritt ist für sich betrachtet nachvollziehbar. In der Summe führt er jedoch zu Drift.
Wenn Offboarding in 90 Prozent der Fälle funktioniert, verschwinden die verbleibenden 10 Prozent nicht einfach so. Sie bleiben. Und mit jedem Monat wird aus einzelnen Fällen ein Bestand, den niemand mehr wirklich aktiv im Blick hat, der aber weiterhin Teil der Umgebung bleibt.
Dormante Accounts wirken oft harmlos, gerade weil bisher nichts passiert ist. Sie sind deaktiviert. Niemand meldet sich mehr an. Bisher wurde kein Vorfall direkt mit ihnen in Verbindung gebracht. Also bleiben sie bestehen. Genau darin liegt die Selbsttäuschung.
Denn auch ein deaktivierter Account hinterlässt einen Access Footprint: Gruppenmitgliedschaften, Berechtigungen und möglicherweise Datenzugriff. Solange diese Dinge nicht explizit entfernt werden, bleibt der Account Teil der Risikofläche.
Die eigentliche Frage ist deshalb nicht, ob ein einzelner dormanter Account für sich allein kritisch ist. Die Frage ist, ob eine wachsende Zahl unverwalteter Identitäten zu einer kontrollierten, auditierbaren IT-Umgebung passt.
Die Antwort ist klar: Nein.
Die entscheidende Frage für einen CIO ist erstaunlich simpel: Wem gehört jede Identität im Tenant? Nicht technisch, aber operativ.
Für jeden User Account, jeden Service Account, jede Shared Mailbox und jeden externen Zugang sollte jemand drei Fragen beantworten können:
In vielen KMU lautet die implizite Antwort: IT ist zuständig. In der Praxis bedeutet das oft: Niemand ist wirklich zuständig.
IT kann Konten verwalten. IT kann aber nicht für den Fachbereich entscheiden, ob ein Account geschäftlich noch nötig ist. Ein Benutzer im Finanzsystem muss von Finance validiert werden, nicht vom Helpdesk. Ein externer Partner benötigt einen internen Sponsor, der den weiteren Zugriff gewährt. Ein Service-Account braucht einen fachlichen Owner, der bestätigt, dass der Account noch benötigt wird.
Wenn operative Verantwortung in der IT hängen bleibt, wird das Lifecycle Management informell. Und informelle Kontrolle wird mit der Zeit immer schlechter
Stell dir die Situation nach einem Sicherheitsvorfall vor. Es gab Zugriff auf sensible Daten. Im Review zeigt sich, dass ein Account genutzt wurde, der seit Monaten nicht mehr aktiv ist. Er gehörte zu einem externen Dienstleister, dessen Zugang nie vollständig entfernt wurde.
Ab diesem Moment musst du erklären:
Und die ehrliche Antwort lautet: niemand. Spätestens dann ist das Thema nicht mehr theoretisch.
Gerade im Schweizer Umfeld reicht es nicht, Richtlinien auf Papier zu haben. Wer über Identity und Access Management spricht, muss im Ernstfall auch nachweisen können, dass Ownership, Überprüfung und Lifecycle sauber geregelt sind. Eine Liste von dormant gewordenen Accounts ohne klare Verantwortung sieht in so einem Moment nicht nur unschön aus. Sie sieht nach fehlender Kontrolle aus
Servicekonten sind der Punkt, an dem sich das Problem weiter verschärft. Sie haben häufig:
Sie werden meist erstellt, um kurzfristig ein Problem zu lösen. Danach bleiben sie bestehen. Mit der Zeit wird ihr Zweck unklar, der Verantwortliche verschwindet – der Zugriff jedoch bleibt.
Aus Governance-Sicht sind sie schwieriger zu bewerten als Benutzerkonten und oft weniger sichtbar. Es handelt sich dabei nicht um ein separates Problem, sondern um dieselbe Lifecycle-Problematik – nur mit deutlich höherem Risiko.
Viele Unternehmen behandeln inaktive Accounts als Aufräumthema. Man kümmert sich darum, wenn ein Audit ansteht. Oder wenn die Lizenzkosten auffallen. Oder wenn jemand feststellt, dass die Liste inzwischen unangenehm lang geworden ist.
Das Problem dabei: Genau so stellt man sicher, dass es wieder passiert. Der Unterschied ist simpel:
Cleanup ist reaktiv, punktuell und anlassgetrieben
Lifecycle-Disziplin ist eingebaut, wiederkehrend und klar verantwortet
Lifecycle-Disziplin bedeutet konkret:
Das ist langfristig kein Aufwand mehr. Es ist vor allem weniger wiederholte Feuerwehrarbeit
Drei Fragen genügen:
Wenn Sie eine dieser Fragen nicht eindeutig beantworten können, besteht bereits Governance-Schuld.
Inaktive Konten sind nur ein sichtbarer Ausdruck der übergeordneten Drift aus der Identity Blog 1-Identitätsentropie. Ihr Vorhandensein ist kein Fehler, sondern die logische Folge organisatorischer Veränderungen ohne strukturiertes Lifecycle-Management. Die Frage ist nicht, ob sie in Ihrem Tenant existieren – sondern wie viele.
In Identity Blog 3, wenn Rollen und Realität auseinanderdriften, gehen wir einen Schritt weiter: zu einem weniger sichtbaren, aber ebenso kritischen Muster – Role Drift und der Security Capability Gap. Also die schleichende Entkopplung zwischen Lizenzzuweisung und tatsächlicher Rolle – und die daraus resultierenden Kontrolllücken.