Guide

Revoke sessions vs disable user in Entra ID: what each one actually stops

Both buttons sit on the same user page in the Entra admin center, they stop different things, and neither one ends an access token that has already been issued.

An admin sees a suspicious sign-in, opens the user in the Entra admin center, clicks Revoke sessions, and ten minutes later the attacker is still reading mail. The button did exactly what Microsoft documents; it just does less than most people expect. This guide compares revoke sessions with disabling the account: what each changes, what stops and when, what keeps working, what you can undo, and how to prove the result from Microsoft's own data. It is one of the Orbitra guides on privileged identity response.

The short answer

Revoke sessions invalidates the user's refresh tokens and browser session cookies, so every app has to sign in again; it does not block a new sign-in with valid credentials. Disabling the account blocks new sign-ins and new tokens for every application tied to Entra ID. Neither ends an access token already held by an app that does not support Continuous Access Evaluation (CAE); that token works until it expires, about an hour by default. Microsoft's order for a suspected compromise is disable first, then revoke, then disable the user's registered devices.

What revoke sessions actually does

The button calls POST /users/{id}/revokeSignInSessions. Microsoft's description: it "Invalidates all the refresh tokens issued to applications for a user (and session cookies in a user's browser), by resetting the signInSessionsValidFromDateTime user property to the current date-time." It moves one timestamp on the user object. Any refresh token or session cookie issued before that timestamp is rejected the next time a client presents it, forcing the user "to sign in again to all applications that they consented to previously, independent of device."

Two details matter during an incident. Microsoft notes that "there might be a small delay of a few minutes before tokens are revoked." And the method returns a 2xx response code when the timestamp has been reset; the reference page never says a success code means sessions have ended. Treat it as an acknowledgment and read the state back (recipe below). The least privileged Graph permission is User.RevokeSessions.All; in PowerShell it is Revoke-MgUserSignInSession -UserId <id>. Helpdesk Administrator can invalidate refresh tokens only for non-administrators, so revoking an administrator's sessions needs a higher role.

What disable user actually does

Clearing Account enabled is PATCH /users/{id} with the body {"accountEnabled": false}. After that, "the user can't gain new tokens for any application tied to Microsoft Entra ID." A disabled account cannot sign in again even if the attacker holds the password and can pass MFA, which is exactly the gap revoke leaves open. The least privileged permissions are User.EnableDisableAccount.All plus User.Read.All. User Administrator can disable non-admin users; administrator accounts need Privileged Authentication Administrator. Disable does not by itself invalidate tokens already issued: "The elapsed time between revocation and the user losing their access depends on how the application is granting access." That is why the emergency procedure runs both actions.

Side by side

QuestionRevoke sessionsDisable user
What changes in the directorysignInSessionsValidFromDateTime is reset to nowaccountEnabled is set to false
What stops, after a few minutesRefresh tokens and browser session cookies are rejected; every app must sign in againNew sign-ins and new token issuance for every Entra-tied application
What the attacker can still doSign in again with valid credentials and MFA; use unexpired access tokens in non-CAE appsUse unexpired access tokens in non-CAE apps and any session token an application issued on its own
How long residual access lastsUntil the access token expires, about an hour (60 to 90 minutes by default); CAE-capable clients against Exchange Online, SharePoint Online, and Teams lose access within minutes, up to about 15Same windows; disable is also a CAE critical event
Side effects on the personEvery app on every device asks for sign-in again; they can sign back inCannot work until re-enabled; Entra app provisioning, if used, deprovisions them from connected apps on its 20 to 40 minute cycle
Side effects on automationAnything authenticating as this user stops at its next token refreshAnything authenticating as this user stops at its next sign-in
Service principalsUntouched; different object typeUntouched; different object type
ReversibleNo; the timestamp cannot be moved back. Users simply sign in againYes; set accountEnabled back to true
What to logWho acted, user id, request time, response code, and signInSessionsValidFromDateTime read back afterwardsWho acted, user id, request time, response code, and accountEnabled read back afterwards

Why the attacker is still active after you click Revoke sessions

Three token types are in play. Refresh tokens are what revoke invalidates. Access tokens are the short-lived tokens apps present to a resource: "The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average)." Session tokens belong to the application, and "Microsoft Entra ID can't directly revoke a session token issued by an application."

Continuous Access Evaluation shortens the window. Both "User Account is deleted or disabled" and "Administrator explicitly revokes all refresh tokens for a user" are CAE critical events. When client and resource both support CAE, Entra sends the resource a revocation event and the resource rejects the unexpired token with a 401+ claim challenge. Microsoft's stated goal is "near real time," and the same sentence warns that "latency of up to 15 minutes might be observed because of event propagation time." The subscribing workloads are Exchange Online, SharePoint Online, and Teams. For everything else, "the user loses access when the access token expires." So after disable plus revoke: Outlook, OneDrive, and Office desktop drop within minutes, Teams mostly does, other apps holding a token keep it for up to about 90 minutes, and a web app with its own session cookie keeps that session until the app ends it.

