Ihr SIEM beobachtet die Eingangstür. Angreifer kommen durch den Lieferanteneingang.
Nahezu jedes reife Security-Team hat MFA, SSO und Log-Aggregation im Einsatz. Die meisten investieren zusätzlich in Endpoint Detection, Threat Intelligence und mindestens vierteljährliche Access-Reviews. Und trotzdem folgt ein Vorfall nach dem anderen in 2024 und 2025 demselben Muster: Die Angreifer haben kein Passwort geknackt. Sie haben ein Credential missbraucht, für das es nie eine Passwort-Policy gab.
Service-Accounts. API-Keys. OAuth-Tokens. CI/CD-Pipeline-Credentials. Bot-Accounts.
Das sind nicht-menschliche Identitäten (NHIs) - die eigentliche "Belegschaft", die Ihre Automatisierung betreibt, Ihre SaaS-Tools verbindet und Ihre Pipelines am Laufen hält. In den meisten Unternehmen sind sie unreguliert, für Ihr SIEM unsichtbar und sammeln sich unbemerkt an.
Service-Accounts sind die häufigste Form nicht-menschlicher Identitäten in Unternehmensinfrastrukturen. Jede CI/CD-Pipeline, jeder Microservice und nahezu jede SaaS-Integration braucht einen - und in vielen Organisationen übertreffen sie die Zahl der menschlichen User um eine Größenordnung. Das ist kein exotischer Sonderfall. Es ist die dominante Form Ihrer Identity-Landschaft, und die meisten Governance-Programme behandeln sie als Nebenschauplatz.
Das Ausmaß des Problems, das niemand wirklich misst
Die meisten CISOs kennen ihre Mitarbeiterzahl. Sehr wenige kennen ihre NHI-Zahl.
Die CyberArk Identity Security Landscape 2025 fand 82 Maschinenidentitäten pro Mensch - 42 % davon mit privilegierten Zugriffsrechten. In einem Unternehmen mit 500 Mitarbeitenden bedeutet das potenziell zehntausende Service-Accounts, API-Keys, OAuth-Tokens und Bot-Credentials - meist still und leise erstellt von Entwickler:innen, Operations-Teams oder SaaS-Onboarding-Flows - und fast nie mit derselben Sorgfalt geregelt wie ein klassischer Mitarbeiter-Account.
Unternehmen investieren massiv in die Absicherung von Mitarbeiter-Accounts mit MFA, Zero Trust und regelmäßigen Access-Reviews. Parallel dazu werden Service-Accounts mit statischen Credentials erstellt, mit weitreichenden Berechtigungen ausgestattet und anschließend sich selbst überlassen - eine wachsende Population von Identitäten außerhalb klassischer IAM-Kontrollen.
Schon das reine Inventar-Problem ist gravierend. Das eigentliche Risiko entsteht aber dort, wo diese Identitäten niemand im Blick hat.
- Eine Entwickler:in geht. Ihre persönlichen API-Keys für GitHub, Snowflake und interne Tools bleiben aktiv.
- Ein Projekt endet. Der CI/CD-Service-Account mit Deploy-Zugriff auf Produktion existiert weiter - auf unbestimmte Zeit.
- Eine SaaS-Integration wird ersetzt. Das damals erstellte OAuth-Token wird nie widerrufen.
- Ein Bot-Account, vor zwei Jahren für eine Kampagne angelegt, hat weiterhin Schreibzugriff auf Ihr CRM.
Service-Account-Credentials sind häufig im Anwendungscode hardcodiert und landen in Version Control, werden in Container-Images eingebettet oder als langlebige Tokens in CI/CD-Pipelines gespeichert. Der GitGuardian-Report 2026 meldete rund 29 Millionen entdeckte Secrets auf öffentlichem GitHub im Jahr 2025.
Das ist nicht nur ein isoliertes Geheimnisverwaltungsproblem. Es ist ein Governance-Versagen - Identitäten werden ohne Lifecycle-Policies erstellt, ohne kontinuierliche Aufsicht "reviewt" und, falls überhaupt, nur dann deprovisioniert, wenn jemand zufällig die richtige Frage stellt.
Warum Ihr SIEM das meiste davon verpasst
SIEM-Tools sind für Log-Korrelation gebaut. Sie sammeln Events aus Systemen mit strukturierten Logs, suchen nach Anomalien gegenüber bekannten Baselines und schlagen Alarm, wenn etwas abweicht.
Das Problem bei NHIs: gestohlene Credentials sehen nicht anormal aus.
Statt Benutzer-Credentials zu kompromittieren, nutzen Angreifer gültige OAuth-Tokens und authentifizieren sich direkt in SaaS-Umgebungen - sie umgehen MFA und schleusen Daten über Tage hinweg unauffällig ab. Weil die Aktivität von einer zugelassenen Integration mit gültigen Tokens ausgeht, geht sie im normalen SaaS-zu-SaaS-Traffic unter und umgeht klassische Sicherheitskontrollen.
Der Salesloft/Drift-Vorfall 2025 ist das deutlichste Beispiel. Der Angreifer nutzte gestohlene OAuth-Tokens aus der Salesloft-Drift-App, um auf Salesforce-Organisationen zuzugreifen, Daten zu exportieren und nach hochkritischen Secrets wie AWS-Keys und Snowflake-Tokens zu suchen. Ein Musterfall für den Missbrauch nicht-menschlicher Identitäten - klassische Kontrollen wie MFA wurden vollständig umgangen.
Ihr SIEM sah: eine bekannte Integration, die sich ganz normal authentifiziert. Die Realität: systematische Datenexfiltration.
Diese Lücke lässt sich nicht durch ein weiteres Finetuning von SIEM-Regeln schließen. SaaS-Sprawl sorgt für eine Explosion von OAuth-Tokens, API-Keys und App-Verbindungen - jede Integration bringt eine nicht-menschliche Identität mit, die in der Regel für IT unsichtbar ist und nicht im traditionellen Identity-Management auftaucht. Das Ergebnis: eine unregulierte Angriffsfläche.
Detection ohne Governance ist höchstens reaktiv. Sie können kein "Normalverhalten" für eine Identität baselinen, von der Sie nicht einmal wissen, dass es sie gibt.
| NHI-Typ | Entstehungsweg | SIEM-Sichtbarkeit | Typisches Risiko | Lebenszyklus-Governance erforderlich |
|---|---|---|---|---|
| Servicekonten | IT/DevOps-Bereitstellung | Teilweise (falls Log-Ingestion konfiguriert ist) | Überprivilegierte, statische Anmeldeinformationen, selten rotiert | ✅ Ja |
| API-Schlüssel | Entwickler, oft ad hoc | ⚠️ Begrenzt (nur Nutzungsprotokolle) | Hardcodierte Anmeldeinformationen in Repositories, lange gültig, kein Ablaufdatum | ✅ Ja |
| OAuth-Tokens | Vom Benutzer autorisierte App-Integrationen | ❌ Selten (umgeht MFA-Logging) | Gestohlene Tokens umgehen MFA und verschmelzen mit legitimen Traffic | ✅ Ja |
| CI/CD-Pipeline-Anmeldeinformationen | DevOps/Automation | ⚠️ Minimal (Pipeline-Protokolle fragmentiert) | Verwechslungsangriffe (confused deputy), Zugriff auf Deploy in die Produktion | ✅ Ja |
| Bot/RPA-Konten | Betriebs-/Automatisierungsteams | ⚠️ Teilweise (abhängig vom Tool) | Nach Projektende verwaist, behält erhöhten Zugriff | ✅ Ja |
| Gemeinsame Administratorenkonten | Veraltete IT-Praxis | ⚠️ Schlecht (keine individuelle Zuordnung) | Keine Nachverfolgbarkeit, Ermöglicht Lateralbewegung | ✅ Ja |
Das wahre Breach-Muster: Es beginnt fast immer mit einem statischen Credential
Wer sich die Vorfälle der letzten 18 Monate ansieht, erkennt ein Muster. Der Einstiegspunkt ist selten eine Zero-Day-Schwachstelle. Fast immer ist es ein schlecht verwaltetes, nicht-menschliches Credential.
Beim New York Times-Vorfall nutzten Angreifer ein überprivilegiertes GitHub-Token, das Zugriff auf alle Repositories gewährte, um den Source Code zu exfiltrieren.
Im Cloudflare/Okta-Zwischenfall rotierte Cloudflare zwar 5.000 Credentials, doch ein nicht rotiertes Token und Service-Account-Credentials reichten, um die Atlassian-Umgebung zu kompromittieren.
Die Cloudflare-Lektion: Nach der Okta-Panne von 2023 hat Cloudflare ungefähr 5.000 Anmeldeinformationen rotiert. Aber ein unrotiertes API-Token und eine Reihe von Dienstkonto-Anmeldeinformationen reichten aus, damit Angreifer die gesamte Atlassian-Umgebung von Cloudflare kompromittieren konnten – Bitbucket, Jira und Confluence. Eine vergessene nicht-menschliche Identität rückte eine ansonsten gründliche Vorfallreaktion zunichte.
85 % der Breaches zwischen Januar und Juli 2024 betrafen kompromittierte Service-Accounts - ein signifikanter Anstieg gegenüber 71 % im gleichen Zeitraum 2023.
Das Muster ist stabil: Service-Accounts sind eine direkte Abkürzung zur Dominanz in der Domäne. Angreifer nutzen sie für laterale Bewegung, Privilege Escalation und den Zugriff auf sensitive Systeme - ganz ohne Malware. Überprivilegierte, kaum verwaltete Service-Accounts gehören zu den meistgenutzten und gleichzeitig am stärksten unterschätzten Angriffsvektoren.
Der unangenehmste Teil: Im Gegensatz zu menschlichen Accounts mit MFA und Lockout-Policies arbeiten Service-Accounts praktisch immer mit statischen Tokens ohne zusätzlichen Verifizierungsschritt. Ein gestohlenes Credential funktioniert unabhängig davon, wo, wann oder wie es verwendet wird.
Kein zweiter Faktor, der umgangen werden muss. Kein Lockout, der anspringt. Das SIEM sieht ein gültiges Token. Der Angreifer hat alles, was er braucht.
Warum nicht-menschliche Identitäten denselben Lifecycle brauchen wie Menschen
Die Branche hat 20 Jahre damit verbracht, Joiner-Mover-Leaver-(JML)-Prozesse für Mitarbeitende aufzubauen. Onboarding triggert Provisionierung. Rollenwechsel triggern Access-Updates. Offboarding triggert Revocation. Nicht perfekt, aber immerhin ein etabliertes Modell.
Für nicht-menschliche Identitäten gibt es kein vergleichbares Muster. Sie werden mit sehr breiten Berechtigungen erstellt - ihr Default-Lifecycle lautet: erstellt, genutzt, vergessen.
So sieht saubere NHI-Governance aus - im Vergleich zu dem, was in den meisten Unternehmen tatsächlich passiert:
| Lifecycle-Phase | Menschliche Identität (typisch) | Nicht-menschliche Identität (typisch) |
|---|---|---|
| Creation | Provisioniert per HRIS-Trigger | Ad hoc von Developer oder DevOps erstellt |
| Ownership | An Mitarbeiterakte gebunden | Oft niemandem eindeutig zugewiesen oder geteilt |
| Access Scope | Rollenbasiert, regelmäßig geprüft | Standardmäßig breit, selten geprüft |
| Rotation | Passwort-Policies erzwungen | Statische Credentials, Monate oder Jahre alt |
| Offboarding | Deprovisionierung beim Austritt | Bleibt bestehen, bis es jemand bemerkt |
| Audit-Trail | SSO-Logs, HR-Daten | Zersplittert über Apps und Vaults |
Anders als menschliche Identitäten - typischerweise zentral über einen Identity Provider gesteuert - sind NHIs von Natur aus dezentral. Sie werden dynamisch über Plattformen hinweg erzeugt, per Infrastructure-as-Code provisioniert und häufig von Entwickler:innen, DevOps-Teams oder sogar autonomen Systemen angelegt. Diese Vermehrung macht sie schwer zu erfassen, noch schwerer zu steuern und ohne die richtigen Controls nahezu unmöglich abzusichern.
Die Lösung ist nicht ein weiteres Spezialtool nur für NHIs. Das erzeugt lediglich ein weiteres Silo, ein weiteres Dashboard und einen weiteren Ort, an dem sich Abdeckungslücken verstecken. Die Lösung besteht darin, nicht-menschliche Identitäten in dasselbe Governance-Modell zu holen wie menschliche - mit denselben Lifecycle-Policies, denselben Access-Reviews und derselben Disziplin bei der Deprovisionierung.
Genau das leisten Identity-Governance-Programme, die für den modernen Stack gebaut sind: Jede authentifizierbare Entität - Mensch oder Maschine - wird als vollwertige, zu regierende Identität behandelt.
Wie vollständige NHI-Governance in der Praxis aussieht
Wenn Sie als CISO diese Lücke schließen wollen, ohne zusätzliches Headcount aufzubauen oder ein 12-monatiges Implementierungsprojekt loszutreten, brauchen Sie Folgendes - und genau das sollten Sie von jeder Governance-Plattform einfordern.
1. Vollständige Discovery über Ihren gesamten Stack
Sie können nichts regeln, was Sie nicht sehen. Eine Governance-Plattform muss NHIs über jede App in Ihrer Applikationslandschaft hinweg entdecken - nicht nur dort, wo SCIM-Konnektoren oder Enterprise-Plan-APIs existieren.
Die meisten "modernen IGA"-Tools hören bei SCIM-fähigen Apps auf. Ihr CI/CD-Tooling, interne Plattformen und Legacy-SaaS ohne Enterprise-Plan enthalten trotzdem Service-Accounts und API-Keys. Eine Governance-Lösung, die nur 30-40 % Ihres Stacks abdeckt, lässt den Großteil Ihrer NHI-Angriffsfläche unsichtbar.
Die universellen Konnektoren von Iden erreichen Applikationen unabhängig davon, ob sie SCIM unterstützen, APIs haben oder keines von beidem - so wird Discovery vollständig, nicht partiell.
2. Klare Ownership und Lifecycle-Policies
Jede NHI braucht eine:n Owner - ein Team, ein System, einen klaren Zweck. Ohne Ownership wird nichts regelmäßig geprüft, nichts rotiert und nichts deprovisioniert, wenn es nicht mehr benötigt wird.
Gute Governance-Plattformen verknüpfen NHIs mit ihren verantwortlichen menschlichen Identitäten (oder verantwortlichen Systemen), sodass beim Offboarding einer Person auch die zugehörigen Service-Accounts und API-Tokens im selben Sweep erfasst werden - statt als verwaiste Credentials im System zu verbleiben.
3. Kontinuierliche Access-Reviews statt periodischer Alibi-Prüfungen
Vierteljährliche Access-Reviews funktionieren für NHIs nicht. Ein Token kann kompromittiert, missbraucht und wieder aufgeräumt werden, bevor Ihr nächster Review-Zyklus überhaupt startet.
Der neue Standard heißt kontinuierliche Governance: Echtzeit-Sichtbarkeit darauf, worauf jede NHI zugreifen kann, automatisierte Alerts, wenn Zugriffe über den erwarteten Scope hinauswachsen, und Policy-gesteuerte Revocation, wenn eine NHI inaktiv wird oder sich ihr Kontext ändert.
Das ist die Abkehr von statischen Checks hin zu Echtzeit-Entscheidungen - das einzige Modell, das mit kontinuierlichen Angriffen Schritt hält.
4. Immutable Audit-Logs für jede Identität
Wenn ein Auditor fragt: "Wer hatte Zugriff auf die Produktionsdatenbank und seit wann?" - dann muss die Antwort auch Service-Accounts und API-Keys abdecken, nicht nur Mitarbeiter-Accounts.
Immutable Audit-Trails über alle Identitäten hinweg, mit klarer Herkunft eines jeden Access-Grants und jeder Revocation, machen aus einer Governance-Plattform ein Compliance-Asset. Ohne diese Transparenz für NHIs bleiben Ihre Nachweise für SOC 2 oder ISO 27001 lückenhaft.
5. Automatisierte Deprovisionierung - inklusive Long Tail
Der schwierigste Teil von NHI-Governance in großem Maßstab ist die Deprovisionierung. Die meisten Plattformen automatisieren Offboarding für SCIM-verbundene Apps. Ihre GitHub-Tokens, Notion-Integrationen und Figma-Bot-Accounts erfordern dagegen Konnektoren, die deutlich tiefer gehen als SCIM.
Automatisierte, Policy-gesteuerte Deprovisionierung, die jede App erreicht - nicht nur die 30 % mit SCIM-Support - beseitigt verwaiste Konten und Zombie-Credentials direkt an der Quelle.
Genau hier wird die Governance-Lücke bei Dienstleistern und Service-Accounts am sichtbarsten - jede Identität außerhalb des standardisierten, HRIS-getriggerten JML-Prozesses neigt dazu, sich anzusammeln und zu überdauern.
Sicherheitsimperativ statt reines Compliance-Thema
Oft wird NHI-Governance als Compliance-Pflicht verstanden - etwas, das man tut, weil SOC 2 oder ISO 27001 Access-Reviews verlangen. Dieses Framing unterschätzt das Risiko massiv.
Nahezu ein Drittel aller Sicherheitsvorfälle 2024 waren Identity-basierte Angriffe mit gültigen Accounts. Admin- und Service-Accounts - häufig mit breiten Berechtigungen, statischen Credentials und kaum eingeschränkten Logon-Rechten - gehören zu den mächtigsten Assets in Ihrem Netzwerk und gleichzeitig zu den am schwersten abzusichernden.
Sobald ein Angreifer einen einzigen überprivilegierten Service-Account kompromittiert, skaliert der Schaden schnell. Der Einstiegspunkt ist ein statisches Credential. Laterale Bewegung wird durch exzessive Berechtigungen erleichtert, die nie wirklich geprüft wurden. Die Dwell Time bleibt hoch, weil niemand das Normalverhalten dieser Identität sauber baselined.
Ihr SIEM kann dieses Problem nicht lösen. Tools für Geheimnisverwaltung verbessern die Rotation von Keys, liefern aber keine Governance. PAM-Lösungen sichern privilegierten Infrastrukturzugriff, sehen aber die SaaS-Ebene nicht. SSO schützt interaktive, menschliche Logins - nicht den Machine-to-Machine-Traffic darunter.
Die Lücke ist eine Governance-Lücke - und sie zu schließen bedeutet, nicht-menschliche Identitäten als First-Class-Citizens in Ihrem Identity-Security-Programm zu behandeln, inklusive Maschinenidentitätsschutz, API-Schlüssel-Sicherheit und konsequenter Verwaltung von Dienstkonten.
Zentrale Punkte für Security-Verantwortliche
- NHIs übertreffen menschliche Identitäten in Enterprise-Umgebungen um bis zu 82:1, doch die meisten Governance-Programme decken nur Mitarbeiter-Accounts ab.
- SIEM erkennt kompromittierte OAuth-Tokens oder API-Keys nicht zuverlässig, wenn sie als zugelassene, vertrauenswürdige Integrationen auftreten - Angreifer tarnen sich als legitimer Traffic.
- 85 % der Breaches im ersten Halbjahr 2024 betrafen kompromittierte Service-Accounts - das ist kein Zukunftsszenario, sondern Ihre aktuelle Angriffsfläche.
- Statische Credentials ohne Rotation, Ownership und Deprovisionierung sind heute der dominante Einstiegspunkt für laterale Bewegung und Datenexfiltration.
- Governance - nicht nur Detection - ist der Hebel: vollständige Discovery, eindeutige Ownership, kontinuierliche Reviews und automatisierte Deprovisionierung über Ihren gesamten Stack hinweg, inklusive Apps ohne SCIM oder APIs - genau dort, wo Verwaltung von Dienstkonten und Sicherheit von Dienstkonten heute oft endet.
- Ziel ist eine Governance-Schicht für alle Identitäten - menschlich und nicht-menschlich - statt separater Tools für jede Teilmenge des Problems.
Was ist der Unterschied zwischen einem Dienstkonto und einem API-Schlüssel?
Ein Dienstkonto ist eine Identität, die für eine Anwendung oder einen automatisierten Prozess erstellt wird, um sich gegenüber Systemen zu authentifizieren – denken Sie an einen Jira-Bot, der Ihr Ticketsystem liest, oder einen Überwachungsagenten, der sich in eine Datenbank einloggt. Ein API-Schlüssel ist eine statische Anmeldeinformation (in der Regel eine lange alphanumerische Zeichenfolge), die programmgesteuerten Zugriff auf die Schnittstelle einer Anwendung gewährt. Beide sind nicht-menschliche Identitäten (NHIs), beide tragen Zugriffsrechte, und standardmäßig ist keine MFA dafür aktiviert. Der entscheidende Unterschied: API-Schlüssel werden von Entwicklern oft ad hoc erstellt, im Code hardkodiert und vergessen – wodurch sie eine besonders diffuse Angriffsfläche darstellen.
Warum kann mein SIEM kompromittierte OAuth-Tokens oder API-Schlüssel nicht erkennen?
Ihr SIEM erfasst Protokolle von Systemen, mit denen es verbunden ist. OAuth-Tokens und API-Schlüssel authentifizieren oft als vertrauenswürdige Integrationen - was bedeutet, dass der Traffic für die Apps, die die Protokolle erzeugen, legitim aussieht. Wenn ein Angreifer ein gestohlenes OAuth-Token erneut abspielt, wirkt die Aktivität so, als stamme sie von einer bekannten, genehmigten App. Ihr SIEM sieht ein gültiges Authentifizierungsereignis, keine Anomalie. Ohne eine Governance-Schicht, die welche NHIs existieren, worauf sie zugreifen sollten und was für sie normal ist, gibt es keine Grundlage, um Alarm zu schlagen.
Wie viele nicht-menschliche Identitäten hat ein typisches mittelständisches Unternehmen?
Mehr, als die meisten Sicherheitsteams realisieren. Branchenforschung deutet darauf hin, dass Maschinenidentitäten Menschen deutlich übertreffen – CyberArk's 2025 Identity Security Landscape fand 82 Maschinenidentitäten pro Mensch, wobei 42% privilegierten Zugriff besitzen. Selbst in einem SaaS-intensiven Unternehmen mit 500 Mitarbeitenden können Sie leicht Tausende von API-Schlüsseln, OAuth-Tokens, Dienstkonten und CI/CD-Pipeline-Zugangsdaten über Ihren Stack hinweg ansammeln – die meisten davon nicht verwaltet.
Was ist Maschinidentitätssicherheit und wie unterscheidet sie sich von IAM?
Traditionelles IAM (Identitäts- und Zugriffsmanagement) konzentriert sich auf menschliche Benutzer – wer meldet sich an, mit welchen Anmeldeinformationen, in welche Systeme. Maschinidentitätssicherheit erweitert die Governance auf nicht-menschliche Identitäten: Dienstkonten, API-Schlüssel, OAuth-Tokens, Zertifikate und Bot-Konten. Es stellt dieselben Fragen (wer hat Zugriff, auf welche Ressourcen, seit wann, ist es noch nötig?), aber für Anmeldeinformationen, die sich nie interaktiv anmelden, MFA nicht verwenden können und oft Monate oder Jahre über ihren ursprünglichen Zweck hinaus bestehen.
Verwaltet Iden nicht-menschliche Identitäten wie Dienstkonten und API-Schlüssel?
Ja. Iden behandelt alle Identitäten - menschliche und nicht-menschliche - als gleichberechtigte Bürger in derselben Governance-Plattform. Dienstkonten, API-Schlüssel, Bot-Konten und OAuth-Integrationen sind auffindbar, mit denselben Lebenszyklusrichtlinien wie Mitarbeiterkonten verwaltet und in Zugriffsüberprüfungen und Audit-Logs eingeschlossen. Es bedarf keines separaten Dashboards oder Tools. Wichtig ist, dass Idens universelle Konnektoren Apps mit und ohne SCIM oder APIs erreichen – Governance ist daher nicht auf einen kleinen Teil Ihres Stack beschränkt.
