Sicherheit bei der Identitätsprüfung von Nicht-Menschen – eine Erklärung

Eine nicht-menschliche Identität (NHI) ist ein Software-Prinzipal, wie beispielsweise ein Dienstkonto, eine Workload, eine „ cloud “-Instanz, ein Gerät oder ein automatisierter Agent, der sich authentifizieren kann und Berechtigungen zum Zugriff auf Ressourcen erhalten kann. Hinter ihr steht keine Person, und sie wird durch ein Softwareereignis und nicht durch eine Einstellung erstellt. Außerhalb der Cybersicherheit hat der Begriff eine ganz andere Bedeutung, und das Akronym NHI wird in allgemeinen Suchergebnissen überwiegend mit einer nicht damit zusammenhängenden Bedeutung assoziiert. Um es klar zu sagen: Auf dieser Seite geht es um Maschinenprinzipale innerhalb von Identitätssystemen in Unternehmen.

Diese Identitäten machen mittlerweile den Großteil der Authentifizierungsvorgänge in einer modernen Infrastruktur aus. Sie verfügen über dauerhafte Berechtigungen, sind kontinuierlich aktiv, haben selten einen namentlich genannten Eigentümer, und ihre Zugangsdaten überdauern in der Regel die Systeme, die sie ausgestellt haben. Auf dieser Seite wird diese Gruppe definiert, ihre Abgrenzung zu Maschinenidentitäten sowie zum Identitäts- und Zugriffsmanagement (IAM) erläutert, aufgezeigt, wie diese Identitäten tatsächlich kompromittiert werden, und dargelegt, was ein Sicherheitsteam unternimmt, wenn eine dieser Identitäten einen Alarm auslöst.

Was ist eine nicht-menschliche Identität?

Eine nicht-menschliche Identität ist jedes Software-Subjekt, das sich authentifizieren und autorisieren lassen kann, um auf Ressourcen zuzugreifen, ohne dass eine Person dahinter steht. Dazu zählen Dienstkonten, Workloads, „ cloud “-Instanzen, Geräte und automatisierte Agenten. Diese Kategorie existiert, weil Automatisierung Anmeldedaten benötigt. Jeder geplante Job, jede Pipeline, jede Integration und jeder Microservice muss seine Identität nachweisen, bevor er etwas Sinnvolles ausführen kann.

Unter der Sicherheit nicht-menschlicher Identitäten, oft als NHI-Sicherheit abgekürzt, versteht man, diese Gruppe zu identifizieren, jeder Identität einen Eigentümer und einen begrenzten Umfang an Berechtigungen zuzuweisen, die Gültigkeitsdauer ihrer Zugangsdaten zu verkürzen und zu erkennen, wenn sich eine Identität auf eine Weise verhält, wie sie es zuvor noch nie getan hat. Programme zum Insider-Risikomanagement beziehen diese Identitäten zunehmend mit ein, da ein zugeordnetes Dienstkonto und ein nicht überwachter Mitarbeiter ein ähnliches Governance-Problem darstellen.

Der Grenzwerttest – was zählt und was nicht

Die „ Cloud “ Security Alliance zieht die Grenze sehr eng. In ihrem Papier „Defining Non-Human Identity“ aus dem Jahr 2026 gilt eine Entität „nur dann als NHI, wenn sie sich authentifizieren (nachweisen kann, wer sie ist) und autorisiert werden kann (Berechtigungen erhalten kann), entweder direkt oder indirekt, um auf Ressourcen zuzugreifen“ (Cloud Security Alliance).

Dieser Test schließt mehrere Dinge aus, die im allgemeinen Sprachgebrauch als nicht-menschliche Identitäten bezeichnet werden. Ein Konfigurationsdatensatz, wie beispielsweise ein CMDB-Eintrag, der einen Server beschreibt, ist keine Identität, es sei denn, er wird zur Authentifizierung oder zum Abruf von Berechtigungen verwendet. Ebenso wenig sind es Metadatenobjekte oder Code und Skripte, die niemals eine Authentifizierung durchführen. Vor allem aber sind Geheimnisse, Tokens, API-Schlüssel und Zertifikate ebenfalls keine Identitäten, es sei denn, sie sind an eine solche gebunden. Dieser letzte Ausschluss verändert die Art und Weise, wie ein Programm ausgeführt wird, und im nächsten Abschnitt wird erklärt, warum.

Die US-Regierung verwendet für denselben Begriff eine eigene Bezeichnung. Das NIST definiert eine „Non-Person Entity“ (NPE) als „eine mit der Informationstechnologie verbundene Entität mit einer digitalen Identität, die im Cyberspace agiert, jedoch kein menschlicher Akteur ist“, wobei es sich auf CNSSI 4009-2015, NIST SP 800-162 und NIST SP 800-207 (NIST CSRC) stützt. Wenn in einem Kontrollrahmenwerk oder einem Bundesvertrag von „NPE“ die Rede ist, ist damit eine nicht-menschliche Identität gemeint.

Wie viele nicht-menschliche Identitäten eine Organisation hat