Which order to run them

Microsoft's emergency revocation procedure for cloud-only users: clear Account enabled and save, then select Revoke sessions on the user's Overview page. Scripted, in the same order: Update-MgUser -UserId <id> -AccountEnabled:$false, then Revoke-MgUserSignInSession -UserId <id>, then Update-MgDevice -DeviceId <id> -AccountEnabled:$false for each registered device. Disable comes first because it closes the door revoke leaves open. For hybrid tenants Microsoft adds disabling the on-premises account and resetting the password twice in Active Directory against pass-the-hash. Session revocation is not supported for external and guest users, so for a guest, disable is the lever you have.

If the account holds Global Administrator or another privileged role, read the compromised admin account guide first and confirm another administrator or an emergency access account can still sign in before you disable.

Reversibility: what you can undo

  • Disable user is a clean undo. Setting accountEnabled back to true restores sign-in; nothing about the user's tokens or methods changed.
  • Revoke sessions cannot be undone. No call makes the old refresh tokens valid again. The cost is low: users sign in again.
  • Password reset is recoverable, not reversible. The user gets a new password; the old one no longer works. It is also a CAE critical event.
  • Device wipe is neither: "Data on the device can't be recovered after a wipe."

Record which of these are permanent in your runbook before an incident, so the person approving at two in the morning is not working it out under pressure.

How to verify it worked

A success code from either call is not evidence that access ended. Three checks against Microsoft's own data:

  1. Read the user object back. Confirm accountEnabled is false and signInSessionsValidFromDateTime is at or after the time you acted. Record both values with the read time; that read, not the button click, is your containment timestamp.
  2. Filter the sign-in logs to this user after that timestamp. Interactive sign-ins should fail because the account is disabled. Successful non-interactive sign-ins mean a client presented a token that was still valid; watch for them to stop within about 90 minutes, sooner on CAE workloads. A successful interactive sign-in after the revoke means the account was not disabled and someone re-authenticated with the credentials.
  3. Review the authentication methods list. Attackers commonly register their own phone number or authenticator app early. Remove any method the user does not recognize before you re-enable the account, otherwise re-enabling hands access straight back.

Keep four times together: signal observed, plan ready, action submitted, provider verified. That record is what an insurer or auditor asks for later, and it shows how long the residual window really was in your tenant. See containment verification for the general pattern.

Where Orbitra fits

Orbitra runs disable and revoke as governed response actions from an allowlisted catalog. It revokes refresh tokens and blocks new token issuance now; existing access tokens expire within their lifetime, sooner for CAE-enabled apps, and propagation is shown as estimated until it is observed. Orbitra independently re-reads Microsoft after supported response actions to verify the final state, and Orbitra tells you which steps are permanent before you approve them. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. Each incident carries the four timestamps above in its evidence receipt. See how it works.

Does revoke sessions sign out mobile Outlook?

Yes, within minutes rather than at the next token expiry. Outlook on iOS and Android is listed as supported for CAE against Exchange Online and SharePoint Online, and an administrator revoking all refresh tokens is a CAE critical event, so expect a sign-in prompt within about 15 minutes at most. If the account is disabled, that prompt fails; if you only revoked, a person with the password and MFA signs straight back in.

Does revoke sessions affect Teams?

Teams is one of the three workloads that subscribe to CAE critical events, so Teams clients lose access to chat, files, and calendar within minutes of a revoke or disable. Microsoft lists Teams on every platform as "Partially supported" rather than "Supported" and notes that Teams is made up of multiple services, so plan on the same window of up to 15 minutes and confirm in the sign-in logs.

Does revoke sessions touch service principals?

No. The method is defined on the user object, and a service principal is a different object type with its own tokens. Neither action changes what an application can do with its own credentials. If the compromise involves an OAuth app or an app secret, the consent grant, app role assignment, or credential has to be removed on the application side; see non-human identity and OAuth consent response.

Does it need Entra ID P1?

Microsoft's emergency revocation procedure and the Graph reference describe both actions in terms of directory roles and Graph permissions, not licenses. The CAE critical-event path that shortens the residual window "doesn't rely on Conditional Access policies so it's available in any tenant." For teams on Business Premium or E3, see identity response on Business Premium and E3, and the privileged identity response glossary entry for where these two actions sit in a wider response.

Sources

See it on your tenant

Find the privilege that can reach your critical systems.

Get a privilege exposure review Guides