Governance-Schulden

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.

Warum ein inaktives Konto alles andere als harmlos ist

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:

• Mitgliedschaften in Gruppen bestehen weiterhin
• Zugriffe auf SharePoint, Teams oder Mailboxen sind noch vorhanden
• Lizenzen laufen weiter
• eine Reaktivierung wäre jederzeit möglich

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.

Warum sich Inaktivität unbemerkt aufstaut

Dormante Accounts entstehen selten aus Nachlässigkeit. Meist sind sie das Resultat ganz normaler organisatorischer Reibung.

Typische Ursachen sind:

• HR und IT sind im Austrittsprozess nicht sauber verbunden
• Offboarding hängt an Tickets und manuellem Nachfassen
• Rollenwechsel werden in Berechtigungen nicht konsequent nachgeführt
• Externe erhalten Zugriff ohne klares Ablaufdatum
• Service Accounts werden für einen akuten Bedarf erstellt und danach nie mehr sauber überprüft

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.

Die gefährliche Illusion der Harmlosigkeit

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.

Das eigentliche Problem: Niemand fühlt sich zuständig.

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:

• Wird diese Identität noch gebraucht?
• Sind die aktuellen Berechtigungen noch angemessen?
• Wer ist für den weiteren Lebenszyklus verantwortlich?

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

Die Compliance-Perspektive im Ernstfall

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:

• warum der Account noch existierte
• warum die Berechtigungen noch aktiv waren
• wer für die Überprüfung verantwortlich gewesen wäre
  

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

Service Accounts: die besonders unbequeme Kategorie

Servicekonten sind der Punkt, an dem sich das Problem weiter verschärft. Sie haben häufig:

• Erhöhte Berechtigungen
• Keinen dokumentierten Verantwortlichen
• Kein Ablaufdatum
• Zugangsdaten, die seit Jahren nicht rotiert wurden

   

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.

Dieser Punkt knüpft direkt an Identity Blog 4 an, der sich mit der Governance privilegierter Zugriffe befasst. Viele Servicekonten verfügen über Berechtigungen, die als privilegiert gelten, wodurch ihr Lifecycle-Management zu einer Sicherheitsfrage wird – und nicht nur zu einer Frage der Ordnung.

Von der Bereinigung zur Lifecycle-Disziplin

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:

• definierte Trigger im Offboarding
• klare Verantwortlichkeit pro Identität
• regelmässiger Reviews inaktiver Accounts
• Ablaufdaten für externe Zugriffe
• dokumentierte Ownership für Service-Accounts

Das ist langfristig kein Aufwand mehr. Es ist vor allem weniger wiederholte Feuerwehrarbeit

Ein einfacher Praxistes 

Drei Fragen genügen:

1. Können Sie innerhalb weniger Minuten eine Liste aller inaktiven Konten (>90–180 Tage) erstellen?
2. Gibt es für jedes Konto einen klar benannten Verantwortlichen?
3. Existiert ein definierter, regelmäßiger Prozess zur Überprüfung und Deaktivierung?

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.