Microsoft Entra ID | Neuer Revoke Sessions Button ab Februar 2026

Schluss mit dem Rätselraten im Incident Response Fall. Microsoft räumt endlich im Entra Admin Center auf und beseitigt eine historische Altlast, die Admins seit Jahren nervt: Die Unterscheidung zwischen „Revoke sessions“ und „Revoke multifactor authentication sessions“.

Ab Februar 2026 wird es nur noch einen Button geben. Das klingt nach einer kosmetischen UI-Änderung, ist aber ein längst überfälliger Schritt zur Konsolidierung der Identitätssicherheit.

Warum das wichtig ist, wie die Token-Mechanik dahinter funktioniert und warum du für echte Sicherheit trotzdem PowerShell brauchst, analysieren wir jetzt.

Das Problem: Zwei Buttons, halbe Sicherheit

Bisher musstest du im Entra Admin Center je nach Kontext entscheiden:

1. Revoke sessions: Invalidiert Refresh Tokens.
2. Revoke MFA sessions: Löscht den „MFA Claim“ aus dem Token, zwingt den User also zur erneuten MFA-Prüfung – aber nur, wenn Legacy (Per-User) MFA genutzt wurde.

Das Problem dabei: Im Stress eines Security Incidents (z. B. Account Compromise) willst du nicht darüber nachdenken, wie MFA bei diesem User technisch erzwungen wurde (Conditional Access vs. Legacy). Du willst den „Kill Switch“. Der alte „Revoke MFA“-Button war oft wirkungslos, wenn der User über moderne Conditional Access Policies gesteuert wurde.

Die Änderung ab Februar 2026:

Der neue „Revoke sessions“ Button übernimmt ab Februar 2026 alles. Er invalidiert alle User-Sessions und Refresh Tokens, unabhängig davon, ob MFA per Legacy-Richtlinie oder Conditional Access erzwungen wurde.

Was technisch passiert (The Token Lifecycle)

Um zu verstehen, warum dieser Button kritisch ist, müssen wir uns den Token-Lifecycle ansehen. Wenn du auf „Revoke“ drückst, passiert im Hintergrund Folgendes:

1. Refresh Token (RT) Invalidation: Der User besitzt ein langlebiges Refresh Token (oft 90 Tage rollierend). Der Button setzt das RefreshTokensValidFromDateTime-Attribut des User-Objekts auf den aktuellen Zeitstempel.
   
2. Access Token (AT) Survival: Das Access Token (Lebensdauer ca. 1 Stunde) ist stateless. Der Button kann dieses Token nicht sofort zerstören. Der Client hat also theoretisch noch bis zu 59 Minuten Zugriff.
   
3. Continuous Access Evaluation (CAE): Hier kommt die moderne Architektur ins Spiel. Dienste wie Exchange Online, SharePoint und Teams unterstützen CAE. Wenn du die Session widerrufst, sendet Entra ID ein Signal an diese Workloads. Dank CAE wird das Access Token fast in Echtzeit (near real-time) abgelehnt, auch wenn es laut Zeitstempel noch gültig wäre.

Hinweis: Damit der „Kill Switch“ wirklich sofort wirkt, müssen deine Clients CAE-fähig sein (moderne Outlook/Teams Clients sind das) und CAE darf nicht per Conditional Access deaktiviert sein.

Automation: Warum Klicken für Amateure ist

Ein Button im Web-Portal ist nett für Ad-hoc-Maßnahmen. In einer professionellen Incident Response (IR) Architektur muss dieser Schritt jedoch skriptbasiert erfolgen. Ein kompromittierter Account erfordert mehr als nur Session Revocation.

Der Befehl für den Session Revoke im Microsoft Graph PowerShell SDK lautet:

Revoke-MgUserSignInSession -UserId <UserPrincipalName>

Dieser Befehl führt exakt die Logik aus, die der neue Button nun im UI abbildet: Er invalidiert die Refresh Tokens und triggert das CAE-Event.

Die Lizenz-Falle: Conditional Access

Der ursprüngliche Artikel der Tech Community weist zu Recht auf einen wunden Punkt hin: Microsoft drängt massiv weg von „Legacy Per-User MFA“ hin zu Conditional Access (CA). Technisch ist das absolut richtig, da CA kontextbasiert (Gerätestatus, Standort, Risiko) entscheidet und nicht statisch ist.

Das Aber: Conditional Access erfordert Entra ID P1 Lizenzen (enthalten in Microsoft 365 Business Premium oder E3/E5).

Wer noch auf Office 365 E3 (ohne EMS) oder Business Standard setzt, wird hier zur Kasse gebeten, um Sicherheitsstandards nutzen zu können, die eigentlich Commodity sein sollten. Dennoch: Aus Architektensicht ist P1 heute die „Cost of doing business“ für jede ernsthafte Identitätsstrategie.

Abgrenzung: Session-Kill vs. Methoden-Reset

Hier entsteht oft das größte Missverständnis in der Praxis. Der kommende „Revoke sessions“-Button (und sein Vorgänger) löst nur ein Problem: Den Zugriff. Er löst nicht das Problem einer kompromittierten MFA-Methode.

Wenn ein User sein Smartphone verliert oder Opfer eines SIM-Swaps wird, ist der „Revoke sessions“-Button nutzlos, wenn du nicht auch die registrierte Methode zurücksetzt. Denn: Der Angreifer besitzt den zweiten Faktor. Nach dem Session-Revoke meldet er sich einfach neu an und bestätigt die MFA-Anfrage erneut.

Du musst daher zwei Aktionen strikt trennen:

1. Revoke Sessions: Zwingt zur Neuanmeldung (Token Invalidierung).
2. Require Re-register MFA: Zwingt den User, den MFA-Prozess (z. B. QR-Code Scan) komplett neu zu durchlaufen.

Im Entra Admin Center findest du diese Funktion unter Authentication methods > Require re-register multifactor authentication.

Fazit: Weniger Verwirrung, mehr Sicherheit

Die Konsolidierung der Buttons ist keine Revolution, sondern eine notwendige Evolution. Sie eliminiert eine Fehlerquelle im operativen Betrieb (SecOps). Wenn ein Admin „Revoke“ drückt, muss der User rausfliegen – ohne Wenn und Aber.

Deine To-Dos:

1. Playbooks prüfen: Aktualisiere deine Incident Response Dokumentation. Der Unterscheid zwischen MFA-Reset und Session-Reset entfällt.
2. Skripte validieren: Stelle sicher, dass deine Offboarding- und Emergency-Skripte Revoke-MgUserSignInSession nutzen und nicht auf veraltete Module (AzureAD) setzen.
3. CAE prüfen: Kontrolliere in deinen Conditional Access Policies, ob Continuous Access Evaluation aktiviert ist, damit der Revoke auch wirklich sofort wirkt.

This post is also available in: