Leaver Access Cutoff: Revoke Refresh Tokens Fast

A leaver access cutoff that only disables the Entra ID account leaves a gap most IT teams don't realize they have. Refresh token revocation, not the disable toggle, is what actually ends a live session. Until that token is revoked, someone with an already-open laptop, a signed-in phone, or a cached mobile app can keep working for hours after their account shows as disabled in the admin center.

This isn't a theoretical edge case. It's how Entra ID's token model works by design, and it catches out plenty of teams who treat "disable the account" as the finish line for the last working day. This article explains exactly what disabling does and doesn't do, how to force a real cutoff, and where the remaining gaps sit even after you've revoked everything Microsoft lets you revoke.

Why disabling the account isn't the same as ending access

accountEnabled: false is a directory-level flag. It tells Entra ID to reject any new authentication attempt for that account. It does nothing to sessions and tokens that were issued before you flipped the switch.

That distinction matters because of how modern authentication actually works:

• A user signs in once and receives a short-lived access token (typically valid around an hour) and a longer-lived refresh token (often valid for 90 days or more, depending on your configuration).
• Every time the access token expires, the client silently uses the refresh token to get a new one, without the user noticing and without a new sign-in event that checks accountEnabled.
• Disabling the account stops the next interactive sign-in. It does not stop that silent refresh cycle already in motion on a device that's already authenticated.

In practice this means a disabled leaver can stay signed into Outlook, Teams, and SharePoint on a laptop that was open when they left, sometimes for the remaining lifetime of the refresh token, unless something explicitly revokes it.

The fix: revoke sign-in sessions, not just the account

Microsoft Graph exposes a revokeSignInSessions action for exactly this reason. It invalidates the user's refresh tokens (and by extension, session cookies tied to them), forcing every client to re-authenticate the next time its access token expires. Combined with Continuous Access Evaluation (CAE), which Microsoft has been extending to more workloads, the effect can be closer to real-time for supported apps: a disabled account can lose access to Exchange Online, SharePoint, and Teams within minutes instead of waiting for the access token to naturally expire.

What a real leaver cutoff needs to include

Treat the last working day as a sequence, not a single click. Four actions need to happen together, and in this rough order:

1. Disable the account. Stops any new interactive sign-in immediately.
2. Revoke refresh tokens and sessions via Microsoft Graph (revokeSignInSessions) or the equivalent PowerShell cmdlet. This is the step that actually ends what's already open.
3. Reset or remove MFA methods. If a device or authenticator app was compromised or simply not returned, this prevents it from being reused to re-authenticate once the account is re-enabled or an attacker resets a password.
4. Revoke app passwords and service principal credentials if the leaver had any personal app registrations or client secrets tied to their identity.

Why the order matters

Disabling and revoking sessions belong together, ideally triggered by the same automated event, because doing one without the other leaves an obvious gap: disable-only leaves live sessions running, revoke-only without disabling means the account can simply sign in again a minute later. Neither action alone is a cutoff. Together, within the same script or runbook, they are.

Where tokens keep living even after you revoke

Revoking sign-in sessions in Entra ID is necessary, but it doesn't reach everything. A few places require separate attention:

Cached tokens in mobile and desktop apps

Some native apps cache tokens more aggressively than the browser and may not immediately respect a server-side revocation until they attempt their next network call. If a leaver's phone was never returned, revoking the session stops new API calls succeeding, but a well-timed offline action inside an already-open app can still slip through until the client next tries to talk to the server.

On-prem Active Directory: Kerberos doesn't ask Entra ID

If your leaver also had on-prem AD access, a Kerberos ticket issued before the account was disabled remains valid until it expires (typically up to 10 hours by default) or the KDC is told to invalidate it. Disabling the AD account stops new ticket issuance; it does not recall tickets already in someone's cache. For genuinely sensitive accounts, forcing a Kerberos ticket refresh or resetting the account password (which changes the key material tickets are built on) closes this gap.

Conditional access and remembered devices

If a device was marked as "remembered" for MFA, or falls under a conditional access exclusion, double-check that the leaver's device doesn't retain any special trust status that outlives the account itself.

The table teams keep in their heads (and should write down)

Session type	What disabling the account does	What actually revokes it
New interactive sign-in	Blocked immediately	N/A, already blocked
Existing Entra ID session (access token)	Nothing until it expires (~1 hour)	Revoke sign-in sessions / CAE
Refresh token	Nothing until natural expiry (days to months)	revokeSignInSessions via Graph
On-prem Kerberos ticket	Nothing until natural expiry (up to ~10h)	Password reset / KDC ticket invalidation
Cached mobile app token	Delayed until next server call	Revoke session + app-level sign-out where supported
Remembered MFA device	Not affected	Manual removal of device trust

Building the cutoff into the leaver trigger, not a manual step

The reliability problem with this whole sequence isn't that any single action is hard. revokeSignInSessions is one Graph call. The problem is remembering to run it, every time, on the actual last working day, and not three days later when someone finally works through a ticket queue.

That's why this belongs in the same automated trigger as the rest of leaver processing rather than a manual step on a checklist. When a leaver event fires, whether from an HR status change or a manually flagged departure, the same runbook that disables the account should call the session revocation endpoint in the same breath. This is a natural extension of attribute-based access automation: if group and role membership already unwinds automatically the moment someone's status attribute changes, revoking active sessions at the same trigger point closes the last window that "disable the account" leaves open. ServiceChanger's ABAC engine handles the access and membership side of that automation; the disable-and-revoke action itself runs through your own Azure Automation runbook or Graph script, triggered by the same status change.

Getting this into a single automated chain, rather than three separate people doing three separate things at three separate times, is what actually turns "we have an offboarding process" into "a leaver loses access within minutes, every time."

FAQ

Does disabling an Entra ID account end an active session immediately? No. Disabling blocks new sign-ins but does not invalidate an access token or refresh token that was issued before the account was disabled. You need to explicitly revoke sign-in sessions to force re-authentication.

How do I revoke a user's refresh tokens in Entra ID? Use the Microsoft Graph revokeSignInSessions action (or the equivalent Azure AD PowerShell / Microsoft Graph PowerShell cmdlet) against the user object. This invalidates their refresh tokens and forces every client to re-authenticate the next time an access token expires.

Does revoking sessions in Entra ID also end on-prem Active Directory access? No. Entra ID session revocation has no effect on Kerberos tickets already issued by an on-prem domain controller. Those need a separate step, typically a password reset, to invalidate the key material tickets rely on.

Can ServiceChanger revoke sessions and tokens automatically? ServiceChanger's ABAC engine automatically unwinds a leaver's group and role membership the moment their status attribute changes, which is the standing-access side of offboarding. The disable-and-revoke-session action itself is typically run through an Azure Automation runbook or Graph script triggered by that same status change, not a capability ServiceChanger performs directly.

Cutting off a leaver on paper and cutting them off in practice are two different things, and the gap between them is exactly the refresh token lifetime you never checked. Make revocation part of the same automated step as disabling the account, not a follow-up task. For more on tying leaver events to automatic access removal, see our access governance and security compliance overview, or browse more on offboarding and Entra ID on the blog.

Next step

Want a leaver's group and role access to unwind automatically the moment their status changes, so the manual part of offboarding shrinks to disable-and-revoke? Book a demo or read the access automation docs.