In vielen IT-Umgebungen wird über Benutzerkonten, MFA und Phishing gesprochen, als gäbe es nur menschliche Identitäten. Dabei laufen im Hintergrund längst die maschinellen Nachtschichten: Service Accounts, API-Keys, Tokens, Workload Identities, Bots, Automationen und Agenten.
Also all das, was keine Pause macht – und unter Umständen Vollzugriff hat.
Hier wird es kritisch – oder unangenehm. Je nachdem, wie gut du deine Umgebung kennst.
Non-Human Identities, kurz NHIs, sind in modernen IT-Umgebungen Teil der Infrastruktur. Ohne sie läuft kein Cloud-Deployment, keine Integration, kein Backup, keine SaaS-Anbindung und immer öfter auch kein KI-Workflow mehr.
Gleichzeitig sind sie in vielen Unternehmen ein blinder Fleck: still, mächtig, oft überprivilegiert – und erstaunlich selten sauber inventarisiert. OWASP führt NHIs inzwischen nicht ohne Grund als eigenes Top-10-Risikofeld, unter anderem mit Themen wie unvollständigem Offboarding, Weitergabe vertraulicher Informationen, anfällige NHI-Dienste und unsichere Authentifizierung.
NHIs sind digitale Identitäten für Maschinen, Anwendungen und Workloads. Gemeint sind nicht Benutzerkonten, sondern zum Beispiel:
Microsoft beschreibt solche Service Accounts als Konten für nicht-menschliche Entitäten wie Anwendungen, APIs oder Dienste.
Das wirkt zunächst unproblematisch – solange diese Identitäten sauber verwaltet werden. Das Problem ist nur: Das passiert oft nicht.
Menschen verursachen viele Sicherheitsvorfälle. Menschen klicken auf Dinge. Menschen vergessen Passwörter. Menschen schreiben „123456!“ nur aus pädagogischen Gründen in Präsentationen. Aber Menschen haben immerhin Sichtbarkeit: Sie loggen sich ein, sie tauchen in Organigrammen auf, sie verlassen das Unternehmen irgendwann wieder.
Maschinenkonten ticken anders. Microsoft weist darauf hin, dass Non-Human Identities keine MFA machen können, oft keinen formalen Lifecycle haben und trotzdem ihre Zugangsdaten oder Secrets irgendwo speichern müssen. Diese Kombi macht sie schwerer zu verwalten und anfälliger für Kompromittierung.
Die größte Gefahr ist nicht, dass es NHIs gibt. Die braucht moderne IT nun mal. Die größte Gefahr ist, dass niemand so richtig weiß:
Und dann passiert das Typische: Einmal eingerichtet – und nie wieder angefasst.
OWASP benennt folgende Muster als Kernrisiken: unsaubere Abschaltung alter NHIs, geleakte Secrets, verwundbare Drittanbieter-Identitäten und schwache Authentifizierung.
Weil sich moderne IT vervielfacht hat.
Cloud, SaaS, Container, APIs, DevOps, Automatisierung und KI-Agenten sorgen dafür, dass die Zahl nicht-menschlicher Identitäten explodiert. Jede Integration braucht Zugriff. Jeder Workflow braucht Rechte. Jedes Tool benötigt Zugriff. Und jedes Mal entsteht potenziell ein weiterer digitaler Mitarbeiter ohne Gesicht, aber mit Schlüsselbund.
Das sieht man sehr gut an aktuellen Sicherheitsbeobachtungen. In der Analyse zum Trivy-Supply-Chain-Angriff wird beschrieben, dass viele Organisationen gar nicht genug Telemetrie haben, um den Impact sauber einzugrenzen – und schon gar nicht, um schnell zu erkennen, welche Secrets rotiert werden müssen.
Besonders problematisch: Open-Source-Komponenten landen auf Entwicklergeräten, in Pipelines, in Staging und Produktion, oft mit zu wenig Transparenz. Als Gegenmaßnahmen nennt die Analyse unter anderem JIT für Human und Non-Human Identities, klare Secret-Rotation-Prozesse und den Verzicht auf hart codierte Keys.
In dem Moment wird aus einem „Technikdetail“ plötzlich ein Management-Thema. Denn wenn dein Unternehmen nicht nachvollziehen kann, welche Maschinenidentität wo welche Rechte hat, wird es extrem schwierig, Vorfälle sauber einzugrenzen und gezielt zu reagieren.
Ein klassischer Fall: Für eine Schnittstelle wird ein Service Account angelegt. Weil es schnell gehen muss, bekommt das Konto lieber etwas mehr Rechte als zu wenig. Nur zur Sicherheit.
Später wird die Anwendung ersetzt, die Integration umgebaut oder der Dienstleister gewechselt. Das Konto bleibt aber aktiv. Niemand fühlt sich zuständig. Es steht in keiner sauberen Doku. Es hat weiterhin Zugriff auf Dateien, Datenbanken oder Admin-Funktionen.
OWASP nennt „unsauberes Offboarding“ ausdrücklich als Top-Risiko: Nicht deaktivierte oder verwaiste NHIs können von Angreifern ausgenutzt werden, um auf sensible Systeme und Daten zuzugreifen.
Ein API-Key in einer Config-Datei. Ein Token in einer Pipeline. Ein Secret in einem Chat. Ein Zertifikat, das seit zwei Jahren niemand mehr angefasst hat. Funktioniert ja noch.
Auch das gehört zu den häufigsten Problemen. OWASP listet Secret Leakage als eines der zentralen NHI-Risiken, etwa wenn Schlüssel oder Tokens in Code, Klartext-Konfigurationen oder unsanktionierten Speichern landen.
Besonders unschön wird das bei Lieferkettenangriffen: Die Trivy-Analyse beschreibt, wie moderne Angriffe Secrets abziehen, verschlüsselt exfiltrieren und möglichst unauffällig agieren. Wer dann keine Übersicht über Token-Beziehungen und Berechtigungen hat, steht beim Rotieren und Eingrenzen schnell vor dem digitalen Wimmelbild.
Spätestens mit agentischen KI-Systemen bekommt das Thema eine neue Flughöhe. Denn sobald KI nicht nur antwortet, sondern Tools nutzt, Daten liest, E-Mails verschickt, Datensätze löscht oder Deployments anstößt, reden wir im Kern ebenfalls über Non-Human Identities plus Berechtigungen.
Die AgentSeal-Analyse benennt es deutlich: Bei 5.125 gescannten MCP-Servern wurden 53.533 Security Findings gefunden; 555 Server wiesen sogenannte „toxic data flows“ auf – also gefährliche Tool-Kombinationen, bei denen zum Beispiel private Daten gelesen und anschließend exfiltriert werden können.
Mit mehr Tools steigt das Risiko quadratisch, weil die Zahl möglicher gefährlicher Tool-Paare explodiert.
Das ist ein Beispiel dafür, was passiert, wenn Identitäten, Rechte und Tool-Zugriffe schneller wachsen als Governance.
Was hilft also?
Nicht die große PowerPoint mit „Zero Trust“ auf Folie 3 und einem Schloss-Icon auf Folie 4. Sondern solide Grundlagen.
Du brauchst ein belastbares Verzeichnis deiner NHIs:
Welche gibt es? Wem gehören sie? Wofür sind sie da? Welche Rechte haben sie? Wo liegen ihre Secrets?
Jede Non-Human Identity braucht einen menschlichen Owner. Ja, Ironie des Schicksals. Aber irgendwer muss verantwortlich sein.
Least Privilege gilt nicht nur für Menschen. Gerade Maschinenkonten bekommen aus Bequemlichkeit oft viel zu viele Rechte.
Wo möglich: kurzlebige Credentials, automatische Rotation, zentrale Secret-Verwaltung. Die Trivy-Analyse empfiehlt explizit klare Rotation-Prozesse und externe Secrets Manager statt hart codierter Schlüssel.
Nicht nur Mitarbeitende verlassen Systeme. Auch Integrationen, Tools, Projekte und Workloads tun das. Und deren Identitäten müssen mitgehen – nämlich raus.
Wenn Entwicklergeräte, Pipelines und Cloud-Workloads blinde Flecken bleiben, erkennst du Angriffe zu spät oder gar nicht.
Für moderne Workloads sind Identitätsmodelle mit Attestation und kurzlebigen Credentials deutlich robuster als statische Zugangsdaten.
Ich fand den Gedanken aus einem anderen aktuellen Security-Thema ganz passend: Google führt mit „Advanced Flow“ für APK-Sideloading bewusst zusätzliche Sicherheitsbarrieren ein, obwohl Power User mehr Freiheit wollen. Die Lektion: Mehr Flexibilität braucht mehr Leitplanken, nicht weniger.
Das gilt in der Unternehmens-IT ganz genauso. Je mehr Automatisierung, KI, Cloud-Integrationen und Services du zulässt, desto klarer müssen Identitäten, Rechte und Schutzmechanismen geregelt sein.
Non-Human Identities sind kein exotisches Security-Spezialthema. Sie sind Kerngeschäft moderner IT und dürfen darum kein blinder Fleck bleiben.
Wenn du heute nur auf menschliche Benutzer schaust, sicherst du nur die halbe Wahrheit. Die andere Hälfte läuft im Hintergrund – ohne Bildschirm, ohne Schulung, ohne Bauchgefühl. Aber mit weitreichenden Berechtigungen.
In Cloud-Umgebungen gilt deshalb mehr denn je: Sicherheit muss einfach handhabbar sein, sauber strukturiert und persönlich verantwortet.
Weil moderne IT sonst irgendwann von Identitäten gesteuert wird, die zwar alles dürfen – aber bei keinem auf dem Zettel stehen.
Der gefährlichste Kollege in deiner IT ist vielleicht nicht der, der auf Phishing klickt. Sondern der, der seit 2019 still mit Adminrechten durch die Gegend läuft und offiziell gar niemandem mehr gehört.