Service Accounts hat es schon immer gegeben.

Ein Beispiel: In jedem Active Directory existieren etliche. Ein Systemadministrator hat sie einst angelegt, damit ein Dienst auf eine Datenbank zugreifen kann. Der Sysadmin ist längst weg, der Account läuft noch.

Dann kamen Cloud, APIs, Microservices und CI/CD-Pipelines und aus wenigen Service Accounts wurden schnell sehr viele. Genau da fängt die Geschichte von Non-Human Identities (NHIs) an.

 

Was sich verändert hat und warum das Volumen das Problem ist

Früher war ein Service Account ein konkretes Ding: ein Windows-Konto im Active Directory, das einen Dienst ausführt. Jemand hat es angelegt, irgendwo dokumentiert (vielleicht in einer Excel-Tabelle?) und gehofft, dass es nie Probleme macht. Das hat funktioniert, weil die Zahlen überschaubar waren. Eine Organisation mit 500 Mitarbeitern hatte vielleicht 50 Service Accounts. Jemand kannte sie alle, zumindest ungefähr.

Heute sieht das anders aus. Laut Entro Security übersteigen nicht-menschliche Identitäten die menschlichen in vielen Enterprise-Umgebungen deutlich, teils um ein Vielfaches, und wachsen weiterhin stark (H1 2025).

Die neue Realität: 500 Mitarbeiter, aber zehntausende NHIs.

Keine Excel-Tabelle der Welt ist dafür gebaut und kein Sysadmin kann das manuell überblicken. Viele klassische IAM-Prozesse (Identity and Access Management) wurden für menschliche Lebenszyklen konzipiert und stoßen bei diesem rasant steigenden NHI-Volumen schnell an ihre Grenzen.

 

Wie es dazu gekommen ist: Eine kurze Geschichte

Active Directory wurde um das Jahr 2000 eingeführt. Das zugrunde liegende Identity-Modell war damals stark auf menschliche Benutzer ausgelegt: Gruppen, Passwörter und Anmelderichtlinien orientierten sich primär daran, dass sich Menschen an Unternehmenssystemen anmelden.

Service Accounts wurden in vielen Unternehmen pragmatisch umgesetzt. Wenn ein Dienst ohne menschliche Interaktion auf andere Systeme oder Datenbanken zugreifen musste, nutzten Administratoren häufig normale Benutzerkonten aus dem Active Directory. Sie vergaben technische Namen und aktivierten oft „Passwort läuft nie ab“, damit der Betrieb nicht plötzlich wegen eines abgelaufenen Kennworts stillstand.

Microsoft hat später zwar Managed Service Accounts (MSAs) und Group Managed Service Accounts (gMSAs) eingeführt, technisch deutlich besser und mit automatischer Passwort-Rotation –, doch die Adoption blieb begrenzt. In den meisten Umgebungen stehen noch heute hunderte klassischer Domain-Accounts, die kritische Dienste betreiben und seit Jahren keinen Passwort-Reset gesehen haben.

Mit dem Wandel der IT-Architektur explodierten die Zahlen:

• Cloud-Dienste brachten SaaS-Modelle.
• Microservices machten aus einer monolithischen Applikation plötzlich zehn eigenständige Dienste.
• DevOps führte zu CI/CD-Pipelines, die vollautomatisiert neue Identitäten erzeugen.

Jeder API-Call, jede Integration und jedes Skript benötigt Credentials. Mit der zunehmenden Nutzung von KI-Agenten in Unternehmen wächst die Zahl nicht-menschlicher Identitäten nun noch weiter. Anders als klassische Automatisierungen führen agentische KI-Systeme Aufgaben nicht nur starr aus, sondern treffen innerhalb definierter Grenzen eigenständig Entscheidungen darüber, welche Systeme, APIs oder Datenquellen sie nutzen.

KuppingerCole beschreibt NHIs als Identitäten für Maschinen, Workloads, Service Accounts und AI Agents. Die Advisory Note ordnet ein, dass Automatisierung, cloud-native Architekturen und autonome AI Agents die Anzahl und Komplexität nicht-menschlicher Identitäten erhöhen.

