Ihr Identity-Programm verwaltet Tausende menschlicher Konten. Die Hunderttausenden nicht-menschlichen Identitäten, die daneben existieren, werden mit hoher Wahrscheinlichkeit nicht erfasst - und Angreifer haben das längst bemerkt.
Das durchschnittliche Unternehmen betreibt laut [1] über 250.000 nicht-menschliche Identitäten (NHIs) in seinen Cloud-Umgebungen. Forschungsergebnisse von Rubrik Zero Labs beziffern das Verhältnis von NHIs zu menschlichen Identitäten im modernen Unternehmen auf 45:1; für Cloud-native und DevOps-Umgebungen gibt [2] diesen Wert mit 144:1 an. Ein DAX-Konzern kann problemlos die Marke von 500.000 Machine-Identities überschreiten. Jede einzelne davon authentifiziert sich kontinuierlich, greift auf sensible Systeme zu und verfügt über Berechtigungen, die bei einem menschlichen Konto sofort eine Überprüfung auslösen würden.
Die Governance-Programme, die für die Verwaltung menschlicher Konten entwickelt wurden, waren für dieses Szenario nie gedacht.
Was "nicht-menschliche Identität" wirklich bedeutet
Der Begriff umfasst eine breite und wachsende Taxonomie. Nicht-menschliche Identitäten schließen Service-Accounts, API-Keys, OAuth-Tokens, SSH-Keys, RPA-Bots, Cloud-Workload-Credentials und KI-Agenten ein - die am schnellsten wachsende und am wenigsten regulierte Angriffsfläche im modernen Unternehmen.
In der Praxis lassen sich NHIs in einige operative Kategorien einteilen:
- Service-Accounts - langlebige Credentials, die für Anwendungen, Skripte und geplante Jobs erstellt werden. Häufig mit weitreichenden Berechtigungen ausgestattet, "um Reibungsverluste zu vermeiden", und selten überprüft.
- API-Keys - statische Secrets, die in Code, CI/CD-Pipelines und Konfigurationsdateien eingebettet sind. Werden regelmäßig in Repositories eingecheckt und dann vergessen.
- OAuth-Tokens - delegierte Zugriffsberechtigungen, die ausgestellt werden, wenn ein Nutzer oder Administrator eine SaaS-App mit einer anderen verbindet. Refresh-Tokens können nach der ursprünglichen Autorisierung unbegrenzt weiter gültig bleiben.
- KI-Agenten - die neueste und am schnellsten wachsende Kategorie. Anders als statische Service-Accounts kann ein KI-Agent mit delegiertem Zugriff seinen Scope dynamisch erweitern - auf eine Weise, die kein Policy-Dokument vorhergesehen hat. Der Blast-Radius ist erheblich größer, der Audit-Trail erheblich dünner.
Was sie alle verbindet: kein HR-Datensatz, kein MFA, kein Passwort-Reset-Zyklus - und niemand, dessen Aufgabe es wäre zu bemerken, wenn sie veralten.
Warum NHIs strukturell der Governance entgehen
Die meisten Identity-Governance-Programme basieren auf einer einfachen Annahme: Identitäten repräsentieren Menschen. IGA-Plattformen wurden um die Idee herum entwickelt, dass menschliche Identitäten klare autoritative Quellen, relativ stabile Attribute und vorhersehbare Joiner-Mover-Leaver-Ereignisse haben. Nicht-menschliche Identitäten verletzen nahezu alle diese Annahmen. Sie können ad hoc von beliebigen Fachbereichen erstellt, in Cloud-Plattformen initiiert oder von Automatisierungstools generiert werden.
Die JML-Automatisierung, die für Mitarbeitende gut funktioniert - HRIS-Ereignis wird ausgelöst, SSO-Konto wird provisioniert, SCIM überträgt die Daten nachgelagert - hat schlicht keinen Trigger für einen Service-Account, den ein Entwickler letzten Dienstag angelegt hat. Anders als menschliche Mitarbeitende, die einen an HR gebundenen Joiner-Mover-Leaver-Prozess durchlaufen, werden NHIs oft ad hoc von Entwicklern erstellt. Es gibt keinen Einstellungsdatensatz. Kein Kündigungsereignis. Keinen Offboarding-Workflow. Das Konto existiert einfach weiter, sammelt Zugriffe an - bis etwas schiefgeht.
SSO schließt diese Lücke ebenfalls nicht. SSO regelt den Login für menschliche Nutzer. Es hat keine Sichtbarkeit auf die OAuth-Berechtigungen, die diese Nutzer autorisieren, die API-Keys, die ihre Anwendungen generieren, oder die Service-Accounts, die ihre CI/CD-Pipelines erstellen. Menschliche Identitäten über SSO zu verwalten und NHIs dabei unkontrolliert zu lassen, ist wie die Haustür abzuschließen und den Serverraum offen zu lassen.
SSO ist keine Governance. SSO steuert, wie sich Menschen anmelden. Es hat keine Einsicht in OAuth-Token, API-Schlüssel oder Service-Accounts, die außerhalb des IdP erstellt wurden. Ein Unternehmen mit 100 % SSO-Abdeckung kann dennoch über 250.000 ungovernte NHIs verfügen.
Die Zahlen sind alarmierend - und werden schlechter
Das Ausmaß des Problems ist in der Forschung des Jahres 2026 gut dokumentiert:
Laut [3] - einer herstellerunabhängigen Umfrage unter 5.000 IT- und Cybersecurity-Verantwortlichen in 17 Ländern - erlitten 71 % der Unternehmen im vergangenen Jahr mindestens einen identitätsbezogenen Sicherheitsvorfall.
[3] - darunter in Code gespeicherte API-Keys, statische Credentials und verwaiste Konten - wurde als Mitverursacher bei 41 % dieser Vorfälle genannt.
Unternehmen mit schwachem NHI-Management sind [4] und zahlen für die Bewältigung eines Vorfalls im Schnitt 147.000 US-Dollar mehr als der durchschnittliche Breach-Betroffene.
Das Bild bei der Credential-Hygiene ist ebenso ernüchternd. 97 % der NHIs verfügen über überschüssige Berechtigungen, die über das für ihre Funktion erforderliche Maß hinausgehen, und 71 % wurden nicht innerhalb der empfohlenen Zeitrahmen rotiert. 47 % der NHIs sind älter als ein Jahr, ohne dass eine Credential-Rotation stattgefunden hat. Nur 1 von 3 Unternehmen rotiert oder prüft Service-Accounts und nicht-menschliche Identitäten regelmäßig, und lediglich 11 % tun dies kontinuierlich.
Das Dwell-Time-Problem verschärft all das noch. Die durchschnittliche Verweildauer nach einem NHI-Breach beträgt über 200 Tage - mehr als das Dreifache des Durchschnittswerts bei kompromittierten menschlichen Konten. Ein API-Key bemerkt keine verdächtige Aktivität. Er authentifiziert sich einfach weiter.
Zwei Sicherheitsvorfälle, die das Abstrakte konkret machten
Salesloft Drift - August 2025
Im August 2025 wurde der Drift-Chatbot-Dienst von Salesloft zum Einfallstor für einen der bislang größten SaaS-Supply-Chain-Breaches. Drift ist über OAuth-Tokens mit Kundensystemen wie Salesforce, Slack und Google Workspace integriert. Bedrohungsakteure nutzten diese Integration aus, um Authentifizierungstoken zu stehlen und sich Zugang zu Kundenumgebungen zu verschaffen. Mehr als 700 Organisationen waren betroffen, darunter namhafte Anbieter wie Cloudflare, Zscaler, Palo Alto Networks und PagerDuty.
Zwischen dem 9. und 17. August 2025 nutzte die als UNC6395 verfolgte Angriffsgruppe gestohlene OAuth-Tokens aus der Drift-Chatbot-Integration von Salesloft, um sich Zugang zu Hunderten von Salesforce-Umgebungen zu verschaffen. Über einen Zeitraum von zehn Tagen fragten die Angreifer systematisch große Mengen an Datensätzen aus mehr als 700 Organisationen ab und exportierten diese. Die gestohlenen Datensätze wurden nach Klartext-AWS-Keys, VPN-Credentials, Snowflake-Tokens und anderen Secrets durchsucht, die Folgeangriffe ermöglichen könnten.
Die Grundursache: Der Breach resultierte aus schwachem Credential-Management, übermäßig weitreichenden Integrationen und fehlendem Monitoring - nicht aus einem direkten Exploit von Salesforce. Die OAuth-Tokens, die Drift mit den Salesforce-Instanzen der Kunden verbanden, waren die Angriffsfläche. Niemand hatte sie im Blick.
Vercel / Context AI - April 2026
Bei einem Angriff, der mit einer Lumma-Stealer-Malware-Infektion bei Context.ai etwa im Februar 2026 begann und im April 2026 öffentlich wurde, nutzten Angreifer die Kompromittierung der Google-Workspace-OAuth-Tokens von Context.ai, um sich einen Brückenkopf in den internen Systemen von Vercel zu verschaffen. Dabei wurden Umgebungsvariablen einer nicht genannten, aber Berichten zufolge begrenzten Anzahl von Kundenprojekten offengelegt.
Der Angreifer nutzte diese Credentials, um unbemerkt auf das Google-Workspace-Konto des Vercel-Mitarbeiters zuzugreifen - und umging dabei die Multi-Faktor-Authentifizierung vollständig, da OAuth-Tokens nach ihrer Ausstellung keine erneute Authentifizierung erfordern. Über Google Single Sign-On bewegte sich der Angreifer in die internen Systeme von Vercel - Issue-Tracker, Admin-Tools und interne Umgebungen. Anschließend extrahierte er in großem Umfang Umgebungsvariablen aus Vercel-Kundenprojekten: die Secrets und Credentials, die Unternehmen in Vercel hinterlegen, damit ihre Anwendungen funktionieren.
Eine allzu vertraute Geschichte im modernen Unternehmen: die SaaS-App, die ein einzelner Mitarbeitender ausprobiert hat, kaum genutzt, mit zentralen App-Tenants integriert und dann vergessen - ein unsichtbarer Knoten in der Angriffsfläche der Organisation. Vercel ist nicht einmal ein Context-Kunde - mindestens ein Vercel-Mitarbeitender hatte sich mit seinem Vercel-Enterprise-Account für die KI-Office-Suite registriert und "Alle erlauben"-Berechtigungen erteilt. Vercels interne OAuth-Konfigurationen scheinen diese Aktion ermöglicht zu haben, wodurch weitreichende Berechtigungen im Enterprise-Google-Workspace von Vercel gewährt wurden.
Beide Sicherheitsvorfälle teilen dasselbe strukturelle Versagen: OAuth-Tokens und Drittanbieter-Integrationen - klassische NHIs - die vollständig außerhalb jedes Governance-Rahmens operierten.
Der KI-Agenten-Multiplikator
Jeder KI-Agent, den Ihre Organisation einsetzt, erzeugt neue NHIs. KI-Agenten können autonom Sub-Agenten starten, die jeweils neue Credentials mit weitreichendem, dauerhaftem Zugriff und unzureichender menschlicher Aufsicht generieren. KI verstärkt bestehende NHI-Risiken in Bezug auf Governance, Sichtbarkeit, Eigentümerschaft und Credential-Lifecycle-Management. Die meisten Unternehmen verwalten KI-Identitäten noch immer mit Legacy-IAM-Tools und manuellen Prozessen - doch diese Ressourcen wurden nie für autonome, hochdynamische Systeme konzipiert. Da KI-gesteuerte Workloads die Identitätserstellung beschleunigen, kämpfen Unternehmen mit Credential-Sprawl, unklarer Eigentümerschaft, inkonsistenter Automatisierung und langsamen Behebungszeiten.
[5], dennoch erwarten 78 % der Befragten, dass das NHI-Wachstum das Wachstum menschlicher Identitäten im kommenden Jahr übertreffen wird. Die Lücke wird größer, nicht kleiner.
Die Governance-Herausforderung bei KI-Agenten unterscheidet sich qualitativ von der bei statischen Service-Accounts. Ein Service-Account hat einen definierten Scope, den man inventarisieren und prüfen kann. Ein KI-Agent mit delegiertem Zugriff kann diesen Scope dynamisch erweitern. Er kann Child-Agents starten. Er kann an einem Wochenende in Produktionssysteme schreiben, ohne dass eine Detection-Regel anschlägt - weil niemand definiert hat, wie anomales Agentenverhalten aussieht.
Der Weg zur NHI-Governance
Die gute Nachricht: Dieses Problem ist lösbar. Es erfordert, NHIs mit derselben Lifecycle-Sorgfalt zu behandeln wie menschliche Identitäten - Discovery, Klassifizierung, Durchsetzung des Least-Privilege-Prinzips, Rotation und Dekommissionierung - in einer einheitlichen Governance-Ebene.
Hier ist ein praktischer Fünf-Schritte-Plan:
Man kann nur regeln, was man sieht. Scannen Sie Ihren gesamten SaaS-Stack, Cloud-Umgebungen, CI/CD-Pipelines und Code-Repositories nach Service-Accounts, API-Schlüsseln, OAuth-Grants und Bot-Zugangsdaten. Beziehen Sie Drittanbieter-Integrationen ein – die Sicherheitsvorfälle bei Vercel und Salesloft Drift gingen beide auf OAuth-Verbindungen zurück, die nie inventarisiert wurden. Weisen Sie jeder gefundenen NHI einen Verantwortlichen zu.
Nicht alle NHIs sind gleich riskant. Klassifizieren Sie jede nach der Sensibilität der zugegriffenen Systeme, dem Umfang der Berechtigungen, dem Alter der Zugangsdaten sowie danach, ob ein bekannter Verantwortlicher und ein aktiver Anwendungsfall vorhanden sind. Verwaiste NHIs – solche ohne aktiven übergeordneten Prozess oder menschlichen Verantwortlichen – sollten als kritisches Risiko eingestuft und sofort widerrufen werden.
97 % der NHIs verfügen über übermäßige Berechtigungen. Prüfen Sie, welche Berechtigungen jede NHI tatsächlich nutzt im Vergleich zu dem, was sie besitzt, und entfernen Sie alles, was über die betriebliche Notwendigkeit hinausgeht. Überprüfen Sie bei OAuth-Grants die Scopes – die meisten Drittanbieter-Tools fordern weit mehr Zugriff an, als sie benötigen. Definieren Sie für KI-Agenten explizite Berechtigungsgrenzen vor dem Einsatz, nicht danach.
Statische API-Schlüssel, die nie ablaufen, sind der größte einzelne Risikofaktor bei NHIs. Wechseln Sie zu kurzlebigen Zugangsdaten mit automatischem Ablauf, Workload Identity Federation wo möglich, und richtliniengesteuerter Ausstellung, die den Geltungsbereich der Zugangsdaten an eine bestimmte Funktion und ein bestimmtes Zeitfenster knüpft. Jede NHI sollte einen definierten Lebenszyklus haben – Erstellung, Rotation und Außerbetriebnahme – der automatisch durchgesetzt wird.
Isolierte Tools – eines für Human IGA, ein weiteres für Secrets Management, ein weiteres für OAuth-Transparenz – erzeugen die Abdeckungslücken, die Angreifer ausnutzen. Eine einheitliche Governance-Schicht, die konsistente Richtlinien, Audits und Lifecycle-Automatisierung über alle Identitätstypen hinweg anwendet, schließt diese Lücken und macht die Compliance-Attestierung handhabbar. Dies ist die Architektur, die NHI-Governance im großen Maßstab nachhaltig macht.
Warum einheitliche Governance die einzige dauerhafte Antwort ist
Punktlösungen für NHI-Sicherheit - Secrets Manager, OAuth-Auditoren, Cloud-CIEM-Tools - adressieren jeweils einen Ausschnitt des Problems. Doch die Sicherheitsvorfälle bei Salesloft Drift und Vercel nutzten keine Lücke im Secrets-Management oder in der Cloud-Konfiguration aus. Sie nutzten das vollständige Fehlen jeglicher Governance über eine Klasse von Identitäten aus, die niemandem gehörte.
Die dauerhafte Antwort ist eine Governance-Plattform, die menschliche und nicht-menschliche Identitäten als zwei Ausprägungen desselben Problems behandelt: Wer hat Zugriff auf was, ist dieser Zugriff noch angemessen, und was passiert, wenn er es nicht ist? Das bedeutet feingranulare, richtliniengesteuerte Kontrolle auf der Ebene einzelner Tokens, OAuth-Scopes und Agenten-Berechtigungen - nicht nur grobe Rollenzuweisungen. Es bedeutet Lifecycle-Automatisierung, die den gesamten Stack abdeckt, einschließlich der langen Liste von SaaS-Apps, die kein SCIM unterstützen. Und es bedeutet kontinuierliche Sichtbarkeit, keine quartalsweisen Reviews.
Für Security-Verantwortliche und Platform-Engineers, die auf dieses Ziel hinarbeiten, lautet die Frage nicht ob NHIs governed werden sollen - die Breach-Daten belegen das eindeutig. Die Frage ist, ob Ihre aktuelle IGA-Plattform dafür gebaut wurde - oder für eine Welt, in der jede Identität einen HR-Datensatz hatte.
Die meisten Legacy-IGA-Plattformen wurden für Letzteres gebaut. Die Angriffsfläche, die Ihre Service-Accounts und API-Keys als nicht-menschliche Identitäten darstellen, und die strukturellen Unterschiede zwischen NHI-Governance und traditioneller IGA sind es wert, eingehend verstanden zu werden, bevor Sie Ihre Optionen evaluieren.
Das Zeitfenster schließt sich
Angreifer zielen zunehmend auf Machine-Identities und authentifizierte Session-Artefakte ab - zusätzlich zu klassischen Credentials. "Wir erleben eine strukturelle Verschiebung in der Art und Weise, wie Identitäten ausgenutzt werden", sagte Trevor Hilligoss, Chief Intelligence Officer bei SpyCloud. "Angreifer zielen nicht mehr nur auf Credentials ab. Sie stehlen authentifizierten Zugriff - einschließlich API-Keys, Session-Tokens und Automatisierungs-Credentials - und nutzen diesen Zugriff, um schneller vorzugehen und persistent zu bleiben."
Die Unternehmen, die hier die Nase vorn haben, warten nicht auf den nächsten Vorfall im Ausmaß von Vercel, um die Investition zu rechtfertigen. Sie bauen Governance-Programme auf, die jede Identität abdecken - menschlich und nicht-menschlich - in einer einzigen, revisionssicheren, richtliniengesteuerten Ebene.
