Secrets Management vs. Non-Human Identity Governance: Wo Vaults aufhören

Ihr Vault läuft. Rotation ist konfiguriert. Die Audit-Logs fließen. Und trotzdem taucht beim nächsten Penetrationstest ein Service-Account auf, der seit 14 Monaten niemanden mehr gehört - mit vollen Produktionsrechten, ohne Ablaufdatum, ohne Owner.

Das ist kein Vault-Problem. Das ist ein Governance-Problem. Und die Verwechslung dieser beiden Kategorien ist einer der teuersten Denkfehler in der modernen Identity-Security-Architektur.

Alle Identitäten in einer Ansicht

Kurz gezeigt: Wie menschliche und nicht-menschliche Identitäten in einer einzigen Governance-Ansicht zusammenlaufen statt in drei getrennten Systemen.

Was ein Vault wirklich tut - und was nicht

Secrets Manager wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault lösen ein klar umrissenes Problem: Sie speichern Credentials verschlüsselt, versionieren sie, und ermöglichen automatisierte Rotation. Das ist wertvoll. Aber es ist nicht Governance.

Vaulting secrets ist wichtig - aber es ist keine Governance. Das Speichern von Credentials in einem Secrets Manager schützt sie vor Plaintext-Exposition. Es verfolgt jedoch nicht, ob sie noch in Verwendung sind. Es verknüpft sie nicht mit einem konkreten Owner. Es lässt sie nicht ablaufen, rotiert sie nicht automatisch, und es widerruft keinen Zugriff, wenn der zugehörige Service deprecated wird. Kurz: Es verwaltet und regiert nicht den gesamten Lifecycle.

Ein Vault beantwortet die Frage: Wo liegt das Secret? Er beantwortet nicht: Wer ist dafür verantwortlich? Wird es noch gebraucht? Ist der Zugriff noch angemessen? Was passiert, wenn der Entwickler, der es angelegt hat, das Unternehmen verlässt?

Das Skalierungsproblem, das Vaults nicht lösen können

Das eigentliche Ausmaß des Problems wird erst klar, wenn man die Zahlen betrachtet. Non-Human Identities übersteigen menschliche Identitäten laut Entro Security H1 2025 Research in einem Verhältnis von 144:1 in Cloud-nativen Umgebungen - ein Anstieg von 92:1 im Vorjahr. Über alle Enterprise-Umgebungen hinweg liegt das Verhältnis im Durchschnitt bei etwa 45:1.

Allein im vergangenen Jahr sind NHIs um 44 % gewachsen. Sie übersteigen menschliche Identitäten nun im Verhältnis 144:1 - ein deutlicher Sprung gegenüber dem 92:1-Verhältnis aus H1 2024. Diese Machine-Identities - Service-Accounts, Tokens, API-Keys - sind das operative Rückgrat moderner Infrastruktur. Ihr Wachstum überholt jedoch häufig die Oversight.

Für ein Unternehmen mit 1.000 Mitarbeitern bedeutet das rechnerisch rund 144.000 Machine-Credentials, die verwaltet werden müssen. Kein manueller Prozess, kein Vault allein, kann diese Last tragen.

Non-Human Identities persistieren über Pipelines, Workloads, Integrationen und Umgebungen hinweg - deshalb werden Service-Ownership, Secret-Rotation und Offboarding zu den eigentlichen Kontrollpunkten. Dieser Unterschied ist entscheidend, weil Machine-Identities oft multipliziert, in Code versteckt und lange nach ihrem ursprünglichen Zweck aktiv bleiben.

Genau hier beginnt die Governance-Lücke.

Die fünf Fragen, die ein Vault nicht beantworten kann

Stellen Sie sich vor, Ihr Security-Audit fragt nach dem Zugriffsstatus eines bestimmten CI/CD-Service-Accounts. Ein Vault sagt Ihnen, dass das Secret existiert und wann es zuletzt rotiert wurde. Er sagt Ihnen nicht:

1. Wem gehört diese Identität? Ownership ist eine Governance-Funktion, keine Storage-Funktion.
2. Wird sie noch aktiv genutzt? Vaults tracken Issuance, nicht Usage-Kontext.
3. Ist der Zugriff noch angemessen? Least-Privilege-Überprüfung erfordert Policy-Enforcement, nicht nur Verschlüsselung.
4. Was passiert beim Offboarding? 91 % der Tokens ehemaliger Mitarbeiter bleiben nach dem Offboarding aktiv - das zeigt die 2025 State of NHIs and Secrets in Cybersecurity Research von Astrix Security & CSA.
5. Wann muss diese Identität dekommissioniert werden? NHIs skalieren schneller als menschliche Identitäten und überleben oft weit über das Business-Event hinaus, das sie erzeugt hat. Nur 20 % der Organisationen haben formale Offboarding- und Revocation-Prozesse für API-Keys, während 71 % der NHIs nicht innerhalb empfohlener Zeitrahmen rotiert werden.

