Stand: 30. September 2026
Unternehmen schützen Benutzerkonten heute mit MFA, Conditional Access und Identity Protection. Doch immer mehr Zugriffe werden gar nicht von Menschen ausgeführt. Anwendungen, CI/CD-Pipelines, Skripte, Container, Integrationen und AI Agents authentifizieren sich mit sogenannten Workload Identities. Genau diese nicht-menschlichen Identitäten werden zu einem der wichtigsten Sicherheitsfelder moderner Cloud-Umgebungen.
In Microsoft Entra zählen dazu insbesondere Applications, Service Principals und Managed Identities. Sie greifen teilweise rund um die Uhr auf APIs, Storage, Datenbanken oder andere Cloud-Dienste zu – und können keine klassische MFA-Challenge beantworten. Deshalb müssen ihre Risiken anders kontrolliert werden.
Warum Workload Identities gefährlich werden können
Ein Service Principal kann sehr mächtige Rechte besitzen. Wenn dessen Secret oder Zertifikat kompromittiert wird, kann ein Angreifer oft automatisiert und ohne Benutzerinteraktion auf Ressourcen zugreifen. Noch problematischer ist, dass solche Identitäten häufig keinen klaren Besitzer und keinen geregelten Lifecycle haben.
Microsoft nennt genau diese Punkte als zentrale Herausforderung: Workload Identities können keine MFA durchführen, speichern häufig Secrets und besitzen in vielen Organisationen keinen formalen Lebenszyklus.
Secrets sind das neue Passwortproblem
Client Secrets werden oft in CI/CD-Variablen, Konfigurationsdateien, Skripten oder Secret Stores hinterlegt. Ein Secret mit zwei Jahren Laufzeit ist technisch bequem, aber sicherheitlich ähnlich problematisch wie ein statisches Service-Account-Passwort.
Besser sind kurzlebige Tokens, Zertifikate, Managed Identities oder Workload Identity Federation. Das Ziel sollte sein, möglichst wenige dauerhaft gespeicherte Credentials zu besitzen.
Managed Identities bevorzugen
Für Azure-Ressourcen empfiehlt Microsoft Managed Identities, wenn die Zielplattform sie unterstützt. Dabei wird die Identität von Azure verwaltet, Credentials werden automatisch geschützt und rotiert. Anwendungen müssen kein eigenes Secret speichern.
Das reduziert nicht nur Diebstahlrisiken, sondern auch operative Probleme durch ablaufende Secrets. Trotzdem müssen Berechtigungen weiterhin nach Least Privilege vergeben werden.
Conditional Access für Workload Identities
Microsoft Entra erweitert Conditional Access auf bestimmte Service Principals. Dadurch können Zugriffe beispielsweise von nicht erlaubten Netzwerkstandorten blockiert oder risikobasiert eingeschränkt werden. Das ist ein wichtiger Schritt, weil maschinelle Identitäten damit stärker wie eigenständige Sicherheitsobjekte behandelt werden.
Nicht jede Identitätsart fällt unter dieselben Controls. Managed Identities und Multi-Tenant-Anwendungen haben andere Möglichkeiten und Grenzen. Deshalb ist ein vollständiges Inventar notwendig.
Risk Detection für nicht-menschliche Identitäten
Entra ID Protection kann bestimmte Workload Identities als riskant erkennen und entsprechende Signale bereitstellen. Unternehmen können diese Daten in Log Analytics, Event Hubs oder SIEM-Systeme exportieren und mit anderen Security Events korrelieren.
Besonders wertvoll wird dies bei ungewöhnlichen Token-Nutzungen, neuen Netzwerkstandorten oder verdächtigen Zugriffsmustern. Ein kompromittierter Service Principal verursacht oft keine sichtbare Benutzeranmeldung – klassische User-Reports reichen daher nicht aus.
AI Agents vergrößern die Zahl der Maschinenidentitäten
Mit Agentic AI steigt die Zahl nicht-menschlicher Identitäten weiter. Ein Agent benötigt Zugriff auf Dateien, APIs, Datenbanken und Tools. Wird dafür einfach ein mächtiger Service Principal wiederverwendet, entsteht eine gefährliche Konzentration von Rechten.
GORTNET hat bereits in AI Control Plane 2026 und AI Agents und Zero Trust beschrieben, warum Agent-Identitäten granular kontrolliert werden müssen.
Was Unternehmen jetzt inventarisieren sollten
Applications: Welche App Registrations existieren und wer ist Owner?
Service Principals: Welche Rechte besitzen sie und wann wurden sie zuletzt verwendet?
Credentials: Welche Secrets und Zertifikate laufen wann ab?
Managed Identities: Welche Ressourcen besitzen sie und welche Rollen sind zugewiesen?
Federation: Wo können statische Secrets durch Workload Identity Federation ersetzt werden?
Privileged Roles: Welche nicht-menschlichen Identitäten besitzen hochprivilegierte Rollen?
Lifecycle statt Einmal-Konfiguration
Eine sichere Workload Identity braucht einen Lebenszyklus: Beantragung, Genehmigung, Rechtevergabe, Monitoring, Rotation und Entfernung. Verwaiste Service Principals sind genauso gefährlich wie alte Benutzerkonten.
Fazit
Workload Identities sind 2026 ein Kernbestandteil moderner Cloud-Sicherheit. Unternehmen sollten Service Principals nicht als technische Nebensache behandeln, sondern als eigenständige Identitäten mit Risiko, Lifecycle und Monitoring. Je stärker Automatisierung und AI Agents wachsen, desto wichtiger werden kurze Credentials, Managed Identities, Federation, Least Privilege und risikobasierte Zugriffskontrollen.
Weiterführende Quellen
Microsoft Learn: Microsoft Entra Workload ID
Microsoft Learn: Securing workload identities
Microsoft Learn: Conditional Access for workload identities
Titelbild: Growtika / Unsplash
Autor: Salman Dolatpanah Gortlar