Es gibt keinen branchenweiten Konsens darüber, um wie viel nicht-menschliche Identitäten die menschlichen Identitäten zahlenmäßig übertreffen, und die veröffentlichten Zahlen lassen sich nicht miteinander in Einklang bringen. Sie beziehen sich auf unterschiedliche Populationen: in einer Studie auf alle Unternehmen, in einer anderen auf „ cloud-native“ Unternehmen und in einer dritten ausschließlich auf große Organisationen. Sie verwenden unterschiedliche Nenner: In einem Fall werden Maschinenidentitäten pro Mitarbeiter gezählt, in einem anderen nicht-menschliche Identitäten pro menschlicher Identität. Und sie basieren auf unterschiedlichen Methoden, die von Authentifizierungsdaten über das Scannen von Repositorien bis hin zu Selbstauskünften in Umfragen reichen. Betrachten Sie jede in den Schlagzeilen genannte Quote als richtungsweisend und auf ihren jeweiligen Kontext bezogen, niemals als Maßstab für Ihre eigene Situation.

Was man mit Sicherheit sagen kann, ist die Richtung, in die es geht. In den meisten Unternehmen überwiegen mittlerweile nicht-menschliche Identitäten bei weitem gegenüber menschlichen, und diese Kluft vergrößert sich weiter, je mehr sich Automatisierung und agentenbasierte Arbeitsabläufe ausbreiten.

Ein erreichbarer, datierter Messwert ohne Verhältnisangabe untermauert dies. Ein Bericht aus dem Jahr 2026 ergab, dass 91 % der aktiven Produktionsidentitäten nicht-menschlicher Natur waren; diese stammen aus den AWS- und Google- Cloud -Umgebungen, die der Anbieter überwacht (Help Net Security). Dies ist ein Anteil der beobachteten aktiven Identitäten in der von einem Anbieter überwachten Infrastruktur. Es handelt sich nicht um ein Verhältnis, und eine Umrechnung in ein solches würde eine Zahl erfinden, die durch die Untersuchung nicht gestützt wird.

Welche Arten von nicht-menschlichen Identitäten gibt es?

Nicht-menschliche Identitäten lassen sich in fünf Arten einteilen, die danach gruppiert sind, woran die Identität gebunden ist, und nicht danach, welche Berechtigungsnachweise sie vorlegt.

Fünf Themen zur Identität

Tabelle: Die fünf Arten nicht-menschlicher Identitäten in der Taxonomie der „ Cloud Security Alliance“, womit die jeweilige Identität verbunden ist und jeweils ein konkretes Beispiel.

Die mittlere Spalte übernimmt die eigentliche Arbeit. Ein Dienstkonto wird an einen Anwendungsprinzipal gebunden, sodass es auch bei einer erneuten Bereitstellung erhalten bleibt. Eine Workload-Identität ist an einen laufenden Pod, Dienst oder eine Funktion gebunden und kann daher nur für Sekunden bestehen. Infrastruktur-Identitäten sind an Instanzen und Knoten gekoppelt, Geräte-Identitäten an Hardware und Firmware einschließlich IoT-Sensoren und Agent-Identitäten an einen autonomen Akteur. Workload-Identitäten sind die am schnellsten wachsende Gruppe in containerisierten Umgebungen, weshalb sich die Arbeit an der Kubernetes-Sicherheit und die Arbeit an nicht-menschlichen Identitäten in der Praxis so stark überschneiden.

Das Identitätsobjekt ist nicht der Authentifizierungsmechanismus

Unternehmen verwechseln regelmäßig die Identität mit dem Mittel, mit dem sie sich authentifiziert, und behandeln einen API-Schlüssel, ein Token oder ein Zertifikat so, als wäre die Anmeldeinformation die Identität. Das ist jedoch nicht der Fall. Es handelt sich dabei um Authentifizierungsmechanismen, die in der Taxonomie in fünf Kategorien unterteilt werden: statische Geheimnisse wie Passwörter, API-Schlüssel und SSH-Schlüssel; signierte Token wie JWT-, OIDC- und SAML-Assertions; Zertifikate einschließlich X.509 und SPIFFE-SVIDs; hardware- oder attestationsgestützte Anmeldedaten, die in einem TPM, HSM oder Secure Element gespeichert sind; sowie native Sitzungsanmeldedaten von „ cloud “, die kurzlebig und temporär sind.

Die Governance-Regel ergibt sich direkt aus dieser Trennung. Verknüpfen Sie Eigentumsverhältnisse, Lebenszyklus und Berechtigungen mit dem Objekt – also dem Dienstkonto oder der Workload, die fortbestehen. Passen Sie die Stärke der Anmeldedaten, die Rotationshäufigkeit und die Erneuerung an den Mechanismus an, der ausgetauscht werden kann, ohne dass sich die Identität ändert. Programme, die diesen Ansatz umkehren, rotieren Geheimnisse zwar gewissenhaft, doch niemand kann sagen, wem das Konto gehört, zu dem diese Geheimnisse gehören. Das ist auch der Grund, warum eine Bestandsaufnahme von API-Schlüsseln keine Bestandsaufnahme von Identitäten ist.

Sind KI-Agenten nicht-menschliche Identitäten?