Fragmentierte Secrets-Estates verwandeln Access-Reviews in eine Beweissammlungsübung. Wenn Vault-Cluster, Cloud-Secret-Manager und Audit-Logs separat verwaltet werden, hat die Organisation keine einheitliche Antwort mehr auf die Frage, wer wann auf was zugegriffen hat. Das ist nicht nur eine operative Last - es ist ein Governance-Versagen, das die Accountability über NHI- und Platform-Zugriff untergräbt.

Secrets Management vs. NHI Governance: Die ehrliche Gegenüberstellung

Wo Vaults enden - und warum das strukturell ist

Secrets sind nur ein Teil der Non-Human Identity Governance. API-Keys, Zertifikate, Tokens und Service-Credentials benötigen weiterhin Ownership, Lifecycle-Kontrolle und kontinuierliche Überprüfung.

Das ist keine Kritik an Vault-Produkten. HashiCorp Vault, AWS Secrets Manager und ihre Alternativen tun genau das, wofür sie gebaut wurden. Das Problem entsteht, wenn Teams sie als vollständige NHI-Governance-Lösung behandeln - und dabei die Kontrollschicht darüber vergessen.

NHI Governance ist die Gesamtheit der Policies und Controls, die Non-Human Identities über ihren gesamten Lifecycle hinweg verwalten. Sie umfasst Issuance, Access-Scope, Monitoring, Rotation und Retirement - damit Machine-Credentials keine versteckten, dauerhaften Angriffspfade werden. NHI Governance ist breiter als Inventory-Management oder Secret-Rotation. Sie definiert, wer eine NHI erstellen darf, wie sie klassifiziert wird, was sie erreichen kann, wie oft ihr Zugriff überprüft wird und wann sie dekommissioniert werden muss.

Laut GitGuardian State of Secrets Sprawl 2026 wurden allein 2025 über 28,65 Millionen hardcodierte Secrets in öffentliche GitHub-Repositories eingecheckt - ein Anstieg von 34 % gegenüber dem Vorjahr. Nur 5,7 % der Organisationen haben vollständige Sichtbarkeit über ihre Service-Accounts. 96 % der Organisationen speichern Secrets außerhalb von Secrets Managern an vulnerablen Orten - in Code, Config-Dateien und CI/CD-Tools.

Das zeigt: Vaults lösen das Problem nur für den Teil der Credentials, der tatsächlich im Vault landet. Der Rest - und das ist strukturell der größere Teil - bleibt ungoverned.

Die Governance-Schicht, die über dem Vault sitzt

NHI Governance ist keine Konkurrenz zum Vault. Sie ist die Schicht darüber. Ein reifes Modell sieht so aus:

Policy-basierter Zugriff funktioniert nur, wenn er an kontinuierliche Identity-Reviews gebunden ist. RBAC und JIT reduzieren die Exposition, helfen aber nicht, wenn Zugriff nie überprüft oder die zugrundeliegende NHI nie dekommissioniert wird. Das Feld muss NHI Governance als Lifecycle-Disziplin behandeln, bei der Zugriff, Ownership und Ablauf zusammengebunden sind.

Human + Non-Human: Warum getrennte Silos das Problem verschärfen

Der häufigste Architektur-Fehler: Ein Team betreibt ein IGA-Tool für menschliche Identitäten und einen Vault für Machine-Credentials - und behandelt beides als separate Welten. Das Ergebnis sind zwei Governance-Silos, die sich gegenseitig blind machen.

IAM fokussiert auf die Kontrolle des Zugriffs auf Systeme, während IGA Governance und Compliance-Oversight hinzufügt. Non-Human Identity Management erweitert beides, indem es Sichtbarkeit und Kontrolle auf maschinenbasierte Identitäten ausdehnt.

