Governance nicht-menschlicher Identitäten vs. traditionelles Identity Management für EU AI Act, NIST CSF, ISO 27001 und NIS2

Nicht-menschliche Identitäten - Service-Accounts, API Keys, Bots, RPA-Skripte, CI/CD-Pipelines und jetzt AI Agents - sind heute in den meisten Umgebungen die dominierende "Belegschaft".

Aktuelle Studien schätzen, dass nicht-menschliche Identitäten Menschen um den Faktor 20:1 bis über 80:1 übersteigen; in manchen Cloud-nativen Umgebungen liegt das Verhältnis sogar über 100:1. Das bedeutet: Tausende von ständig aktiven Berechtigungen, oft mit privilegiertem Zugriff und kaum Governance.

Ab 2026 ist das nicht mehr nur ein Security-Thema, sondern ein handfestes Compliance-Risiko.

• EU AI Act (EU-KI-Verordnung): Hochrisiko-KI-Systeme erfordern strikte Protokollierung, Transparenz und technische Kontrollen.
• NIST CSF 2.0: Identity Management für "users, services and hardware" ist verpflichtend.
• ISO 27001:2022: Service- und privilegierte Konten brauchen Verantwortliche, Least Privilege und regelmäßige Reviews.
• NIS2: Identity- und Access-Management sind Baseline-Anforderungen mit Haftung auf Vorstandsebene.

Der EU AI Act ist am 1. August 2024 in Kraft getreten. Die meisten Pflichten greifen gestaffelt über 6-36 Monate; Bußgelder können bei schweren Verstößen bis zu 7 % des weltweiten Jahresumsatzes erreichen. NIST hat das Cybersecurity Framework 2.0 am 26. Februar 2024 veröffentlicht - mit einer neuen "Govern"-Funktion und expliziten Anforderungen für alle Identitäten und Credentials. Die ISO 27001:2022 Annex-A-Kontrollen (A.5.16, A.8.2) verlangen, dass Service- und privilegierte Accounts einen Owner und regelmäßige Reviews haben. Die NIS2-Richtlinie (EU) 2022/2555 muss bis 17. Oktober 2024 in nationales Recht umgesetzt werden; deutsche Leitfäden erwarten für viele SaaS-Anbieter bis April 2026 belastbare technische Nachweise für Artikel 21.

Wenn Ihr Stack immer noch implizit annimmt "Identität = Menschen im SSO", erwarten Aufsichtsbehörden jetzt, dass Sie diese Blindspots schließen.

Dieser Beitrag vergleicht zwei Ansätze:

1. Traditionelles, menschenzentriertes Identity Management - SSO plus manuelle Prozesse und punktuelle Tools.
2. Vereinheitlichte Governance nicht-menschlicher Identitäten - ein vollständiges IGA-Modell, das Menschen, AI Agents und Service-Accounts gemeinsam abdeckt (der Iden-Ansatz).

Wir betrachten beide Ansätze aus der 2026er-Regulierungsperspektive und schließen mit konkreten Handlungsempfehlungen.

Zusammenfassung: Traditionell vs. vereinheitlichte Governance nicht-menschlicher Identitäten

Option 1: Traditionelles, menschenzentriertes Identity Management

Die meisten schnell wachsenden Unternehmen haben ihren Stack nicht für AI Agents oder Service-Accounts entworfen. Typischerweise sieht er so aus:

• SSO (Okta, Entra ID etc.) für die Authentifizierung der Belegschaft
• Lifecycle-Automatisierung für SCIM-fähige Apps
• Manuelles Provisioning für alles andere - Long-Tail-SaaS, Legacy, interne Tools
• Service-Accounts werden - falls überhaupt - in Passwort-Tresoren, Wikis oder Notizen verwaltet
• Quartalsweise Access-Reviews in Tabellen

Stärken:

• Besser als App-zu-App-Passwörter
• Für Auditoren vertraut - SSO + manuelle Reviews sind erwarteter Standard
• Einfacher Einstieg - so arbeiten die meisten Organisationen heute

Schwächen:

• Nicht-menschliche Identitäten überall - CI/CD, Bots, API Tokens, AI Agents
• Unklare Verantwortlichkeiten - wem "gehört" dieser alte Service-Account?
• Manuelle, punktuelle Reviews - Auditoren sehen Durchwink-Genehmigungen statt fundierter Entscheidungen
• Nur ein Teil der Applandschaft ist automatisiert - der Rest basiert auf Gedächtnis und Goodwill