Ja, mit einer Einschränkung. Die Taxonomie der „ Cloud Security Alliance“ nennt „Agentenidentitäten (autonome Akteure, einschließlich KI)“ als einen ihrer fünf Typen; ein KI-Agent ist also eine nicht-menschliche Identität und weist alle auf dieser Seite genannten Fehlermodi auf: dauerhaftes Zugriffsrecht, nicht rotierende Zugangsdaten und keinen namentlich benannten Eigentümer. Die Einschränkung besteht darin, dass die Autorisierung von Agenten gegenüber Tools nun über ein eigenes normatives Modell verfügt. Die Spezifikation des Model Context Protocol vom 28.07.2026 macht MCP-Server zu OAuth-2.1-Ressourcenservern, die „überprüfen MÜSSEN, ob Zugriffstoken speziell für sie als Zielgruppe ausgestellt wurden“ (Model Context Protocol). Die für Agenten spezifischen Fragen zu Governance, Lebenszyklus und Kontrolle gehören zum Bereich der agentenbasierten KI-Sicherheit.

Inwiefern steht die Identität nicht-menschlicher Wesen in Zusammenhang mit der Maschinenidentität und IAM?

Die Sicherheit nicht-menschlicher Identitäten ist die Anwendung von IAM auf Subjekte, für die es nie einen Einstellungs-, Versetzungs- oder Austrittsprozess gab. Die Tabelle unterscheidet zwischen den drei Begriffen, die oft synonym verwendet werden.

Tabelle: Wie sich menschliche Identitäten, nicht-menschliche Identitäten und Maschinenidentitäten hinsichtlich Herkunft, Berechtigungsnachweis, Eigentumsverhältnissen und Lebensende unterscheiden.

Menschliche versus nicht-menschliche Identitäten

Der entscheidende Unterschied liegt darin, woher die Identität stammt. Menschliche Identitäten durchlaufen HR-gesteuerte Prozesse bei Einstellungs-, Versetzungs- und Austrittsvorgängen, sodass ihr Lebenszyklus über ein Erfassungssystem verfügt und eine dafür verantwortliche Person vorhanden ist. Nicht-menschliche Identitäten entstehen stattdessen aus Ereignissen im Software-Lebenszyklus: einer Bereitstellung, einem Provisioning-Lauf, dem Start einer Workload, der Ausführung einer Pipeline, einem Autoscaling-Ereignis oder dem Aufruf eines Agenten. Kein Personalverwaltungssystem weiß, dass irgendetwas davon stattgefunden hat. Deshalb lassen sich Governance-Modelle, die auf den Prozessen „Joiner“, „Mover“ und „Leaver“ basieren, nicht ohne Weiteres auf diese Gruppe anwenden.

Maschinenidentität und die Zertifikatsstruktur

Die Begriffe überschneiden sich, sind jedoch keine Synonyme. Das Maschinenidentitätsmanagement steht in der Tradition der PKI und konzentriert sich auf Zertifikate, Schlüssel und die Erneuerung vor Ablauf. Bei der Identitätsverwaltung für nicht-menschliche Akteure stehen Dienstkonten, OAuth-Token, API-Schlüssel und die Autorisierung zwischen Anwendungen im Mittelpunkt. Die Unterscheidung zwischen „Subjekt“ und „Mechanismus“ erklärt den Unterschied: Ein Zertifikat ist ein Mechanismus, keine Art von Identität.

Die Gültigkeitsdauer von Zertifikaten wird nach einem eigenen Zeitplan verkürzt. Das CA/Browser Forum hat am 11. April 2025 den Beschluss SC-081v3 verabschiedet, wonach die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise von 398 Tagen auf 47 Tage verkürzt wird, wobei die Verkürzungen „voraussichtlich ab März 2026 beginnen und im März 2029 abgeschlossen sein sollen“ (CA/Browser Forum). Dieser Zeitplan gilt ausschließlich für öffentlich vertrauenswürdige TLS-Zertifikate. Er betrifft weder interne PKI-Systeme noch die OAuth-Token und API-Schlüssel, die auf dieser Seite im Vordergrund stehen.

Die Position von NHI-Sicherheit im Verhältnis zu IAM

IAM ist ein Bereich der Cybersicherheit, und die Sicherheit nicht-menschlicher Identitäten ist der Teil davon, der sich mit Prinzipalen befasst, hinter denen keine Person steht. Diese Unterscheidung ist eher operativer als akademischer Natur, da ältere IAM-Tools auf Ereignissen im Lebenszyklus von Menschen basierten. In einer von einem Anbieter gesponserten Umfrage der „ Cloud Security Alliance“ aus dem Jahr 2026, an der 383 Fachleute teilnahmen und die im August und September 2025 online durchgeführt wurde, gaben 92 % der Befragten an, dass sie nicht davon überzeugt seien, dass ihre älteren IAM-Lösungen die mit KI und nicht-menschlichen Identitäten verbundenen Risiken effektiv bewältigen können (Cloud Security Alliance). In der Identitätsanalyse treffen diese beiden Bereiche in der Praxis aufeinander, wobei für beide Verhaltensmodellierung angewendet wird.

Wie nicht-menschliche Identitäten gefährdet werden

Nicht-menschliche Identitäten werden durch Offboarding gefährdet, bei dem Zugangsdaten nie widerrufen werden, durch Integrationen von Drittanbietern, die aktive Tokens speichern, und durch Geheimnisse, die nie aktualisiert wurden. Was sie attraktiv macht, ist eher struktureller als exotischer Natur. Sie verfügen über dauerhafte Zugriffsrechte, laufen kontinuierlich, haben selten einen Verantwortlichen, der bemerken könnte, dass etwas nicht stimmt, und ihre Aktivitäten sehen genauso aus wie die legitime Automatisierung, als die sie sich ausgeben.

