Illustration Absmeier foto ki designer

Service Accounts, API-Schlüssel, Cloud-Workloads und KI-Agenten handeln längst in einer Größenordnung, die klassische IAM-Prozesse überfordert. Die Studie »2026 Identity Security Landscape« beschreibt eine Identitätswelt, in der Maschinen menschliche Nutzer zahlenmäßig weit übertreffen und fragmentierte Kontrollen die Reaktion auf Vorfälle verlangsamen. Der Praxisleitfaden zeigt, wie Unternehmen in 90 Tagen Transparenz schaffen, Verantwortlichkeiten festlegen, langlebige Secrets abbauen und Zugriffe konsequent am tatsächlichen Geschäftsbedarf ausrichten.

Management Summary

Maschinenidentitäten werden zur dominierenden Identitätsklasse: Laut Palo Alto Networks kommen 2026 im Durchschnitt 109 Maschinenidentitäten auf eine menschliche Identität; die Zahl der KI-Agenten soll binnen eines Jahres um 85 Prozent wachsen.[1]
Governance hält mit dem Wachstum nicht Schritt: 88 Prozent der befragten Organisationen sichern vor allem menschliche Identitäten. Die Cloud Security Alliance berichtet zusätzlich von Defiziten bei Richtlinien, Inventarisierung und Ownership für KI-Identitäten.[1][6]
Der größte Hebel ist Transparenz: Ein vollständiges Inventar mit Geschäftszweck, Owner, Berechtigungen, Zielsystemen und Ablaufdatum bildet die Grundlage für Lifecycle-Management und priorisierte Risikoreduktion.
Statische Zugangsdaten und dauerhafte Privilegien erhöhen den Aktionsradius: Verwaltete Workload-Identitäten, kurzlebige Credentials, Just-in-Time-Zugriffe und konsequentes Offboarding adressieren zentrale OWASP-Risikokategorien.[5][7]
Technik allein reicht nicht: Identitätsbasierte Mikrosegmentierung, Verhaltensüberwachung und automatisierte Richtlinien entfalten ihren Nutzen erst mit klarer Verantwortung, getesteten Reaktionswegen und messbaren Betriebszielen.[4]

Die Zahlen des »2026 Identity Security Landscape« von Palo Alto Networks markieren einen Wendepunkt: Im Durchschnitt kommen inzwischen 109 Maschinenidentitäten auf eine menschliche Identität. Befragt wurden 2.930 Cybersecurity-Verantwortliche. 88 Prozent der Organisationen konzentrieren ihre Identitätssicherung demnach weiterhin vor allem auf Menschen; zugleich erwarten die Befragten, dass die Zahl der KI-Agenten innerhalb eines Jahres um 85 Prozent wächst. Neun von zehn Organisationen berichteten zudem von mindestens einem erfolgreichen identitätsbezogenen Angriff in den vorangegangenen zwölf Monaten.[1] Für Unternehmen folgt daraus kein Bedarf an einem weiteren isolierten Sicherheitstool, sondern an einem belastbaren Betriebsmodell für sämtliche nicht-menschlichen Identitäten.

Der folgende Praxisleitfaden übersetzt die Studienergebnisse in neun Arbeitspakete. Ziel ist nicht, alle Risiken auf einmal zu beseitigen. Entscheidend ist eine belastbare Reihenfolge: zuerst Transparenz und Verantwortung, dann Zugangsdaten und Berechtigungen, anschließend Segmentierung, Automatisierung und kontinuierliche Überwachung.

1. Ein gemeinsames Inventar statt weiterer Insellisten

Der erste Schritt ist eine belastbare Bestandsaufnahme. Zum Inventar gehören nicht nur klassische Service Accounts, sondern auch Service Principals, Workload-Identitäten, API-Schlüssel, OAuth-Tokens, Zertifikate, Bots, RPA-Konten, CI/CD-Identitäten, SaaS-Konnektoren und KI-Agenten. Die Studie zeigt, warum eine punktuelle Erfassung nicht genügt: Maschinenidentitäten entstehen in Cloud-Plattformen, Entwicklungsumgebungen und Fachbereichen deutlich schneller als menschliche Konten.[1]

Praktisch sollte das Sicherheitsteam vorhandene Datenquellen zusammenführen: IAM- und PAM-Systeme, Cloud-Verzeichnisse, Secrets Manager, Code-Repositories, Kubernetes-Cluster, API-Gateways, CI/CD-Plattformen, CMDB, EDR, SIEM und Netzwerk-Telemetrie. Ein Datensatz ist erst dann steuerbar, wenn mindestens Identitätstyp, technischer Name, Umgebung, Eigentümer, Geschäftszweck, verwendetes Credential, Zielsysteme, Privilegierungsgrad, letzte Nutzung und Ablaufdatum dokumentiert sind.

Praxisbeispiel: Ein Unternehmen führt die Daten aus Entra ID, AWS IAM, Kubernetes, GitHub Actions und dem Secrets Vault zusammen. Dabei werden 4.800 NHI gefunden; 620 davon waren zuvor in keiner zentralen Liste erfasst. Für die erste Bereinigungswelle werden nicht alle Konten gleich behandelt: 75 Identitäten mit Produktivzugriff und erhöhten Rechten erhalten Priorität, während 140 seit mehr als 90 Tagen inaktive Konten zunächst in eine Beobachtungs- und Freigabeliste kommen.

Praxisregel: Unbekannte Identitäten nicht sofort abschalten. Zunächst Nutzung und Abhängigkeiten beobachten, dann klassifizieren und mit einem kontrollierten Stilllegungsprozess bearbeiten. So sinkt das Risiko, produktive Abläufe zu unterbrechen.

2. Für jede Identität zwei Verantwortliche benennen

Eine NHI ohne Eigentümer ist organisatorisch verwaist, selbst wenn sie technisch noch aktiv ist. Jede Maschinenidentität sollte deshalb einen fachlichen Owner und einen technischen Betreiber erhalten. Der fachliche Owner bestätigt Zweck, Datenzugriff und Risikoklasse. Der technische Betreiber verantwortet Konfiguration, Rotation, Protokollierung und Abschaltung.

Die Cloud Security Alliance beschreibt Governance und Ownership als eine der größten Schwachstellen: Weniger als ein Viertel der befragten Organisationen verfügte über dokumentierte und formal eingeführte Regeln für das Erstellen oder Entfernen von KI-Identitäten; mehr als 16 Prozent verfolgten die Entstehung neuer KI-bezogener Identitäten überhaupt nicht.[6] Ein Freigabeworkflow sollte daher verhindern, dass eine neue Identität ohne Owner, Zweck, Laufzeit und Rezertifizierungsdatum produktiv geht.

Praxisbeispiel: Für den Service Account einer Zahlungsanwendung ist der Leiter Finance fachlicher Owner; das Plattformteam übernimmt den technischen Betrieb. Eine Eskalationsmatrix legt fest: Das SOC darf Tokens bei bestätigtem Missbrauch sofort sperren, eine endgültige Stilllegung benötigt die Freigabe beider Owner. Als operative Kennzahl gilt der Anteil kritischer NHI mit vollständig besetzter Doppelverantwortung.

Prüffrage für das Management: Wer darf innerhalb von 30 Minuten entscheiden, ob eine auffällige Maschinenidentität gesperrt werden kann? Gibt es darauf keine eindeutige Antwort, ist die Verantwortungsstruktur unzureichend.

3. Geschäftszweck und erlaubtes Verhalten dokumentieren

Ein Name wie »svc-prod-01« sagt nichts darüber aus, welche Aktionen legitim sind. Für jede kritische NHI braucht es deshalb ein kurzes Maschinenidentitätsprofil: Welche Aufgabe erfüllt sie? Welche Systeme darf sie ansprechen? Welche Datenklassen darf sie lesen oder verändern? Zu welchen Zeiten und aus welchen Umgebungen darf sie aktiv sein? Darf sie weitere Identitäten oder Subagenten erzeugen?

Dieses Soll-Profil wird später zur Grundlage für Zugriffsrichtlinien und Verhaltensüberwachung. Besonders bei KI-Agenten reicht eine Beschreibung des Einsatzzwecks nicht aus. Zusätzlich müssen zulässige Werkzeuge, Datenquellen, Transaktionsgrenzen, Delegationsketten und Abbruchbedingungen festgelegt werden. Ein Agent, der E-Mails zusammenfasst, benötigt beispielsweise keine dauerhafte Schreibberechtigung in einem Finanzsystem.

4. Langlebige Secrets systematisch abbauen

Statische API-Schlüssel, hart codierte Passwörter und dauerhaft gültige Tokens sind bequem, vergrößern aber das Zeitfenster für Missbrauch. OWASP führt sowohl Secret Leakage als auch Long-Lived Secrets unter den zentralen Risiken nicht-menschlicher Identitäten. Geheimnisse können über Quellcode, Protokolle, Konfigurationsdateien, Entwicklergeräte oder SaaS-Dienste abfließen.[5]

Unternehmen sollten zunächst die kritischsten Secrets priorisieren: produktive Cloud-Zugänge, Datenbank-Credentials, CI/CD-Schlüssel und Tokens mit Schreib- oder Administrationsrechten. Wo die Plattform es unterstützt, sind verwaltete Workload-Identitäten, föderierte Vertrauensbeziehungen, kurzlebige Tokens oder Zertifikate statischen Geheimnissen vorzuziehen. Verbleibende Secrets gehören in einen zentralen Vault, müssen automatisiert rotiert und bei Verdacht kurzfristig widerrufen werden können.

Praxisbeispiel: Eine CI/CD-Pipeline verwendet bislang einen Cloud-Schlüssel mit zwölf Monaten Laufzeit. Im Pilot wird dieser durch eine föderierte Workload-Identität ersetzt, die pro Build ein kurzlebiges Token erhält. Gemessen werden die Zahl dauerhaft gespeicherter Secrets, ihre durchschnittliche Restlaufzeit, die Erfolgsquote automatisierter Rotationen und die Zeit bis zum Widerruf. Als 90-Tage-Zielkorridor eignen sich beispielsweise 30 bis 50 Prozent weniger langlebige Secrets im Pilotbereich und eine Widerrufszeit von höchstens 30 Minuten.

Umsetzungstipp: Rotation nicht als reinen Sicherheitsvorgang behandeln. Jede Rotation benötigt einen technischen Test, einen Rückfallplan und eine Überwachung der abhängigen Anwendung. Erst wenn die Anwendung aktualisierte Credentials ohne manuelle Eingriffe übernimmt, ist der Prozess wirklich automatisiert.

5. Least Privilege aus realer Nutzung ableiten

Die Studie verweist auf eine deutliche Lücke zwischen Anspruch und Praxis: Viele Unternehmen wollen Least Privilege durchsetzen, können die tatsächlichen Berechtigungen von Service Accounts, Konnektoren und Agenten aber nicht ausreichend überblicken.[1] Eine einmalige Rollenbereinigung reicht deshalb nicht. Berechtigungen müssen regelmäßig mit beobachteter Nutzung verglichen werden.

Ein praktikables Vorgehen besteht aus drei Stufen. Zuerst wird vier bis sechs Wochen lang erfasst, welche Ressourcen eine Identität tatsächlich nutzt. Danach werden nicht verwendete Rechte in einer Simulation entfernt. Erst wenn keine geschäftskritischen Verbindungen betroffen sind, folgt die schrittweise Durchsetzung. Hochprivilegierte Aktionen sollten möglichst über Just-in-Time-Verfahren oder Zero Standing Privilege bereitgestellt werden, statt dauerhaft verfügbar zu sein.

Für KI-Agenten sollte die Autorisierung zusätzlich auf einzelne Aufgaben begrenzt werden. Zugriffsrechte, die ein Agent für einen bestimmten Auftrag erhält, dürfen nicht automatisch für spätere Aufgaben oder erzeugte Subagenten weitergelten.

Praxisbeispiel: Ein Reporting-Agent darf für einen Monatsabschluss Daten aus drei freigegebenen Quellen lesen und eine Datei in einem definierten Zielordner ablegen. Schreibrechte in ERP-Stammdaten und der Zugriff auf Personalinformationen bleiben gesperrt. Nach vier Wochen Beobachtung zeigt sich, dass zwei von acht ursprünglich gewährten Rollen benötigt werden. Der Pilot misst deshalb nicht nur die Zahl entzogener Rollen, sondern auch fehlgeschlagene Geschäftsprozesse und notwendige Ausnahmen.

6. Netzwerkpfade identitätsbasiert begrenzen

IAM regelt, ob eine Identität ein Ziel grundsätzlich nutzen darf. Mikrosegmentierung ergänzt diese Kontrolle um die Frage, welche Netzwerkverbindung tatsächlich erlaubt ist. Das ist besonders relevant, wenn gültige Zugangsdaten kompromittiert wurden: Ein erfolgreicher Login darf nicht automatisch freie Bewegung zwischen Cloud, Rechenzentrum, Entwicklungsumgebung und kritischen Fachsystemen ermöglichen.

Die Segmentierung sollte sich an Identität, Anwendung und Geschäftsprozess orientieren, nicht allein an IP-Adressen. Beginnen sollten Unternehmen mit besonders sensiblen Ost-West-Verbindungen: von CI/CD-Systemen in Produktionsumgebungen, von Administrationsdiensten zu Identitätsplattformen sowie von KI-Agenten zu Datenbanken, Dateiablagen und externen APIs. Neue Regeln werden zunächst beobachtet und simuliert, anschließend in kleinen Gruppen aktiviert.

Praxisbeispiel: Ein kompromittierter Build-Agent könnte ohne Segmentierung zwölf produktive Systeme erreichen. Eine identitätsbasierte Richtlinie erlaubt anschließend nur noch die Artefaktablage und zwei definierte Deployment-Ziele. Als Kennzahlen dienen die Zahl erreichbarer kritischer Systeme je NHI, der Anteil dokumentierter Ost-West-Verbindungen und die Quote der Regeln, die vor Aktivierung mindestens sieben Tage ohne ungeklärte Treffer simuliert wurden.

Wichtig: Mikrosegmentierung ersetzt weder sauberes Identity Lifecycle Management noch PAM, sichere Secrets oder Monitoring. Sie begrenzt den möglichen Aktionsradius und schafft damit eine zusätzliche Kontrollschicht.

7. Den Lifecycle an CI/CD, Cloud und ITSM koppeln

Viele verwaiste Identitäten entstehen nicht bei der Einrichtung, sondern am Ende eines Projekts, einer Anwendung oder eines Dienstvertrags. OWASP nennt unsachgemäßes Offboarding als führendes NHI-Risiko.[5] Erstellung, Änderung, Rezertifizierung und Stilllegung müssen deshalb Teil der regulären Betriebsprozesse werden.

Neue Maschinenidentitäten sollten ausschließlich über standardisierte Workflows angelegt werden. Änderungen an Anwendung, Umgebung, Owner oder Datenklasse lösen automatisch eine Neubewertung aus. Das Ende eines Projekts, das Löschen eines Cloud-Workloads, ein abgelaufener Vertrag oder eine längere Inaktivität erzeugt ein Stilllegungs-Ticket. Nach der Abschaltung werden Credentials widerrufen, Berechtigungen entfernt und abhängige Richtlinien bereinigt.

Für kritische NHI empfiehlt sich eine quartalsweise Rezertifizierung. Weniger sensible Identitäten können risikobasiert in längeren Intervallen geprüft werden. Entscheidend ist, dass Ausnahmen befristet und begründet sind.

8. Erkennung auf Identität und Verhalten ausrichten

Der Missbrauch einer Maschinenidentität sieht in klassischen Logdaten häufig legitim aus, weil Angreifer gültige Tokens oder Schlüssel verwenden. Deshalb benötigt jede kritische NHI eine Verhaltensbasis. Beobachtet werden sollten unter anderem Anmeldequelle, Zielsysteme, Uhrzeiten, Datenvolumen, Anzahl und Reihenfolge von API-Aufrufen, neue Tools, geänderte Privilegien und ungewöhnliche Delegationen.

Bei KI-Agenten kommen weitere Signale hinzu: plötzlich erweiterte Tool-Ketten, ungewöhnlich viele autonome Schritte, der Zugriff auf bislang ungenutzte Datenquellen oder die Erzeugung neuer Identitäten. Alarme müssen direkt mit Reaktionsmöglichkeiten verknüpft sein – etwa Token-Widerruf, Netzwerkisolation, Entzug einzelner Tools oder Übergabe an einen menschlichen Entscheider.