Dieses Modell ist nicht geeignet für eine Welt, in der ein einziges Team in einem Quartal Tausende von API Keys und AI Agents erzeugen kann.

Option 2: Vereinheitlichte Governance nicht-menschlicher Identitäten (Iden-Style)

Die Lösung ist ein einheitliches Identity Fabric - Menschen und Maschinen werden gleichberechtigt und kontinuierlich regiert.

Iden verkörpert diesen Ansatz:

• Eine Plattform für alle User, Agents, Service-Accounts und externe Mitarbeitende
• Universelle Connectoren zu jeder App - kein zwingendes SCIM und kein erzwungenes Upgrade auf Enterprise-Tiers
• Fein granulierte Steuerung über Channels, Repos, Projekte, Umgebungen hinweg
• Agentische Workflows - AI-gesteuerte, autonome Provisionierung und Rightsizing von Berechtigungen
• Unveränderliche Audit-Logs, kontinuierliche Reviews

Iden-Kunden berichten von rund 80 % weniger manuellen Access-Tickets, sparen etwa 120 Stunden pro Quartal bei Reviews und senken ihre SaaS-Ausgaben um bis zu 30 % durch Lizenzrückgewinnung und das Vermeiden unnötiger Upgrades.

Das ist kein UI-Facelift für alte IGA-Suiten, sondern ein neuer Ausgangspunkt: Jede Identität - menschlich oder maschinell - wird nach demselben Modell regiert.

Direktvergleich: Kritische Kriterien

1. Identity Coverage: Menschen vs. Nicht-Menschen

Traditionell:

• Identitäten werden als User aus HRIS/AD modelliert; nicht-menschliche Identitäten entstehen außerhalb zentraler Prozesse, werden geteilt genutzt und haben keinen klaren Lifecycle
• Service-Accounts stehen im Passwort-Tresor - ohne Kontext

Vereinheitlicht:

• Jeder authentifizierbare Principal ist eine Identität - Mensch, Workload, Bot, AI Agent
• Zentrales Verzeichnis mit Typ, Owner, Business-Zweck, Berechtigungen
• AI-gestützte Discovery deckt "Identity Dark Matter" auf: verwaiste, veraltete, ungenutzte Credentials

Kontext 2026: NIST CSF 2.0 und ISO 27001 verlangen identitätsgenaue Antworten auch für AI Agents und Service-Accounts. Wenn Sie für nicht-menschliche Akteure nicht beantworten können "Wer kann was?", sind Sie faktisch bereits außerhalb der Leitplanken.

2. Regulatorische Ausrichtung

EU AI Act

Der AI Act führt Pflichten bis 2026/2027 gestaffelt ein, insbesondere für Hochrisiko-Systeme - Risikomanagement, Logging, technische Dokumentation.

Traditionell:

• Steuert, wer auf die UI der KI-Plattform zugreifen darf - nicht jedoch die Agents selbst
• Audit-Trails sind oft nicht eindeutig einem Agent als Identität zugeordnet

Vereinheitlicht:

• Modelliert jeden AI Agent als eigene, regierte nicht-menschliche Identität
• Policies, zeitlich begrenzte Zugriffe, Audit-Trails für sämtliche Agent-Aktionen
• Volle Nachvollziehbarkeit und Verantwortlichkeit - im Sinne der Anforderungen des AI Act

NIST CSF 2.0

NIST CSF 2.0 adressiert Identity und Access für User, Services und Hardware über den gesamten Lifecycle.

Traditionell:

• Stabil für Menschen (Provisioning, SSO, MFA)
• Schwach für nicht-menschliche Identitäten - Service-Accounts umgehen oft Workflows, nutzen statische Credentials und werden kaum überwacht

Vereinheitlicht:

• Lifecycle-Automatisierung für alle Identitäten - menschlich und maschinell
• Policies und kontinuierliches Monitoring über die gesamte Landschaft
• Vereinfachte CSF-Compliance - zentrale Nachweise statt Chaos

ISO 27001:2022

ISO Annex A 5.16/8.2 verlangen Owner, Begründung, Least Privilege und regelmäßige Reviews für alle Accounts - einschließlich Service-Accounts.

Traditionell:

• Menschliche Accounts sind meist konform; nicht-menschliche hingegen selten - geteilte, veraltete Konten, schwaches Logging, Nachweise über diverse Exporte verstreut