Das Standesprivileg und die Ausbreitung von Geheimnissen

Jede nicht-menschliche Identität, die über Berechtigungen verfügt, die sie derzeit nicht benötigt, vergrößert die Angriffsfläche, da die Anmeldedaten gültig bleiben, unabhängig davon, ob sie tatsächlich genutzt werden oder nicht. Gestohlene Anmeldedaten nicht-menschlicher Identitäten sind zudem ein direkter Weg für laterale Bewegungen, da ein Dienstkonto, das bereits mit fünf Systemen kommuniziert, einen vorgefertigten Pfad zwischen diesen darstellt. Diese Identitäten konzentrieren sich dort, wo die direkte Überwachung am geringsten ist, weshalb die Bereiche „cloud “ und Sicherheitsprogramme für nicht-menschliche Identitäten immer stärker zusammenwachsen.

Die Ausbreitung von Geheimnissen ist der messbare Teil des Problems. Die fünfte Ausgabe des Berichts „State of Secrets Sprawl“, der am 17. März 2026 veröffentlicht wurde, identifizierte im Jahr 2025 28.649.024 neue Geheimnisse in öffentlichen GitHub-Commits – ein Anstieg von 34 % gegenüber dem Vorjahr –, darunter 1.275.105 Geheimnisse, die zu KI-bezogenen Diensten gehören, was einem Anstieg von 81 % gegenüber dem Vorjahr entspricht (GitGuardian). Dabei handelt es sich um Anmeldedaten für Identitäten, die jemand eingerichtet hat und die von niemandem nachverfolgt wurden; und der Diebstahl von Anmeldedaten, der in einem öffentlichen Repository beginnt, erfordert keinerlei Eindringen in das System.

Die Beteiligung Dritter verschärft die Situation zusätzlich. Verizon berichtet, dass die Beteiligung Dritter an Sicherheitsvorfällen im Vergleich zum Datensatz des Vorjahres um 60 % gestiegen ist, wobei Vorfälle mit Beteiligung Dritter nun 48 % aller Sicherheitsvorfälle ausmachen (Verizon Newsroom). In der Zusammenfassung für 2026 wird hinzugefügt, dass die Ausnutzung von Schwachstellen „im diesjährigen Berichtsdatensatz auf 31 % gestiegen ist“ und damit den häufigsten Erstzugriffsvektor darstellt (Verizon 2026 DBIR – Zusammenfassung). Der vollständige Bericht legt den Untersuchungszeitraum für die erfassten Vorfälle auf den 1. November 2024 bis zum 31. Oktober 2025 fest. Ein Angriff auf die Lieferkette, der die Tokens einer Integration erreicht, greift auf alles zu, womit diese Tokens in Berührung kommen können.

Was drei bestätigte Vorfälle zeigen

Tabelle: Drei nachgewiesene Vorfälle, die jeweils eine andere Art und Weise veranschaulichen, wie eine nicht-menschliche Identität versagt, mit der Grundursache und der daraus zu ziehenden Lehre.

Zuordnung der OWASP „Top 10“ zu nicht-menschlichen Identitäten zu realen Vorfällen

Die OWASP-Top-10-Liste zu nicht-menschlichen Identitäten umfasst genau zehn Einträge, von NHI1 bis NHI10. Durch die Zuordnung zu nachgewiesenen Vorfällen lassen sich theoretische Risiken von solchen unterscheiden, die bereits Konsequenzen nach sich gezogen haben.

Tabelle: Fünf Einträge aus den OWASP „Non-Human Identities Top 10“ (2025), jeweils zugeordnet zu einem verifizierten Vorfall, der diesen Eintrag veranschaulicht.

Die fünf Einträge, die oben nicht aufgeführt sind, lauten: NHI4:2025 „Unsichere Authentifizierung“, NHI6:2025 „Unsichere Konfigurationen beim Einsatz von „ Cloud “, NHI8:2025 „Umgebungsisolierung“, NHI9:2025 „Wiederverwendung von NHI“ und NHI10:2025 „Menschliche Nutzung von NHI“ (OWASP). Der letztgenannte Eintrag wird in Zusammenfassungen der Liste am häufigsten ausgelassen.

Im Zusammenhang mit „ MITRE ATT&CK “ werden gestohlene API-Schlüssel, OAuth-Token und Signaturschlüssel unter folgenden Umständen erlangt: 0006 Zugang zu Anmeldeinformationen. Ein Hinweis zur Benennung für alle, die ältere Erkennungslogik abbilden: Die Enterprise-Matrix in Version 19.2 umfasst 15 Taktiken, und „Defense Evasion“ gehört nicht mehr dazu, da sie in Version 19 ausgemustert und durch 0005 Tarnung und 0112 Verteidigungsbeeinträchtigung.

Das gleiche Muster lässt sich auch in den Schwachstellenaufzeichnungen beobachten. CVE-2026-12564, veröffentlicht am 18. August 2026, beschreibt ein Credential-Plugin, bei dem ein authentifizierter Angreifer mit Berechtigungen zur Erstellung von Anmeldedaten dafür sorgen kann, dass das Kubernetes-Service-Account-Token eines Controller-Pods ausgelesen und an eine vom Angreifer kontrollierte URL gesendet wird. Die CNA stufte die Schwachstelle mit 9,6 als „kritisch“ ein, und das NVD hatte zum Zeitpunkt der Erstellung dieses Artikels noch keine eigene Bewertung veröffentlicht (NVD).