Praxisbeispiel: Ein Service Account greift gewöhnlich werktags aus einem festen Cluster auf eine Datenbank zu. Ein nächtlicher Zugriff aus einer neuen Cloud-Region mit zehnfachem Datenvolumen löst einen Alarm aus. Die Reaktion wird als Ablauf gemessen: Erkennung innerhalb von fünf Minuten, Entscheidung innerhalb von 15 Minuten und Token-Widerruf innerhalb von 30 Minuten. Die Studie nennt im Markt durchschnittlich zwölf zusätzliche Stunden pro Vorfall durch fragmentierte Werkzeuge; der interne Zielwert sollte deshalb ausdrücklich die eigene Prozesskette abbilden.[1]

Die Studie beziffert den Zeitverlust durch fragmentierte Identitätssysteme und Werkzeuge auf durchschnittlich zwölf zusätzliche Stunden pro identitätsbezogenem Vorfall.[1] Ein gemeinsames Lagebild aus IAM-, Endpoint-, Cloud- und Netzwerkdaten ist daher nicht nur eine Frage der Erkennung, sondern auch der Reaktionsgeschwindigkeit.

9. Mit einem begrenzten, messbaren Pilotprojekt starten

Ein Pilot sollte weder die gesamte Organisation umfassen noch bei einer unkritischen Demo-Anwendung beginnen. Geeignet ist ein produktionsnaher Prozess mit erhöhtem Schutzbedarf, überschaubaren Abhängigkeiten und einem erreichbaren Owner. Typische Kandidaten sind privilegierte CI/CD-Identitäten, ein Service Account mit Zugriff auf Kundendaten oder ein KI-Agent, der mehrere interne Werkzeuge nutzt.

Vor dem Start werden Ausgangswerte erhoben. Dazu gehören bekannte NHI, Owner-Abdeckung, Zahl langlebiger Secrets, durchschnittliche Berechtigungen, erreichbare Zielsysteme, Rezertifizierungsstatus und Zeit bis zum Widerruf. Nach der Beobachtungsphase werden Richtlinien simuliert, technische und fachliche Auswirkungen geprüft und Kontrollen stufenweise aktiviert.

Geeignete Erfolgskennzahlen sind:

Kennzahlen-Cockpit für den 90-Tage-Pilot

Kennzahl	Berechnung	Konkrete Datenquellen	Messintervall	Beispiel-Ausgangs-wert	Empfohlener 90-Tage-Zielkorridor
Inventar-abdeckung	Erfasste NHI ÷ geschätzte NHI × 100	IAM- und PAM-Verzeichnisse; Microsoft Entra ID beziehungsweise Active Directory; AWS IAM und Google Cloud IAM; Kubernetes-Service-Accounts; CI/CD-Plattformen; Secrets Vault; CMDB; API-Gateway; Certificate Manager	Automatisierte Erkennung täglich; konsolidierte Auswertung wöchentlich; Managementbericht monatlich	72 Prozent	mindestens 90 Prozent im Pilotbereich
Owner-Abdeckung	NHI mit fachlichem und technischem Owner ÷ erfasste NHI × 100	Identity-Governance-System; CMDB; ITSM-Tickets; Anwendungsverzeichnis; RACI-Matrix; HR-Verzeichnis zur Prüfung aktiver Verantwortlicher	Bei jeder Neuanlage oder Änderung; automatischer Abgleich wöchentlich; formale Prüfung monatlich	54 Prozent	95 bis 100 Prozent bei kritischen NHI
Anteil langlebiger Secrets	Credentials mit mehr als 90 Tagen Laufzeit ÷ alle Credentials × 100	Secrets Manager und Vault; Cloud-Key-Management; Zertifikatsverwaltung; CI/CD-Variablen; Code- und Secret-Scanning; IAM-Credential-Reports	Secret- und Repository-Scan täglich; Laufzeitauswertung wöchentlich; Trendbericht monatlich	68 Prozent	Reduktion um 30 bis 50 Prozent
Verwaiste Identitäten	NHI ohne aktiven Zweck oder Owner ÷ erfasste NHI × 100	IAM-Verzeichnis; CMDB; ITSM; Cloud-Ressourceninventar; Projekt- und Anwendungsverzeichnis; letzte Anmeldung und letzte API-Nutzung aus SIEM- oder Audit-Logs	Inaktivitätsprüfung wöchentlich; Owner- und Zweckprüfung monatlich; vollständige Rezertifizierung quartalsweise	14 Prozent	unter 5 Prozent; kritisch privilegierte NHI bei 0 Prozent
Least-Privilege-Abdeckung	Kritische NHI mit geprüfter Soll-Rolle ÷ alle kritischen NHI × 100	IAM- und PAM-Rollenmodelle; Cloud-Berechtigungsanalysen beziehungsweise CIEM; Zugriffs- und API-Logs; Datenbank-Audit; Kubernetes-RBAC; freigegebene Soll-Profile	Nutzungsdaten kontinuierlich sammeln; Abweichungen wöchentlich prüfen; Rollen monatlich und nach wesentlichen Änderungen rezertifizieren	25 Prozent	mindestens 80 Prozent
Segmen-tierungs-grad	Abgesicherte kritische Verbindungen ÷ identifizierte kritische Verbindungen × 100	Netzwerk-Flow-Logs; Firewall- und Mikrosegmentierungsrichtlinien; Cloud Security Groups; Kubernetes Network Policies; Service-Mesh-Telemetrie; CMDB-Abhängigkeiten	Telemetrie kontinuierlich; Regelabweichungen täglich; Abdeckungsbericht wöchentlich; Managementtrend monatlich	35 Prozent	70 bis 90 Prozent
Mittlere Widerrufszeit	Zeit von bestätigtem Alarm bis zur technischen Sperrung	SIEM-Alarmzeit; SOAR-Workflow; Incident-Ticket; IAM-, PAM- und Vault-Audit-Logs; Cloud-Control-Plane-Logs; Zeitstempel der Netzisolation	Bei jedem Vorfall messen; operativ wöchentlich auswerten; Managementbericht monatlich; Notfallübung quartalsweise	4 Stunden	höchstens 30 Minuten für kritische NHI
Rezerti-fizierungs-quote	Fristgerecht geprüfte NHI ÷ fällige NHI × 100	Identity-Governance- und Access-Review-System; ITSM-Aufgaben; Owner-Bestätigungen; Ausnahme- und Risikoregister	Status wöchentlich; kritische NHI quartalsweise rezertifizieren; übrige NHI halbjährlich oder risikobasiert	61 Prozent	mindestens 95 Prozent
Fehl-blockierungs-quote	Unberechtigt blockierte legitime Verbindungen ÷ alle blockierten Verbindungen × 100	Firewall- und Mikrosegmentierungslogs; Service-Desk-Störungen; Change-Tickets; Applikationsmonitoring; Ausnahmeanträge; fachlich bestätigte Fehlalarme	Während Einführung täglich; nach Stabilisierung wöchentlich; Trend und Schwellenwerte monatlich überprüfen	noch nicht erhoben	unter 2 Prozent nach der Stabilisierungs-phase

Einordnung: Die Ausgangswerte und Zielkorridore sind Praxisbeispiele, keine Ergebnisse der Studie. Jedes Unternehmen sollte sie anhand von Kritikalität, regulatorischen Vorgaben, Betriebsmodell und technischer Ausgangslage anpassen. Für die Steuerung zählt vor allem die Entwicklung über mehrere Messperioden.

Anteil inventarisierter Maschinenidentitäten an der geschätzten Gesamtzahl,
Anteil der NHI mit fachlichem und technischem Owner,
Anteil kurzlebiger oder verwalteter Credentials,
Zahl verwaister und überprivilegierter Identitäten,
Anteil der Zugriffe über Just-in-Time- oder Zero-Standing-Privilege-Verfahren,
mittlere Zeit bis zum Widerruf kompromittierter Credentials,
Anteil kritischer Netzwerkpfade mit durchgesetzter Segmentierung,
Zahl ungeplanter Betriebsunterbrechungen durch neue Richtlinien.

Ein 90-Tage-Fahrplan für die Umsetzung

Tag 1 bis 30 – Transparenz herstellen: Ein bereichsübergreifendes Team aus IAM, Cloud, Netzwerk, DevOps, SOC und Fachbereichen benennen. Datenquellen anbinden, ein erstes Inventar erstellen, kritische Identitätstypen definieren und für die wichtigsten NHI Owner zuweisen. Gleichzeitig werden einheitliche Pflichtfelder und Risikoklassen beschlossen.

Tag 31 bis 60 – Risiken priorisieren: Langlebige Secrets, privilegierte Konten, verwaiste Identitäten und kritische Netzwerkpfade identifizieren. Für den Piloten Nutzungsdaten sammeln, Soll-Profile formulieren und geplante Berechtigungs- sowie Segmentierungsregeln simulieren. Abschalt- und Notfallwiderrufsprozesse praktisch testen.

Tag 61 bis 90 – Kontrollen durchsetzen: Kurzlebige Credentials oder automatisierte Rotation für die priorisierten Identitäten einführen. Überflüssige Rechte schrittweise entfernen, ausgewählte Netzwerkpfade segmentieren und Verhaltensalarme mit konkreten Reaktionsmaßnahmen verbinden. Abschließend Kennzahlen und Betriebsfolgen auswerten und über die nächste Rollout-Welle entscheiden.

Fazit: Aus Identitätswachstum muss Governance-Geschwindigkeit werden

Das Verhältnis von 109 Maschinenidentitäten zu einer menschlichen Identität ist vor allem ein Hinweis auf ein Skalierungsproblem: Manuelle Inventare, jährliche Rezertifizierungen und statische Netzwerkregeln halten mit automatisiert erzeugten Workloads und KI-Agenten nicht Schritt.[1] Unternehmen benötigen deshalb ein Betriebsmodell, das Identitäten kontinuierlich entdeckt, Verantwortlichkeiten erzwingt, Credentials kurzlebig hält, Rechte aus realer Nutzung ableitet und Netzwerkpfade begrenzt.

Der sinnvollste Startpunkt ist nicht ein flächendeckendes Großprojekt. Ein messbarer Pilot schafft belastbare Daten, deckt Abhängigkeiten auf und zeigt, welche Kontrollen sich ohne Betriebsstörung automatisieren lassen. Erst danach sollte die Organisation das Modell auf weitere Anwendungen, Clouds und Agenten ausweiten.

Albert Absmeier & KI

Tipps für die Umsetzung

Mit kritischen Identitäten beginnen: Priorisieren Sie produktive Service Accounts, CI/CD-Zugänge, Cloud-Administrationsrollen und KI-Agenten mit Zugriff auf vertrauliche Daten.
Owner verpflichtend machen: Keine neue Maschinenidentität ohne fachlichen Verantwortlichen, technischen Betreiber, dokumentierten Zweck und Ablaufdatum.
Secrets vermeiden statt nur rotieren: Nutzen Sie verwaltete Identitäten oder föderierte Workload-Identitäten, wo die Plattform dies unterstützt.[7]
Berechtigungen aus Nutzung ableiten: Beobachten Sie tatsächliche Verbindungen, simulieren Sie den Entzug ungenutzter Rechte und setzen Sie ihn stufenweise durch.
Offboarding automatisieren: Projektende, Ressourcenlöschung, Vertragsablauf und längere Inaktivität sollten eine Rezertifizierung oder Stilllegung auslösen.[5]
Agenten separat protokollieren: Halten Sie fest, welcher Agent im Auftrag welcher Person oder Anwendung welche Tools und Daten verwendet.
Reaktionswege testen: Token-Widerruf, Netzisolation und Entzug einzelner Werkzeuge müssen innerhalb definierter Zeiten ausführbar sein.
Fortschritt messen: Verfolgen Sie Inventarabdeckung, Owner-Quote, Anteil kurzlebiger Credentials, verwaiste Identitäten und Zeit bis zum Widerruf.

FAQ: Maschinenidentitäten sicher steuern

1. Was ist eine Maschinenidentität?

Eine Maschinen- oder nicht-menschliche Identität authentifiziert eine Anwendung, einen Dienst, ein Skript, einen Container, ein Gerät oder einen KI-Agenten. Microsoft fasst Anwendungen, Service Principals und Managed Identities als Workload-Identitäten zusammen.[7]

2. Wie belastbar ist das Verhältnis von 109 zu eins?

Der Wert stammt aus einer von Palo Alto Networks veröffentlichten Befragung von 2.930 Cybersecurity-Entscheidern. Er beschreibt den Durchschnitt der befragten Organisationen und sollte als Marktindikator verstanden werden, nicht als Messwert für jedes einzelne Unternehmen.[1]

3. Warum sind KI-Agenten anspruchsvoller als klassische Service Accounts?

Service Accounts führen meist vorhersehbare Aufgaben aus. KI-Agenten können Werkzeuge auswählen, Schritte verketten, Zugriffe delegieren und ihren Aktionsraum dynamisch erweitern. Deshalb benötigen sie eindeutige Identitäten, Laufzeitkontrollen und nachvollziehbare Delegationsketten.[6]

4. Welche Risiken nennt OWASP?

Die OWASP NHI Top 10 führen unter anderem unzureichendes Offboarding, Secret-Leaks, riskante Drittanbieter-Identitäten, schwache Authentisierung, überprivilegierte NHI und unsichere Cloud-Deployments auf.[5]

5. Reicht ein Secrets Vault aus?

Nein. Ein Vault schützt und verteilt Zugangsdaten, löst aber nicht automatisch Fragen zu Eigentümerschaft, Geschäftszweck, Berechtigungen und Stilllegung. Wo möglich, sollten langlebige Secrets durch verwaltete oder föderierte Workload-Identitäten ersetzt werden.[7]

6. Welche Rolle spielt Zero Trust?

Zero Trust gewährt kein implizites Vertrauen aufgrund des Netzwerkstandorts. Authentisierung und Autorisierung erfolgen vor dem Zugriff auf eine Ressource; Richtlinien orientieren sich an Identität, Ressource und Kontext.[4]

7. Was bringt identitätsbasierte Mikrosegmentierung?

Sie begrenzt die erlaubten Kommunikationspfade einer Identität und kann damit laterale Bewegungen erschweren. Sie ergänzt IAM und Secrets Management, ersetzt aber weder Lifecycle-Governance noch Monitoring und Incident Response.[4]

8. Welche Kennzahlen sind für das Management sinnvoll?

Geeignet sind Inventarabdeckung, Owner-Quote, Zahl verwaister NHI, Anteil kurzlebiger Credentials, überprivilegierte Konten, Rezertifizierungsquote und mittlere Zeit bis zum Widerruf. Der Branchenwert von 109 zu eins dient dabei nur als Vergleichsgröße.[1]

9. Wie lässt sich Schatten-KI reduzieren?

Technische Erkennung muss mit klaren Freigabe- und Beschaffungsprozessen verbunden werden. Die Cloud Security Alliance berichtet, dass weniger als ein Viertel der Organisationen dokumentierte Richtlinien für das Erstellen oder Entfernen von KI-Identitäten besitzt und mehr als 16 Prozent neue KI-Identitäten nicht verfolgen.[6]

10. Wie sollte ein Pilotprojekt aussehen?

Geeignet ist ein produktionsnaher Prozess mit hohem Schutzbedarf, überschaubaren Abhängigkeiten und erreichbarem Owner. Nach einer Beobachtungsphase werden Regeln simuliert, Auswirkungen geprüft und Kontrollen stufenweise durchgesetzt. Ausgangswerte und Zielkennzahlen müssen vor dem Start feststehen.

Quellen

[1] Palo Alto Networks, »Lage der Identitätssicherheit 2026«: https://www.paloaltonetworks.de/idira/identity-security-landscape-report

[6] Cloud Security Alliance, »The State of Non-Human Identity and AI Security«: https://cloudsecurityalliance.org/artifacts/state-of-nhi-and-ai-security-survey-report

[5] OWASP, »Non-Human Identities Top 10 – 2025«: https://owasp.org/www-project-non-human-identities-top-10/2025/top-10-2025

[4] NIST Special Publication 800-207, »Zero Trust Architecture«: https://csrc.nist.gov/pubs/sp/800/207/final

[7] Microsoft Learn, »Workload identities«: https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

94 Artikel zu „KI-Identitäten“

IT-Security | Künstliche Intelligenz | News | Trends 2026 | Trends Security | Whitepaper

KI-Identitäten außer Kontrolle: Massive Governance-Lücken in deutschen Unternehmen

29. Januar 2026

Künstliche Intelligenz ist längst kein Zukunftsthema mehr. Sie agiert in Arbeitsumgebungen bereits heute autonom. Das ist auf der einen Seite ein Riesenvorteil, auf der anderen Seite jedoch schwierig überwachbar. Eine neue internationale Umfrage, beauftragt von Saviynt und in Deutschland, Großbritannien und den USA durchgeführt, zeigt: KI-Identitäten greifen bereits tief in kritische Systeme ein [1].…