Microsoft beschreibt im Entra-Blog eine wichtige Neuerung für automatisierte Zugriffe: Zugriffstokens von Dienstprinzipalen lassen sich mit Continuous Access Evaluation schneller unwirksam machen, wenn eine Workload-Identität gesperrt, gelöscht oder als riskant erkannt wird. Für KMU ist das relevant, weil Skripte, Synchronisationen und Integrationen oft mit weitreichenden App-Berechtigungen arbeiten. Wird ein Secret oder Token missbraucht, zählt nicht nur die Rotation des Geheimnisses, sondern auch die Frage, wie lange ein bereits ausgestelltes Bearer Token noch nutzbar bleibt.
Warum Workload-Identitäten jetzt in den Fokus rücken
Microsoft stuft Workload-Identitäten anders ein als Benutzerkonten: Sie können keine MFA durchführen, haben häufig keinen formalen Lebenszyklus und ihre Anmeldeinformationen müssen irgendwo gespeichert werden. Genau deshalb sind Service Principals ein typischer blinder Fleck in kleineren Microsoft-365-Umgebungen. Ein Benutzerkonto wird deaktiviert, ein Gerät isoliert, ein Passwort zurückgesetzt. Bei einer App-Identität bleibt dagegen oft unklar, welche Automatisierung dahintersteht, welche Berechtigungen vergeben wurden und welche Tokens noch im Umlauf sind.
Der neue Microsoft-Entra-Beitrag vom 26. August 2026 zeigt deshalb keinen allgemeinen Komfortschalter, sondern einen Baustein für Incident Response. Wer kritische Automatisierungen über Microsoft Entra ID und Microsoft Graph betreibt, sollte wissen, ob diese Clients CAE-fähige Tokens anfordern und ob die Sign-in-Logs das auch zeigen.
Was CAE bei Dienstprinzipalen ändert
Microsoft Learn beschreibt den Ablauf klar: Der Dienstprinzipal fordert ein Access Token für Microsoft Graph an und erklärt dabei die Client Capability cp1. Entra ID bewertet passende Conditional-Access-Richtlinien und stellt ein CAE-fähiges Token aus. Wenn später ein unterstütztes Widerrufsereignis eintritt, weist Microsoft Graph das Token zurück und liefert eine 401-Antwort mit Claims Challenge. Der Client muss darauf reagieren und ein neues Token anfordern; erst dann bewertet Entra ID die Bedingungen erneut.
- Ohne explizite
cp1-Angabe erhält die Anwendung laut Microsoft keine CAE-Tokens und keine Claims Challenges. - CAE-Tokens für Workload-Identitäten können bis zu 24 Stunden gültig sein, werden aber kontinuierlich gegen unterstützte Ereignisse geprüft.
- Für Workload-Identitäten nennt Microsoft derzeit Microsoft Graph als unterstützten Ressourcenanbieter.
Welche Auslöser Tokens sofort unwirksam machen
Der Blog nennt drei Widerrufsereignisse: Der Service Principal wird als hohes Risiko erkannt, deaktiviert oder gelöscht. In Microsoft Learn stehen dieselben Ereignisse für CAE bei Workload-Identitäten. Hohes Risiko kann unter anderem aus Microsoft Entra Threat Intelligence, verdächtigen Anmeldungen, geleakten Anmeldeinformationen, auffälligem Graph-API-Verkehr oder ungewöhnlicher Service-Principal-Aktivität entstehen. Besonders wichtig ist die Kombination aus technischer Token-Fähigkeit und Richtlinie. Im Blog weist Microsoft darauf hin, dass ein Risikosignal allein nicht genügt, wenn ein Angreifer weiterhin Client-ID und Secret besitzt und sich direkt ein neues Token holen kann. Für risikobasierte Sperren braucht es daher eine passende Conditional-Access-Regel für Workload-Identitäten.
Eine manuelle Deaktivierung des Service Principals beschreibt Microsoft im Blog als schnellen Kill-Switch für CAE-fähige Tokens. Ob ein Test wirklich CAE nutzt, gehört in die Service-Principal-Sign-in-Logs; dort zeigt das Feld „Continuous access evaluation“, ob CAE beteiligt war.
Grenzen, die vor der Umsetzung wichtig sind
CAE für Workload-Identitäten ist kein Ersatz für saubere App-Governance. Microsoft dokumentiert mehrere Grenzen: Unterstützt werden einzelne, im eigenen Tenant registrierte Single-Tenant-Service-Principals. Multitenant-Apps, Drittanbieter-SaaS und Managed Identities sind für CAE bei Workload-Identitäten nicht im Umfang. Außerdem werden Conditional-Access-Richtlinien nicht wirksam, wenn ein Service Principal nur über eine Gruppe in die Richtlinie kommt; die Zuweisung muss direkt auf die Workload-Identität erfolgen.
Für kleine IT-Teams ist diese Einschränkung hilfreich, weil sie den Prüfpfad begrenzt: Es geht zuerst um die wenigen Automatisierungen mit Microsoft-Graph-Zugriff und hohem Schadenpotenzial, nicht um jede technische Identität im Tenant.
Konkrete nächste Schritte für KMU
Ein sinnvoller Einstieg ist keine große Neustrukturierung, sondern eine belastbare Liste der App-Identitäten, die produktiv genutzt werden. Danach lässt sich priorisieren, welche Clients CAE-fähig werden müssen und welche Richtlinien im Report-only-Modus getestet werden sollten.
- Inventarisieren Sie Service Principals mit Microsoft-Graph-Berechtigungen und ordnen Sie Besitzer, Zweck und Secret-Ablaufdatum zu.
- Prüfen Sie bei Eigenentwicklungen, ob der Tokenabruf die
cp1-Client-Capability setzen und Claims Challenges verarbeiten kann. - Kontrollieren Sie in den Service-Principal-Sign-in-Logs, ob CAE bei Testanmeldungen tatsächlich angezeigt wird.
- Testen Sie risikobasierte oder standortbasierte Regeln für ausgewählte Workload-Identitäten zunächst im Report-only-Modus.
- Dokumentieren Sie einen Kill-Switch: Wer darf welchen Service Principal deaktivieren, und welche Geschäftsprozesse fallen dann aus?
Offizielle Microsoft-Quellen
- Microsoft Entra Blog: Instant revocation of service principal bearer tokens with CAE
- Microsoft Learn: Continuous access evaluation for workload identities
- Microsoft Learn: Securing workload identities with Microsoft Entra ID Protection
- Microsoft Learn: Conditional Access for workload identities
Welche App-Identitäten in Ihrem Tenant ein echtes Risiko darstellen und wie Sie Reaktionswege ohne Lizenzberatung sauber planen, klären wir in einem Microsoft Security Assessment – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