So erkennen und begrenzen Sie Identitätsmissbrauch durch nicht-menschliche Akteure

Um eine Kompromittierung nicht-menschlicher Identitäten zu erkennen, muss zunächst ein Referenzprofil der normalen Aktivitäten jedes Maschinenprinzips erstellt werden, und bei Abweichungen muss eine Warnung ausgelöst werden, da die Anmeldedaten gültig sind und die Authentifizierung an sich keinen Verdacht erregt. „Containment“ bedeutet dann, zunächst die Berechtigungen zu widerrufen und erst anschließend die Abhängigkeiten in der Produktion zu klären – eine Entscheidung, die die meisten Teams nicht im Voraus getroffen haben. Damit handelt es sich hierbei ebenso sehr um ein Problem des SOC-Betriebs wie um ein Problem der Identitäts-Governance.

Es lohnt sich, diese Lücke präzise statt allgemein zu beschreiben. Es gibt bereits Leitlinien zu den Fähigkeiten zur Identifizierung nicht-menschlicher Akteure sowie zur Reihenfolge der Reaktionsschritte, auf die im Folgenden auf dieser Seite verwiesen wird. Was jedoch keine Rangliste und auch nicht die für diese Kategorie zuständige Normungsorganisation bereitstellt, sind SOC-bezogene Triage-Kriterien oder ein benanntes, sequenziertes Handbuch zur Eindämmung. Genau diese Ebene ergänzt der vorliegende Abschnitt.

Warum menschenzentrierte Erkennungssignale bei nicht-menschlichen Identitäten nicht ausgelöst werden

Menschliche Nutzer greifen vorhersehbar auf Systeme zu – von bestimmten Orten aus oder zu bestimmten Tageszeiten –, und ein Großteil der Identitätserkennung basiert auf dieser Vorhersehbarkeit. Nicht-menschliche Identitäten weisen diese physischen Verhaltensmuster nicht auf, weshalb „unmögliche Reisen“ – das klassische Beispiel – von der „ Cloud Security Alliance“ als ein Muster beschrieben werden, das „auf Menschen ausgerichtet ist, aber nicht auf eine NHI“ (Cloud Security Alliance). Erkennungsmechanismen, die aus der menschlichen Bevölkerung abgeleitet wurden, versagen hier stillschweigend. Sie schlagen nicht fehl, sie werden gar nicht erst ausgelöst.

Fünf Funktionen treten an ihre Stelle. Die kontinuierliche Erkennung und Identifizierung spürt Identitäten auf, die von niemandem registriert wurden. Identitätsgraphen bilden Ketten von übernommenen Rollen und delegiertem Vertrauen ab, wodurch transitive Pfade zur Rechteausweitung entstehen. Durch die Erstellung von Verhaltens-Baselines wird für jede Identität ein Normalzustand festgelegt. Die Echtzeit-Erkennung deckt den erstmaligen Zugriff auf Kundendaten, verdächtige Aktualisierungen und das massenhafte Herunterladen vertraulicher Daten ab. Die Reaktion auf Vorfälle schließt den Kreis. Die Funktion selbst ist die Erkennung von und Reaktion auf Identitätsbedrohungen, wobei die Identitätsverhaltensanalyse die zugrunde liegende Modellierung liefert.

Triage-Kriterien für eine Warnmeldung bezüglich einer nicht-menschlichen Identität

Prüfen Sie die Warnmeldung anhand dieser acht Fragen, die nach dem Einfluss geordnet sind, den jede einzelne auf das Urteil hat.

1. Gibt es einen namentlich bekannten menschlichen Inhaber dieses Identitätsnachweises? Niemand kann bestätigen, dass diese Aktivität erwartet wurde.
2. Weicht das Verhalten von der festgelegten Basislinie der Identität ab? Ein Anzeichen dafür ist, dass eine Arbeitslast nach zwei Jahren mit fünf Aufgaben nun eine sechste Aufgabe ausführt.
3. Handelt es sich um einen erstmaligen Zugriff auf einen Speicher mit sensiblen Daten? Die höchste Abweichung, die bei einer langfristig bestehenden Identität verfügbar ist.
4. Ist die Anmeldeinformation noch gültig oder hat ihr Rotationsintervall bereits abgelaufen? Durch die Rotationsrückstände verlängert sich der Zeitraum, in dem eine gestohlene Anmeldeinformation noch funktioniert.
5. Hat die Identität über ihre eigentliche Funktion hinaus ein Privileg? Übermäßige Berechtigungen verwandeln einen kleinen Kompromiss in eine Katastrophe mit weitreichenden Folgen.
6. Ist die Identität über eine Integration eines Drittanbieters abrufbar? Token von Drittanbietern stellen eine First-Party-Exposition dar, wie Salesloft Drift gezeigt hat.
7. Zeigt der Identitätsgraph einen transitiven Weg zu höheren Privilegien auf? Ketten aus angenommenen Rollen ermöglichen es unscheinbaren Identitäten, bemerkenswerte Positionen zu erreichen.
8. Gibt es Anzeichen für eine massenhafte Abfrage geheimer Daten? Massenabrufe aus einem Datenspeicher sind selten Teil der normalen Automatisierung.

‍

‍

