Microsoft Entra ID | New Revoke Sessions Button from February 2026

No more guesswork in the incident response case. Microsoft is finally cleaning up the Entra Admin Center and eliminating a historical legacy that has been annoying admins for years: The distinction between “Revoke sessions” and “Revoke multifactor authentication sessions”.

From February 2026 , there will be only one button. This sounds like a cosmetic UI change, but it’s a long overdue step towards consolidating identity security.

Why this is important, how the token mechanic behind it works and why you still need PowerShell for real security, we will now analyze.

The problem: Two buttons, half security

Previously, you had to decide in the Entra admin center depending on the context:

1. Revoke sessions: Invalidates refresh tokens.
2. Revoke MFA sessions: Deletes the “MFA claim” from the token, forcing the user to check MFA again – but only if legacy (per-user) MFA has been used.

The problem with this is that in the stress of a security incident (e.g. account compromise), you don’t want to think about how MFA was technically enforced on this user (conditional access vs. legacy). You want the “kill switch”. The old “Revoke MFA” button was often ineffective when the user was controlled via modern conditional access policies.

The change from February 2026:

The new “Revoke sessions” button will take over everything from February 2026. It invalidates all user sessions and refresh tokens, regardless of whether MFA was enforced via legacy policy or conditional access.

What happens technically (The Token Lifecycle)

To understand why this button is critical, we need to look at the token lifecycle. When you press “Revoke”, the following happens in the background:

1. Refresh Token (RT) Invalidation: The user has a long-lasting refresh token (often 90 days rolling). The Button sets the RefreshTokensValidFromDateTimeattribute of the User object to the current timestamp.
   
2. Access Token (AT) Survival: The access token (lifetime approx. 1 hour) is stateless. The button cannot destroy this token immediately. Theoretically, the client still has access for up to 59 minutes.
   
3. Continuous Access Evaluation (CAE): This is where modern architecture comes into play. Services such as Exchange Online, SharePoint, and Teams support CAE. When you revoke the session, Entra ID sends a signal to those workloads. Thanks to CAE, the access token is rejected almost in real time (near real-time), even if it would still be valid according to the time stamp.

Note: For the “kill switch” to really work immediately, your clients must be CAE-capable (modern Outlook/Teams clients are) and CAE must not be disabled via conditional access.

Automation: Why clicking is for amateurs

A button in the web portal is nice for ad-hoc measures. In a professional incident response (IR) architecture, however, this step must be script-based. A compromised account requires more than just session revocation.

The command for the Session Revoke in the Microsoft Graph PowerShell SDK is:

Revoke-MgUserSignInSession -UserId <UserPrincipalName>

This command executes exactly the logic that the new button now maps in the UI: It invalidates the refresh tokens and triggers the CAE event.

The License Trap: Conditional Access

The original article by the Tech Community rightly points to a sore point: Microsoft is massively pushing away from “Legacy Per-User MFA” to Conditional Access (CA). Technically, this is absolutely correct, as CA makes context-based decisions (device status, location, risk) and is not static.

The but: Conditional Access requires Entra ID P1 licenses (included in Microsoft 365 Business Premium or E3/E5).

If you still rely on Office 365 E3 (without EMS) or Business Standard, you will be asked to pay here in order to be able to use security standards that should actually be a commodity. Nevertheless, from an architect’s point of view, P1 is now the “cost of doing business” for any serious identity strategy.

Differentiation: Session Kill vs. Method Reset

This is often where the biggest misunderstanding in practice arises. The upcoming “Revoke sessions” button (and its predecessor) solves only one problem: access. It doesn’t solve the problem of a compromised MFA methodology.

If a user loses their smartphone or becomes a victim of a SIM swap, the “Revoke sessions” button is useless if you don’t also reset the registered method. Because: The attacker has the second factor. After the session revoke, he simply logs in again and confirms the MFA request again.

You must therefore strictly separate two actions:

1. Revoke Sessions: Forces you to log in (token invalidation).
2. Require Re-register MFA: Forces the user to go through the MFA process (e.g. QR code scan) from scratch.

In the Entra Admin Center, you can find this feature under Authentication methods > Require re-register multifactor authentication.

Conclusion: Less confusion, more security

The consolidation of buttons is not a revolution, but a necessary evolution. It eliminates a source of error in operational operations (SecOps). If an admin presses “Revoke”, the user has to be kicked out – without ifs and buts.

Your to-dos:

1. Check playbooks: Update your incident response documentation. The difference between MFA reset and session reset is eliminated.
2. Validate scripts: Make sure your offboarding and emergency scripts Revoke-MgUserSignInSession are used and don’t rely on legacy modules (AzureAD).
3. Check CAE: Check in your Conditional Access Policies whether Continuous Access Evaluation is enabled so that the Revoke really takes effect immediately.

This post is also available in: Deutsch English