Ein Badge, zwei Jahre inaktiv – und trotzdem funktioniert er
Das Red Team betritt das Gebäude nicht durch den Haupteingang. Es betritt es mit dem Badge von Thomas K. – einem Mitarbeiter, der das Unternehmen vor 26 Monaten verlassen hat. Der Badge wurde nie deaktiviert. Der AD-Account nie gesperrt. Die VPN-Credentials nie entzogen. Das Postfach läuft noch. Und die Zugangsberechtigung zum Serverraum, die Thomas damals für ein Projekt bekommen hatte, existiert ebenfalls noch – still, unbemerkt, vollständig gültig.
Das ist kein konstruiertes Szenario. Es ist ein zusammengefasstes Muster aus Dutzenden realen Engagements. In fast jedem Unternehmen, das wir auditieren, finden wir aktive Credentials von Personen, die längst nicht mehr Teil der Organisation sind: ausgeschiedene Mitarbeiter, abgeschlossene Praktika, beendete Dienstleisterverträge, abgewickelte Projekte. Die Accounts existieren weiter – weil Offboarding in den meisten Unternehmen kein Prozess ist, sondern eine Hoffnung.
Verwaiste Zugänge sind die am häufigsten übersehene Schwachstelle in der Sicherheitsarchitektur von Unternehmen. Sie erfordern keinen Exploit, keine Social-Engineering-Kompetenz und keine technische Expertise. Sie erfordern nur das Wissen, dass sie existieren – und die Credentials dazu.
Warum Offboarding systematisch scheitert
Offboarding klingt nach einem HR-Thema. In der Praxis ist es ein Schnittstellenproblem – und Schnittstellenprobleme scheitern immer dann, wenn keine eindeutige Ownership definiert ist. Wenn ein Mitarbeiter das Unternehmen verlässt, sind je nach Unternehmensgröße zwischen fünf und fünfzehn verschiedene Systeme betroffen. Jedes hat einen anderen Verantwortlichen, eine andere Schnittstelle und einen anderen Prozessrhythmus.
- Austrittsvertrag
- Lohnabrechnung
- Arbeitszeugnisse
- HRIS-Eintrag deaktivieren
- Schlüsselrückgabe (physisch)
AD-Account-Sperrung
Cloud-SSO-Entzug
VPN-Credentials
SaaS-Zugänge
Shared Secrets
API-Keys
Git-Zugang
- Laptop einziehen
- E-Mail weiterleiten
- Gerät remote wipe
- – wenn Ticket kommt –
- – wenn jemand fragt –
Das Leck liegt in der Mitte. HR schließt den arbeitsrechtlichen Vorgang ab und gibt das Gerät zurück. IT wartet auf ein Ticket. Wer erstellt das Ticket? Oft niemand. Oder jemand – aber zu spät, unvollständig, ohne alle Systeme zu kennen. Besonders gefährlich: Systeme, die niemand aktiv im Kopf hat. Der VPN-Zugang, der für ein Projekt eingerichtet wurde. Der AWS-IAM-User mit Admin-Rechten, den der Entwickler selbst angelegt hat. Der Badge-Zugang zum Serverraum, der für eine temporäre Aufgabe erweitert wurde und danach einfach liegen geblieben ist.
Das gefährlichste verwaiste Konto ist nicht das, das man vergessen hat. Es ist das, von dem nur eine Person wusste – und die hat gerade das Unternehmen verlassen.
Die vollständige Angriffsfläche: Wo verwaiste Zugänge lauern
Verwaiste Zugänge sind kein Badge-Problem. Sie sind ein systemisches Problem, das sich durch alle Schichten der Unternehmensinfrastruktur zieht – von der Eingangstür bis zur Produktionsdatenbank. Jede Ebene hat eigene Risiken, eigene Verwaltungssysteme und eigene blinde Flecken.
Die vollständige Angriffskette: Vom Phantom-Badge zum Produktionssystem
In realen Engagements führen verwaiste Zugänge selten zu einem einzelnen, isolierten Zugriff. Sie sind der Startpunkt einer Kette – weil jede aktive Identität weitere Türen öffnet.
# Accounts die seit >90 Tagen nicht genutzt wurden
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter * -Properties LastLogonDate, Enabled |
Where-Object { $_.Enabled -eq $true -and $_.LastLogonDate -lt $cutoff } |
Select-Object Name, SamAccountName, LastLogonDate |
Sort-Object LastLogonDate
→ Jeder Treffer ist ein potenzieller Phantom-Account
Warum verwaiste Zugänge ein Compliance-Problem sind – nicht nur ein Security-Problem
Identity Lifecycle Management ist keine Best Practice. Für eine wachsende Zahl von Unternehmen ist es eine rechtlich bindende Pflicht. Die relevanten Regelwerke adressieren das Thema explizit – mit unterschiedlichem Fokus, aber gemeinsamer Konsequenz: Wer verwaiste Accounts nicht managt, verstößt gegen nachweisbare Anforderungen.
| Regelwerk | Anforderung | Relevanz für Offboarding | Status |
|---|---|---|---|
| NIS2 | Zugriffskontrolle und Identitätsmanagement als explizite Sicherheitsmaßnahme (Art. 21) | Verwaiste Accounts sind ein direkter Verstoß gegen das Mindestsicherheitsniveau | Pflicht |
| ISO 27001 | A.9.2.6: Entzug von Zugriffsrechten bei Beendigung des Arbeitsverhältnisses | Explizite Kontrollanforderung – auditierbar und zertifizierungsrelevant | Pflicht |
| DSGVO | Datenzugang auf das notwendige Minimum beschränken (Datensparsamkeit, Art. 5) | Aktive Zugänge ausgeschiedener Personen auf personenbezogene Daten sind ein DSGVO-Verstoß | Pflicht |
| SOC 2 | CC6.2: Logical access provisioning und deprovisioning | Fehlende Deprovisioning-Nachweise führen zu Audit-Findings und gefährden das Zertifikat | Auditrelevant |
| CER-Richtlinie | Physische und logische Zugangskontrolle für kritische Einrichtungen | Verwaiste physische Badges in kritischer Infrastruktur sind ein direkter Compliance-Verstoß | Pflicht |
Identity Lifecycle Management: Was ein funktionierender Offboarding-Prozess leisten muss
Das Ziel ist nicht ein besseres Offboarding-Checklisten-Dokument. Das Ziel ist ein automatisierter, systemübergreifender Deprovisioning-Prozess, der keine manuelle Intervention erfordert – und der nachweisbar dokumentiert, was wann entzogen wurde.
- HR-System als Single Source of Truth: Der Austritt eines Mitarbeiters muss im HRIS erfasst werden und automatisch einen Deprovisioning-Workflow triggern. Kein Ticket, kein manueller Schritt – der Prozess startet selbst. Tools wie Workday, BambooHR oder SAP SuccessFactors bieten entsprechende Integrationen.
- Identity Provider als zentraler Hebel: Alle Systeme müssen über einen einzigen IdP (Entra ID, Okta, JumpCloud) provisioniert sein. Eine einzige Deaktivierung im IdP entzieht alle nachgelagerten Zugänge gleichzeitig – AD, SSO-Apps, VPN mit AD-Auth. Was nicht über SSO läuft, ist ein Risiko.
- ZKS-Integration in den Offboarding-Workflow: Badge-Deaktivierung darf nicht von einem separaten IT-Ticket abhängen. Das Zutrittskontrollsystem muss direkt oder über den IdP in den Offboarding-Workflow integriert sein. Bei Offline-Schlössern: maximale Sync-Intervalle definieren und überwachen.
- API-Key- und Service-Account-Inventar führen: Jeder technische Credential muss einem Eigentümer zugeordnet sein – und dieser Eigentümer muss im Offboarding-Prozess adressiert werden. Tools wie HashiCorp Vault, AWS Secrets Manager oder GitHub Enterprise ermöglichen Owner-basiertes Credential-Management.
- SaaS-Discovery für Schatten-IT: Tools wie Nudge Security, Grip Security oder BetterCloud scannen OAuth-Grants und SaaS-Zugänge und machen sichtbar, auf welche Dienste ein Mitarbeiter Zugriff hatte. Ohne diesen Überblick ist vollständiges Offboarding nicht möglich.
- Regelmäßige Access Reviews: Offboarding schließt keine Lücken, die durch temporäre Zugangserweiterungen entstanden sind. Quartalsweise Access Reviews aller privilegierten Accounts – AD, Cloud IAM, ZKS – decken Accounts auf, die nie offiziell deaktiviert wurden. Der PowerShell-Query oben ist ein guter Startpunkt.
- Monitoring für inaktive Account-Nutzung: Jede Authentifizierung mit einem Account, der seit mehr als 30 Tagen nicht genutzt wurde, sollte einen Alert auslösen. In SIEM-Systemen (Splunk, Microsoft Sentinel, Elastic) ist das eine einfache Correlation Rule – und eine der wirkungsvollsten überhaupt.
- Physical Pentest mit Phantom-Badge-Test: Ein strukturiertes Audit, das gezielt versucht, mit Credentials ausgeschiedener Mitarbeiter Zugang zu erlangen, liefert den empirischen Nachweis über den tatsächlichen Zustand des Offboarding-Prozesses. Wir führen diesen Test als Teil jedes Physical-Security-Engagements durch.
Ein vollständiger Offboarding-Prozess entzieht innerhalb von maximal 24 Stunden nach Vertragsende alle Zugänge – physisch und digital – und dokumentiert jeden Entzug nachweisbar. Alles, was länger dauert oder manuell ist, ist eine Lücke.
Fazit: Der gefährlichste Angreifer ist der, den du längst entlassen hast
Thomas K. hat das Unternehmen vor 26 Monaten verlassen. Er hat keine bösen Absichten, er ist nicht der Angreifer. Aber sein Badge, sein AD-Account und sein API-Key existieren noch – und ein Angreifer, der diese Credentials kennt oder findet, ist Thomas K. für alle betroffenen Systeme.
Verwaiste Zugänge sind kein Randthema und kein Nischenproblem. Sie sind die wahrscheinlichste Quelle eines erfolgreichen Zugriffs in fast jedem Unternehmen, das keinen automatisierten Identity-Lifecycle-Prozess betreibt. Sie sind leise, persistent und vollständig vermeidbar.
Die Frage ist nicht: „Haben wir verwaiste Accounts?" Die Frage ist: „Wie viele – und wer weiß es außer uns nicht?"
Wie viele aktive Zugänge hat dein Unternehmen von Personen, die längst weg sind?
Wir testen Phantom-Badges, verwaiste AD-Accounts und vergessene API-Keys – und liefern eine vollständige Aufstellung deiner Identity-Lifecycle-Lücken.
Identity & Access Audit anfragen →