Vereinheitlicht:

• Owner und Begründung sind für jede Identität Pflicht
• Automatisierte Reviews, direkt auf ISO-Kontrollen gemappt, mit klaren Audit-Nachweisen

NIS2

NIS2 verankert Haftung auf Vorstandsebene, fordert technische und organisatorische Maßnahmen (Artikel 21) und droht mit hohen Bußgeldern (mindestens 10 Mio. € oder 2 % Umsatz).

Traditionell:

• Kann SSO/MFA für Menschen belegen, scheitert aber oft an einer vollständigen, aktuellen Inventur privilegierter/technischer Accounts und deren Governance

Vereinheitlicht:

• Konsistente, testbare Policies für alle Identitäten
• Live-Nachweise - unveränderliche Logs, Attestierungsprotokolle - für schnelle Audit-Responses

3. Nachweise und Auditierbarkeit: Statische vs. kontinuierliche Belege

Spätestens 2026 reicht "Papier-Compliance" nicht mehr - Auditoren wollen live Evidenz.

Traditionell:

• Evidence-Gathering ist ein Projekt: Listen ziehen, Tabellen mergen, Genehmigungen nachfordern, Tickets exportieren
• Statische Prüfungen stehen dauerhaften Angriffen gegenüber - neue Risiken bleiben unentdeckt

Vereinheitlicht:

• Unveränderliche Logs; Echtzeit-Access-Entscheidungen
• Reviews sind fokussiert und umsetzbar - Zweck, Nutzung und Entzug/Verlängerung in einem Schritt sichtbar
• Auditoren sehen das Livesystem, nicht manuell zusammenkopierte Tabellen

Das ist der Unterschied zwischen Security-Theater und echten, testbaren Kontrollen.

4. Skalierung und Automatisierung: 10-100× mehr nicht-menschliche Identitäten

Manuelle Prozesse kollabieren bei dieser Größenordnung.

Traditionell:

• Jeder Service-Account ist eine Ausnahme; Skripte und Freigaben werden fragil
• Kein organisationales Lernen - Menschen leisten die Schwerstarbeit

Vereinheitlicht:

• Von Grund auf für die Dominanz nicht-menschlicher Identitäten gedacht
• Agentische Workflows - automatische Discovery, Risikoklassifizierung, Feinjustierung und Entzug von Zugriffen
• Menschliche Teams konzentrieren sich auf Ausnahmen - die Plattform deckt den Long Tail ab

5. Kosten, SCIM Tax und Tool-Sprawl

Identity ist nicht nur ein Compliance-Thema - sondern auch eine Budgetposition.

Traditionell:

• Zahlt die SCIM Tax - Upgrades auf höhere App-Tiers allein für SCIM-Unterstützung
• Führt zusätzliche Punktlösungen ein - PAM, Secrets-Management, Access-Reviews, AI-Governance
• Überlappende Lizenzen und doppelte Kontrollen

Vereinheitlicht:

• Automatisiert über alle App-Tiers hinweg - ohne zwingendes SCIM oder API
• Konsolidiert Governance, Automatisierung und Compliance-Nachweise
• Holt Budget über Lizenzrückgewinnung zurück und vermeidet erzwungene Upgrades

6. Zukunftssicherheit: AI Agents & neue Identitätsspezies

AI Agents sind bereits Realität und vervielfachen sich - autonome Bots, die quer durch Ihren Stack arbeiten.

Traditionell:

• Behandelt Agents als "nur weitere Integrationen" - ein zusätzlicher API Key, ein Shared Account
• Governance endet beim Deployment - nicht bei den Berechtigungen des Agents

Vereinheitlicht:

• AI Agents werden zu First-Class-Identitäten mit Governance - Rollen, Scopes, Verhaltensüberwachung
• Ausgerichtet an EU AI Act, NIST AI RMF, ISO/IEC-Vorgaben für Machine Governance

Wenn Aufsichtsbehörden nach den Rechten von AI Agents fragen, reicht "Wir haben SSO" nicht aus.

Empfehlungen: Was ist für 2026 sinnvoll?

Wann ein traditionell, menschenzentrierter Ansatz "ausreichend" sein kann

• Kleine Organisation (<100 Mitarbeitende) mit wenig Automatisierung/KI
• Nicht-menschliche Identitäten sind überschaubar, statisch und zentral dokumentiert
• Geringe Regulierungslast (kein NIS2, keine Hochrisiko-KI)
• Bereitschaft, zu jedem Audit erheblichen manuellen Aufwand zu schultern