Eine Eindämmungssequenz und die Entscheidung zwischen „Revoke“ und „Break-Production“

Die „ Cloud Security Alliance“ liefert die Vorgaben, und diese sind fundiert. Bei einer Erkennung sollten zunächst kompromittierte Tokens und Zugriffsschlüssel widerrufen werden, um den Zugriff des Angreifers zu unterbinden. Anschließend sind die betroffenen Workloads zu isolieren und der Ausbreitungsradius durch Durchlaufen des Identitätsgraphen einzugrenzen. Erst nachdem die Umgebung als sicher verifiziert wurde, sollte die Wiederherstellung – einschließlich des Austauschs von Anmeldedaten – automatisiert werden, wobei bei Vorfällen mit hohem Schweregrad oder unklaren Vorfällen eine manuelle Überprüfung beibehalten wird, damit keine neuen Geheimnisse in einem noch kompromittierten Kontext ausgegeben werden.

Was diese Anordnung voraussetzt, aber nicht bereitstellt, ist die darunterliegende Entscheidungsebene. Drei Fragen müssen vor dem Auftreten eines Vorfalls und nicht erst währenddessen beantwortet werden. Wer trifft die Entscheidung über den Widerruf, wenn für die Identität kein namentlich benannter Inhaber vorhanden ist? Wie sieht die Ausweichlösung aus, wenn der Widerruf eine Produktionsabhängigkeit unterbricht? Wie lässt sich der Widerruf für ein Dienstkonto, dessen Nutzer unbekannt sind, schrittweise umsetzen?

Dieser Zielkonflikt ist keine hypothetische Frage. In der SANS-Umfrage „State of Identity Threats and Defenses“ aus dem Jahr 2026, an der weltweit mehr als 500 Sicherheitsexperten teilnahmen, gaben 92 % an, dass sie die Anmeldedaten von Systemen nicht im 90-Tage-Rhythmus ändern, da sie befürchten, dass dadurch Dienstkonten nicht mehr funktionieren könnten (Infosecurity Magazine). Ein praktikabler stufenweiser Ansatz schränkt den Geltungsbereich ein, bevor der Zugriff gesperrt wird: Zunächst werden Berechtigungen entzogen, dann wird beobachtet, was nicht mehr funktioniert, während die Zugangsdaten noch gültig sind, und schließlich werden sie widerrufen.

Die Sperrung muss auch die Token-Ebene erreichen. In der Warnung des FBI zu bösartigen verbundenen Apps wird darauf hingewiesen, dass durch die Autorisierung solcher Apps Schutzmaßnahmen wie die Multi-Faktor-Authentifizierung, das Zurücksetzen von Passwörtern und die Anmeldeüberwachung umgangen werden und dass Aktivitäten der bösartigen App wie eine vertrauenswürdige Integration aussehen können, da OAuth-Token von der Plattform selbst ausgestellt werden. Im Fall des Drift-Hacks erfolgte die Eindämmung auf diese Weise: Am 20. August 2025 wurden alle aktiven Zugriffs- und Aktualisierungstoken für die Anwendung widerrufen (FBI FLASH).

Wie schnell ist schnell genug?

Ein Anbieter gibt sowohl ein Ziel als auch einen Messwert an – in derselben Einheit und für dieselbe Maßnahme –, was die Zuordnung ungewöhnlich klar macht. Seine IAM-Arbeitsgruppe nennt als anschauliches Ziel: „weniger als 24 Stunden für die Behebung, um kompromittierte Identitäten einzudämmen, bevor Angreifer eine laterale Bewegung erreichen.“ Das ist ein Ziel für ein ausgereiftes Programm, kein beobachteter Richtwert.

Gemessen daran dauert es laut der vom Anbieter gesponserten Umfrage aus dem Jahr 2026 unter 383 Fachleuten bei fast einem Viertel (24 %) der Unternehmen mehr als 24 Stunden, um eine Zugangsberechtigung nach einer potenziellen Kompromittierung zu ändern oder zu widerrufen, und 30 % benötigen mehr als einen Tag, um einen schwerwiegenden Vorfall im Zusammenhang mit Zugangsberechtigungen einzustufen (Cloud Security Alliance). Lesen Sie diese zweite Zahl aufmerksam durch. Sie gibt an, wie schnell Teams eine Triage durchführen, nicht, worauf sich diese Triage bezieht.

Welche Beweismittel sind aufzubewahren?

Behandeln Sie Telemetriedaten zu nicht-menschlichen Identitäten als eine dauerhaft gespeicherte und überwachte Kontrollmaßnahme und nicht als zufälliges Nebenprodukt. Coupang ist das stichhaltigste Argument, das hierfür vorliegt. Die Aufsichtsbehörden ordneten die Aufbewahrung der Zugriffsprotokolle an, und sechs Tage später löschte das Unternehmen manuell Webzugriffsprotokolle aus einem Zeitraum von etwa sechs Monaten. Etwa 13 % der Protokolle aus dem Zeitraum des Angriffs gingen verloren, „wodurch es unmöglich wurde, alle betroffenen Opfer zu identifizieren“, und die Kommission leitete wegen Beweisvernichtung ein Strafverfahren gegen das Unternehmen ein (The Record).

So verwalten Sie den Lebenszyklus nicht-menschlicher Identitäten