Gleichzeitig zeigt eine Studie der Cloud Security Alliance (CSA) aus dem Jahr 2026, dass ein relevanter Teil der Unternehmen neue KI-bezogene Identitäten bislang nicht systematisch erfasst oder überwacht. Mehr als 16 % der befragten Organisationen gaben an, KI-bezogene Identitäten nicht ausreichend zu erfassen. Dadurch entstehen zusätzliche blinde Flecken in Governance-, IAM- und Secrets-Management-Prozessen.

 

Das eigentliche Problem: Sie sind gar nicht erst angebunden

Hier liegt ein entscheidender Punkt, den viele unterschätzen. Die Diskussion über NHI-Sicherheit dreht sich meistens um schlechte Governance: Accounts werden nicht rotiert, Rechte nicht entzogen, das Offboarding wird vergessen. Das stimmt alles. Aber darunter liegt ein noch grundlegenderes Problem:

 

Ein erheblicher Teil der NHIs ist in keinem IAM-System angebunden und somit für das Unternehmen schlicht „unsichtbar“.

• Ein Service Account wird von einem Entwickler angelegt, um einen Test-Workflow anzubinden. Der Test wird produktiv, der Account bleibt. Im OIM, im IGA-Tool oder im PAM taucht er nie auf. Er existiert in einem blinden Fleck.
• Das gilt ebenso für API-Keys, die direkt in Anwendungen hardcoded sind.
• Für OAuth-Token, die ein SaaS-Tool bei der Integration automatisch erzeugt hat.
• Für CI/CD-Credentials, die in Pipeline-Konfigurationen leben und nie in einen Secrets Manager überführt wurden.

Was nicht angebunden ist, kann nicht verwaltet (governed) werden. Was nicht verwaltet werden kann, wird nicht rotiert. Und was nicht rotiert wird, bleibt aktiv, manchmal für Jahre, manchmal über ein Jahrzehnt. Laut OWASP existieren häufig Secrets ohne sinnvolle Ablaufzeiten, weil sie schlicht nie überprüft werden. Das ist der Ausgangspunkt für etliche NHI-Angriffe: Eine Identität, die dem IAM-System völlig unbekannt war.

 

Was das konkret bedeutet: Reale Vorfälle

• Der GitHub-Action-Vorfall (März 2025): Angreifer kompromittierten die weit verbreitete GitHub Action tj-actions/changed-files (CVE-2025-30066). Dadurch konnten sensible CI/CD-Secrets aus tausenden Repositories abgegriffen werden. Betroffen waren laut Sicherheitsanalysen mehr als 23.000 Projekte. Der Vorfall zeigte, wie kritisch nicht-menschliche Identitäten und Tokens in modernen Entwicklungsumgebungen geworden sind: Ein einziger kompromittierter Access Token innerhalb einer automatisierten CI/CD-Kette reichte aus, um weitreichenden Zugriff auf Build- und Deployment-Prozesse zu erhalten.
• Der Fall Tata Motors (2025 öffentlich bekannt geworden): Im Oktober 2025 veröffentlichte ein Sicherheitsforscher eine Analyse zu Tata Motors: Hardcodierte Credentials in mehreren öffentlichen Anwendungen ermöglichten potenziellen Zugriff auf über 70 TB Daten, darunter Kundendaten, Rechnungen und interne Reports. Die Schwachstellen lagen seit 2023 vor. Der Fall verdeutlicht ein typisches Problem moderner NHI-Sicherheit: langlebige Credentials, die unbemerkt in Anwendungen, Skripten oder Integrationen verbleiben.

Genau dieses Muster taucht in etlichen aktuellen Sicherheitsvorfällen rund um Maschinenidentitäten auf: gültige Credentials, fehlende Transparenz und Identitäten, die nie sauber inventarisiert oder kontrolliert wurden. Der „2026 NHI Reality Report“ beschreibt diese Kombination aus fehlender Sichtbarkeit, überprivilegierten Zugriffen und mangelnder Rotation inzwischen als eines der zentralen Risiken moderner Cloud- und Automatisierungsumgebungen.

 

Warum klassisches IAM hier nicht greift

Traditionelle IAM-Systeme wurden um menschliche Verhaltensmuster herum entwickelt: Onboarding über das HR-System, Rollenänderung beim Abteilungswechsel, Offboarding beim Austritt. Dazu kommen Arbeitszeiten, Standorte und vorhersehbares Verhalten als Baseline für die Anomalieerkennung.

NHIs folgen keinem dieser Muster. Sie laufen rund um die Uhr (24/7). Sie tauchen in keiner HR-Datenbank auf. Sie haben keinen Vorgesetzten, der ihre Zugriffsrechte im jährlichen Review bestätigt. Das Ergebnis zeigt sich in drei konsistenten Lücken:

1. Fehlende Ownership: Viele Organisationen tracken die Erstellung neuer KI-bezogener Identitäten überhaupt nicht (Cloud Security Alliance, 2026). Was nicht erfasst wird, wird nicht verantwortet. Was nicht verantwortet wird, wird nicht gepflegt.
2. Standardmäßige Überprivilegierung: Ein Großteil aller NHIs besitzt weit mehr Rechte, als sie für ihre eigentliche Funktion benötigen. Das ist ein massives Governance-Problem, denn getreu dem Motto „Wer keine klare Richtlinie hat, vergibt im Zweifel lieber zu viel Rechte“ werden technische Accounts oft pauschal mit Admin-Rechten ausgestattet.
3. Kein Offboarding: Ein Microservice wird abgeschaltet, sein API-Key bleibt aktiv. Ein Entwickler verlässt das Unternehmen, sein persönlicher Access Token läuft weiter. Laut OWASP stellt ein unsachgemäßes Offboarding eines der größten NHI-Risiken dar.

 

„Viele Unternehmen behandeln Service Accounts wie ein Hotel, in dem an der Rezeption einfach alle Zimmerkarten offen ausliegen.
Man nimmt sich irgendeine, die funktioniert, und hofft, dass nichts passiert.“

 

Was Unternehmen jetzt konkret tun können

• Bestandsaufnahme zuerst: Was nicht bekannt ist, kann nicht geschützt werden. Der erste Schritt ist immer die umfassende Inventarisierung: Welche NHIs existieren überhaupt im Active Directory, in der Cloud, in SaaS-Integrationen und in den CI/CD-Pipelines?
• Ownership definieren: Jede NHI braucht einen menschlichen Verantwortlichen. Eine konkrete Person oder Rolle, die für die Rotation, Berechtigungsreviews und die schlussendliche Dekommissionierung zuständig ist.
• Least Privilege durchsetzen: Jede Identität darf strikt nur die Rechte erhalten, die sie für ihre spezifische Aufgabe zwingend benötigt.
• Lifecycle automatisieren: Die automatische Erkennung neuer NHIs, die regelmäßige automatisierte Rotation von Secrets sowie das automatische Offboarding beim Abschalten eines Services müssen zum Standard werden.

Mehr Informationen finden Sie auch auf unserer Service-Seite zum Thema NHI-Management.

 

Wir bieten zwei Einstiegspunkte an, je nachdem, wie weit Sie bereits sind.

NHI-Assessment
Wir analysieren Ihre Umgebung strukturiert: Welche nicht-menschlichen Identitäten existieren in Active Directory, Cloud, SaaS-Integrationen und CI/CD Pipelines? Wer ist verantwortlich? Wo liegen die kritischen Lücken?

Ergebnis: ein klares Bild Ihres NHI-Bestands mit priorisierten Handlungsempfehlungen.

NHI-Workshop
Gemeinsam schauen wir, was in Ihrer Umgebung bereits vorhanden ist, wo Governance fehlt und welche nächsten Schritte realistisch sind. Kein Vorwissen nötig: Wir holen Sie dort ab, wo Sie gerade stehen.

Ergebnis: Klarheit über Ihre aktuelle Situation und einen konkreten Fahrplan für Ihr Unternehmen.

Erstgespräch anfragen →