Ein AI-Agent, der Tickets öffnet und interne APIs aufruft, ist eine Identität - genau wie der Entwickler, der ihn deployed hat. 70 % der Organisationen gewähren KI-Systemen mehr Zugriff, als sie einem menschlichen Mitarbeiter in derselben Funktion geben würden. Nur 44 % der Organisationen haben überhaupt Policies implementiert, um ihre AI-Agents zu verwalten - obwohl 92 % zustimmen, dass die Governance von AI-Agents kritisch für die Enterprise-Security ist.

Die einzig haltbare Antwort ist eine Governance-Plattform, die Human und Non-Human Identities als zwei Populationen desselben Problems behandelt: Wer hat Zugriff auf was, ist dieser Zugriff noch angemessen, und was passiert, wenn er endet?

Was das für Security-Architekten bedeutet

Wenn Sie gerade Ihre NHI-Strategie aufbauen oder überprüfen, sind das die praktischen Konsequenzen:

• Vaults sind notwendig, aber nicht hinreichend. Betreiben Sie weiterhin Ihren Vault - aber ergänzen Sie ihn um eine Governance-Schicht, die Ownership, Lifecycle und Policy-Enforcement abdeckt.
• Inventory zuerst. Identity Sprawl wird zu Governance-Schulden, nicht nur zu einem Inventory-Problem. Sobald Machine-Identities menschliche Nutzer um Größenordnungen übersteigen, verlagert sich die Herausforderung vom Zählen von Assets hin zum Nachweisen von Ownership, Purpose und Revocation.
• Unified Governance schlägt Best-of-Breed-Silos. Zwei getrennte Tools für Human und Non-Human Identities erzeugen Coverage-Gaps, die Angreifer ausnutzen - nicht durch Vault-Schwächen, sondern durch das Fehlen jeglicher Governance über eine Klasse von Identitäten, die niemand besitzt.
• Lifecycle-Disziplin ist kein Nice-to-have. 47 % der NHIs sind älter als ein Jahr ohne Credential-Rotation, laut aktuellen Branchendaten. Das ist kein Konfigurationsproblem - es ist ein Governance-Versagen.

Wie Iden die Lücke schließt

Iden ist als IGA-Plattform gebaut, die genau dort ansetzt, wo Vaults aufhören: auf der Governance-Ebene über dem gesamten Stack - für Human und Non-Human Identities gleichermaßen.

Das bedeutet in der Praxis:

• Universal App Coverage - Iden verbindet sich mit jeder App in Ihrem Stack, ob sie SCIM, APIs oder keines von beidem unterstützt. Kein Enterprise-Upgrade erforderlich, um kritische Apps zu automatisieren.
• Fine-grained Control - Zugriffskontrolle tiefer als SCIM: auf Channel-, Repository- und Projekt-Ebene. Für NHIs bedeutet das Scope-Begrenzung auf Workload-Ebene, nicht nur auf Rollen-Ebene.
• Vollständiger Lifecycle - Onboarding, Changes und Offboarding werden policy-gesteuert automatisiert - für Service-Accounts und AI-Agents genauso wie für menschliche Nutzer.
• Kein SCIM-Tax - Keine versteckten Kosten für Enterprise-Tiers, nur um Governance-Automation für Ihre wichtigsten Apps zu aktivieren.
• Fast Time-to-Value - Live in ~24 Stunden, nicht in Monaten. Gebaut für schlanke IT-Teams, die keine dedizierte IAM-Funktion betreiben.

Der entscheidende Unterschied: Iden behandelt Human und Non-Human Identities nicht als separate Probleme mit separaten Tools. Es ist eine einheitliche Governance-Ebene - mit einem Audit-Trail, einer Policy-Engine, einem Lifecycle-Modell.

Das Takeaway

Ein Vault ist kein Ersatz für Governance - er ist eine Voraussetzung dafür. Er schützt das Secret. Governance regiert die Identität dahinter: wer sie besitzt, was sie darf, wie lange sie existiert und was passiert, wenn sie nicht mehr gebraucht wird.

Non-Human Identities übersteigen menschliche Identitäten um das 50-fache, und Rotation, Revocation und Lifecycle-Kontrolle erfordern vollständige kontextuelle Sichtbarkeit. Das Kernproblem ist nicht nur Secret Sprawl, sondern die Governance-Lücke, die entsteht, wenn Identity-Lifecycles menschenzentrierte Zugriffsmodelle überwachsen.

Security-Architekten, die heute eine NHI-Strategie aufbauen, brauchen beides: den Vault als sicheren Speicher und eine Governance-Plattform als Kontrollschicht darüber. Wer nur eines davon hat, hat eine Lücke - und Lücken werden gefunden.