Die Verwaltung nicht-menschlicher Identitäten bedeutet, diese zu ermitteln, jeder Identität einen menschlichen Inhaber zuzuweisen und die Gültigkeitsdauer jeder Zugangsberechtigung zu verkürzen. Die einzelnen Schritte werden der Reihe nach durchgeführt.

1. Entdecken Sie alle nicht-menschlichen Identitäten in „ cloud “, SaaS und On-Premises
2. Weisen Sie jeder gefundenen Identität einen namentlich genannten Verantwortlichen zu
3. Berechtigungen auf den Umfang beschränken, den die Identität tatsächlich nutzt
4. Speichern Sie die Anmeldedaten in einem Tresor und automatisieren Sie deren Rotation
5. Bestandsaufnahme im Rahmen eines wiederkehrenden Überprüfungszyklus bestätigen
6. Die Identität deaktivieren, sobald ihr Zweck erfüllt ist

Erfassung, Eigentumsverhältnisse und Bestandsaufnahme

Die Erfassung steht an erster Stelle, da bei einer nicht erfassten Population nichts anderes funktioniert, und sie muss sich über cloud, SaaS und lokale Infrastrukturen erstrecken – und nicht nur auf einen dieser drei Bereiche beschränken. Die Zuständigkeit steht an zweiter Stelle, und dies ist der Schritt, den die meisten Programme überspringen. In derselben, vom Anbieter gesponserten Umfrage aus dem Jahr 2026 unter 383 Fachleuten gaben 51 % der Unternehmen an, dass das Fehlen klarer Zuständigkeiten oder Verantwortlichkeiten ihr größtes Problem sei (Cloud Security Alliance). Aus diesen beiden Punkten ergibt sich ein zertifizierbares Inventar. Das „Standing Privilege“ ist zudem der Schnittpunkt zwischen der Überwachung privilegierter Zugriffe und der Arbeit mit nicht-menschlichen Identitäten und zero trust ist das maßgebliche Modell, da es keine Berechtigungen aufgrund des Standorts oder einer vorherigen Authentifizierung gewährt.

Rotation und Verwaltung von Geheimnissen

Drei unabhängige Messungen weisen von drei verschiedenen Ausgangspunkten aus in dieselbe Richtung. Sie dürfen niemals gemittelt, zusammengefasst oder voneinander abgezogen werden, da keine zwei von ihnen denselben Nenner haben.

Tabelle: Drei unabhängige Messungen der Zertifikatrotation, die aus einem Beispielziel, einer Selbstauskunft und den Telemetriedaten des Anbieters stammen. Jede Zeile enthält einen anderen Nenner, daher dürfen diese Zahlen keinesfalls gemittelt, zusammengefasst oder voneinander abgezogen werden.

Die Telemetriedaten stammen aus dem Jahr 2025 und sind mittlerweile veraltet; zudem spiegeln sie eher den Kundenstamm eines einzelnen Anbieters wider als den Markt insgesamt. Dennoch ist die Übereinstimmung zwischen Zielvorgabe, Selbstauskunft und Telemetriedaten ein stärkerer Beleg als jede dieser drei Quellen für sich genommen.

Kurzlebige Workload-Identität mit SPIFFE und SPIRE

Die standardbasierte Lösung für langfristig gültige Geheimnisse besteht darin, auf deren Verwendung zu verzichten. Das „Secure Production Identity Framework for Everyone“ (SPIFFE) ist eine Sammlung von Open-Source-Spezifikationen für die Initialisierung und Vergabe von Identitäten an Dienste in dynamischen und heterogenen Umgebungen unter Verwendung kurzlebiger Identitätsnachweise, die über eine einfache API abgerufen werden. SPIRE ist die Implementierung dieser Spezifikationen im Rahmen des SPIFFE-Projekts.

Vier Konzepte bilden die Grundlage des Modells. Eine SPIFFE-ID ist ein im URI-Format dargestellter Name für eine Workload. Ein SVID (SPIFFE Verifiable Identity Document) ist das entsprechenden Nachweisdokument im X.509- oder JWT-Format. Über die Workload-API ruft eine Workload ihr eigenes SVID ab, ohne ein statisches Geheimnis zu speichern. Eine Vertrauensdomäne ist die Grenze, innerhalb derer diese Identitäten ausgestellt und als vertrauenswürdig angesehen werden. Die Dokumentation liegt derzeit in der Version v1.15.2 (SPIFFE) vor. Die Governance ist geregelt: SPIFFE wurde am 29. März 2018 in die „ Cloud “ (Native Computing Foundation) aufgenommen, am 22. Juni 2020 in den „Incubating“-Status überführt und am 23. August 2022 ausder CNCF entlassen.

Dies gehört hierher, weil eine kurzlebige, nachweisbare Workload-Identität bestehende Anmeldedaten vollständig aufhebt, was die strukturelle Antwort auf NHI7:2025 „Long-Lived Secrets“ darstellt. Identitätsstrukturen bringen jedoch ihre eigenen Fehler mit sich. CVE-2026-18677, veröffentlicht am 12. August 2026, beschreibt ein Service-Mesh, in dem sich eine Datenebene, die ein „tags-bound“-Token vorlegt, unter einem beliebigen Workload-Label registrieren und die SPIFFE-Identität eines anderen Workloads abrufen könnte; die Schwachstelle wurde von der CNA mit 6,0 (mittel) bewertet und war zum Zeitpunkt der Erstellung dieses Artikels vom NVD noch nicht bewertet (NVD).