Trotzdem sollten Sie:

• Ein Register aller Service-Accounts mit Ownern und Zwecken aufbauen
• Tresorlösung und Rotation für technische Accounts durchsetzen
• Quartalsweise Reviews für alle Identitäten durchführen

Wann vereinheitlichte Governance nicht-menschlicher Identitäten der sicherere Weg ist

• NIS2-relevant (wichtige/essentielle Einrichtungen)
• Entwicklung/Betrieb von Hochrisiko-KI-Systemen (EU AI Act)
• Geplante oder laufende ISO 27001:2022-Zertifizierung, bei der privilegierte/technische Konten bereits spürbar aufwendig sind
• Umstellung auf NIST CSF 2.0 mit Bedarf nach echten, umfassenden Nachweisen
• Nicht-menschliche Identitäten übersteigen Menschen deutlich (Fakt bei den meisten modernen SaaS- und Cloud-Organisationen)

Die Frage lautet nicht "Brauchen wir Governance für nicht-menschliche Identitäten?", sondern "Wie lange können wir mit reinen Human-Tools noch improvisieren?"

Vereinheitlichte, AI-native IGA-Plattformen wie Iden beantworten das mit:

• Vollständiger Abdeckung aller Identitäten und Apps (auch Non-SCIM, No-API)
• Fein granuliertem Zugriff - bis hinunter auf Channel-, Repo- und Projektebene
• Kontinuierlicher Governance und Audit-Evidenz (EU AI Act, NIS2, ISO 27001, SOC 2 u. v. m.)

Für IT-Verantwortliche mit realen Fristen in der Compliance ist das der Unterschied zwischen Dauer-Feuerwehrmodus und echter Vorbereitung.

FAQ

1. Kümmern sich Aufsichtsbehörden wirklich um nicht-menschliche Identitäten?

Ja. NIST CSF 2.0, ISO 27001:2022 und NIS2 sprechen von "Identitäten, Credentials und privilegiertem Zugriff" - nicht nur von Menschen. Leitfäden benennen zunehmend technische/Service-Accounts explizit. Auditoren erwarten Governance von Service-Accounts und Agents standardmäßig.

2. Reicht SSO für NIS2 oder ISO 27001?

Nein. SSO ist notwendig, aber Auditoren verlangen:

• eine vollständige Inventur privilegierter/technischer Konten
• Least-Privilege- und zeitlich begrenzte Zugriffe
• belastbare Review-Nachweise (nicht nur Logs)
• Deprovisioning für alle Identitäten, nicht nur SSO-Konten

SSO-only-Ansätze übersehen typischerweise Long-Tail-SaaS, Legacy-Systeme und Machine Access - ideale Angriffspunkte für Auditoren.

3. Wie passen AI Agents in Identitätskategorien?

AI Agents sind nicht-menschliche Principals. Aus Governance-Sicht ähneln sie eher Service-Accounts oder Workloads als klassischen Usern. Sie benötigen:

• eine eindeutige Identität und Credentials
• klaren Owner und Scope
• minimal notwendige Berechtigungen
• Aufsicht und Monitoring

Agents einfach als "nur API Keys" zu behandeln, wird mit zunehmender Regulierung immer schwerer zu rechtfertigen.

4. Können wir Governance für nicht-menschliche Identitäten auf unseren bestehenden Stack "aufpflanzen", statt Plattformen zu wechseln?

Sie können skripten, landen aber bei:

• individuellen Playbooks, die nur wenige verstehen
• zusätzlichen Tools für Secrets, Agent-Governance, Service-Accounts
• fragmentierten Logs/Nachweisen, die vor Audits mühsam zusammengeführt werden müssen

Für schnell wachsende, regulierte Organisationen ist die Konsolidierung in eine einheitliche Plattform in der Regel schneller, einfacher und langfristig günstiger.

5. Wie hilft das bei Multi-Framework-Compliance?

Wenn Sie alle Identitäten konsistent mit kontinuierlichen Kontrollen behandeln, sind Sie im Vorteil für:

• SOC 2, CMMC, HIPAA, DORA und weitere Regelwerke

Zentrale Evidenz treibt Compliance über alle Frameworks hinweg. Das ist der ROI vereinheitlichter Governance nicht-menschlicher Identitäten: einmal sauber lösen, überall nachweisen.