Kennzahlen, die eine Risikominderung belegen

In diesem Bereich werden so gut wie keine gemessenen Benchmark-Ergebnisse veröffentlicht; betrachten Sie die Programmziele daher eher als Zielvorgaben denn als tatsächlich gemessene Leistung.

Tabelle: Von der „ Cloud Security Alliance“ veröffentlichte Programmziele, wobei nur dann ein Messwert zum Vergleich angegeben wird, wenn Einheit und Maßnahme übereinstimmen. Der Quelle eigene Anmerkung: „Die hier dargestellten Ziele sind orientierende Vorgaben für ausgereifte NHI-Sicherheitsprogramme und sollten unter Berücksichtigung des organisatorischen Risikos, der Kritikalität des NHI und der betrieblichen Anforderungen angepasst werden.“ Es handelt sich nicht um festgelegte Benchmarks.

Sicherheit und Compliance im Bereich nicht-menschlicher Identitäten

NIS2 und DORA erfassen die Identität nichtmenschlicher Akteure eher durch Zugriffskontrolle und IKT-Risiken durch Dritte als durch deren namentliche Nennung.

Tabelle: Wie die beiden wichtigsten EU-Instrumente nichtmenschliche Identitäten berücksichtigen und auf welchen Artikeltext sich die jeweilige Regelung stützt.

Artikel 21 Absatz 2 der NIS2-Richtlinie zählt zehn Maßnahmen (a) bis (j) auf, doch ist die Rahmenklausel wichtiger als die Anzahl. Die Maßnahmen „basieren auf einem All-Hazards-Ansatz … und umfassen mindestens Folgendes“, wodurch die zehn Maßnahmen eher eine Untergrenze als eine erschöpfende Liste darstellen. Beachten Sie auch, was Artikel 21 Absatz 2 Buchstabe j nicht vorsieht. Da er mit den Worten „gegebenenfalls“ endet, schreibt NIS2 die Multi-Faktor-Authentifizierung nicht bedingungslos vor. Die Mitgliedstaaten hatten bis zum 17. Oktober 2024 Zeit, die Umsetzungsmaßnahmen zu erlassen und zu veröffentlichen, und mussten diese ab dem 18. Oktober 2024 anwenden (Europäische Kommission).

Anhang G des Papiers der „ Cloud Security Alliance“ ordnet unabhängig voneinander Praktiken zur Identitätsverwaltung nicht-menschlicher Akteure den Standards SOC 2, ISO 27001:2022, NIST SP 800-53 und NIST CSF, der DSGVO, HIPAA, PCI-DSS v4.0, DORA und NIS2 zu, wobei die Durchsetzung des Prinzips der geringsten Berechtigungen unter Artikel 21 Absatz 2 Buchstabe i fällt. Dabei ist jedoch der folgende Vorbehalt zu beachten: „Zuordnungen weisen auf eine Übereinstimmung hin, garantieren jedoch keine Zertifizierung.“ Umfassendere Compliance -Programme beziehen die nicht-menschliche Population zunehmend standardmäßig in ihren Geltungsbereich ein.

Moderne Ansätze zur Identitätssicherheit bei Nicht-Menschen

Die Tool-Landschaft lässt sich in fünf herstellerneutrale Kategorien einteilen: Erfassung und Bestandsaufnahme, Verwaltung und Speicherung von Geheimnissen, Berechtigungs- und Zugriffssteuerung, Identitätsstrukturen für Workloads sowie Verhaltenserkennung für Maschinenprinzipale. Die meisten Programme setzen zwei oder drei dieser Komponenten zusammen, anstatt nur eine einzige Lösung zu erwerben.

Bewerten Sie anhand von Kriterien statt anhand von Kandidaten. Fragen Sie, wie weit die Erfassung über cloud, SaaS und lokale Umgebungen reicht und ob das Tool die Zuständigkeiten abbildet, anstatt lediglich Identitäten aufzulisten. Prüfen Sie die Bandbreite der abgedeckten Anmeldedaten-Typen und ob die Automatisierung der Passwortrotation Produktionsabhängigkeiten berücksichtigt, anstatt davon auszugehen, dass keine bestehen. Fragen Sie, ob die Verhaltenserkennung auf Maschinenprinzipale abgestimmt ist oder von menschlichen Modellen abgeleitet wurde, und vergewissern Sie sich, dass die ausgegebenen Nachweise auditfähig sind, da die Erkennung und Reaktion auf Identitätsbedrohungen sowie Compliance-Nachweise auf denselben Telemetriedaten basieren. Die Entwicklung geht in eine einheitliche Richtung: Dauerhafte Geheimnisse weichen kurzlebigen, beglaubigten Workload-Identitäten.

Wie „ Vectra AI “ das Thema Identitätssicherheit für nicht-menschliche Wesen betrachtet

Vectra AI geht von der Prämisse aus, dass ein Kompromittierung bereits angenommen wird. Wenn sich eine nicht-menschliche Identität authentifizieren kann, kann sie missbraucht werden, und die eigentliche Frage ist, ob dies überhaupt jemand bemerken würde. Die Methodik ist verhaltensbasiert: Maschinen-Prinzipale benötigen für Maschinen entwickelte Referenzwerte und keine von Menschen abgeleiteten Erkennungsmechanismen.

‍