How to Revoke All Sessions for a Compromised User: Platform Steps and Proof It Worked

Clicking "revoke sessions" in one console does not log a compromised user out of everything: each platform ends only the sessions and tokens it issued, and app passwords, OAuth grants and desktop clients often survive. This guide is the hands-on procedure for one job: ending every live session a compromised workforce user holds, platform by platform, and then proving that none of them still works. It gives the exact admin actions, API calls, permissions and parameter defaults for the identity provider and the most common SaaS platforms, the credential types responders forget, and a verification method based on a recorded cut-off time. It is written for identity administrators and incident responders who already know why session theft matters. For the concepts, see the Token and Session Security Guide; for the D3FEND countermeasure behind this work, see D3-ST Session Termination; for the standards-based push to downstream apps, see the Global Token Revocation Guide.

Key takeaways

• Block re-entry before you revoke. Disable the account or reset the credential first, otherwise the attacker signs straight back in and receives fresh tokens.
• Read the defaults on every call. Okta's session clear leaves OAuth tokens alone unless you pass oauthTokens=true; Google's cookie reset does not sign out desktop apps; Entra cannot end sessions that applications issued themselves.
• Hunt the credentials that bypass sessions. App passwords, Google application-specific passwords, OAuth grants to third-party apps and API tokens the user created all keep working after a session revoke and need their own step.
• Know your residual window. Entra access tokens last one hour by default, CAE-capable sessions can carry tokens of up to 28 hours that rely on critical events, and some Salesforce services take up to 30 minutes to drop a token.
• Done means proven. Record the UTC cut-off for each platform and search the logs for any successful request from the user after it; one success means a layer was missed.

The order of operations

Revocation is a sequence, not a button. Doing the steps in the wrong order is the most common reason an attacker keeps access after a "full" revoke. The order below applies regardless of platform.

1. Clean the device: if the compromise came from malware on the user's machine (an infostealer, for example), isolate it through EDR first. Any new session the user creates on an infected device is stolen again.
2. Block re-entry: disable the account, or for lower-risk users reset the password from a clean admin workstation. In hybrid estates, Microsoft's procedure starts on-premises: disable the Active Directory account and reset the password twice, to reduce pass-the-hash risk where password replication is delayed.
3. Remove attacker persistence on the identity: MFA methods, registered devices and recovery details the user cannot account for. Leaving a planted MFA method means the next password reset hands the attacker a new login.
4. Revoke at the identity provider: sessions, refresh tokens and, where the platform separates them, OAuth grants.
5. Revoke at each downstream application: every SaaS app that keeps its own session, using its own admin action or API, or a global token revocation push where the app supports it.
6. Revoke the side doors: app passwords, application-specific passwords, personal API tokens, third-party app grants and mobile device sync.
7. Record and verify: note the UTC time each step completed, then run the checks in the verification section.

Steps 4 to 6 can run in parallel across administrators, but none of them should start before step 2 is complete. Re-enabling the account comes last, after verification and after the user has re-enrolled MFA on a clean device.

What each layer needs

A compromised user typically holds several kinds of live credential at once. This table is the inventory to work through; each row is a separate action.

The last row is the one most often skipped. After the 2023 Okta support system breach, the Cloudflare breach followed because one service token and three service accounts exposed in it were not rotated, on the mistaken belief that they were unused. A user's compromise has the same shape: anything the user minted, or could see, is in scope.

Platform steps

Platforms are listed alphabetically. Each section gives the documented action, its scope and what it leaves behind, checked against the vendor's documentation in November 2026. These are customer-side actions under the shared responsibility model; confirm current behaviour in each vendor's documentation before relying on it.

Google Workspace

• Sessions: in the Admin console, go to Menu, Directory, Users, open the user, then Security, Sign-in cookies, Reset. This needs the User management privilege. Google states it signs the user out of browsers and mobile devices. Suspending the user resets sign-in cookies automatically, so suspension is the stronger first move for a confirmed compromise.
• What it leaves: Google documents that resetting sign-in cookies does not sign the user out of apps such as Gmail and Google Drive for desktop. For managed computers and Assistant-enabled smart home devices, use Devices, Endpoints, select the devices, More, Sign Out User (needs the Shared device settings privilege). Wiping a mobile device requires Google endpoint management.
• Side doors: the Directory API exposes the user's application-specific passwords (asps resource, with lastTimeUsed) and the OAuth tokens the user has issued to third-party apps (tokens resource, keyed by clientId). List both, record them as evidence, then delete: tokens.delete removes all access tokens the user issued to that one application. The same third-party access can be revoked in the Admin console under the user's security settings.

Further hardening: see the Google Workspace Security Guide.

Microsoft Entra ID

• Sessions: in the Entra admin centre, go to Entra ID, Users, All users, open the user, clear Account enabled under Account status and save, then select Revoke sessions on the Overview page. Scripted, with Microsoft Graph PowerShell: Update-MgUser -UserId $id -AccountEnabled:$false, then Revoke-MgUserSignInSession -UserId $id, then disable each registered device with Get-MgUserRegisteredDevice piped to Update-MgDevice -AccountEnabled:$false. Microsoft lists User Administrator for standard users, Privileged Authentication Administrator for admin accounts and at least Cloud Device Administrator for devices.
• What it leaves: access tokens stay valid until expiry, one hour by default. Microsoft is explicit that Entra cannot directly revoke a session token issued by an application; the app must do it. Continuous Access Evaluation narrows the gap for Exchange Online, SharePoint Online and Teams: disabling the user, resetting the password and revoking refresh tokens are all critical events, with Microsoft noting latency of up to 15 minutes. The trade-off is that CAE sessions can carry tokens valid for up to 28 hours, so a client or resource that does not honour CAE is exposed for longer than the one-hour default.
• Side doors: app passwords, used where per-user MFA is enforced for non-browser apps, are not revoked when the password is reset. Microsoft's guidance is for the user to delete them and create new ones; the admin-side control is a Conditional Access policy blocking legacy authentication, which stops existing app passwords working. Check OAuth consents granted during the exposure window, and Intune for a managed device wipe or selective wipe of corporate data. Provisioning to downstream apps typically runs every 20 to 40 minutes, so trigger app deprovisioning manually for priority accounts.

Investigation detail: see How to Investigate a Compromised Entra ID Account and the Entra ID Security Guide.

Okta

• Sessions: call DELETE /api/v1/users/{userId}/sessions?oauthTokens=true or use the equivalent clear sessions action in the Admin Console. Okta's API reference states that oauthTokens defaults to false, so without it the user's OpenID Connect and OAuth refresh and access tokens are left in place. forgetDevices defaults to true in Identity Engine and false in Classic Engine; set it explicitly so remembered factors are cleared. A successful call returns 204.
• What it leaves: the operation does not clear sessions that web or native applications created for themselves. Those need each application's own action, or Universal Logout where the app supports it (see the Global Token Revocation Guide).
• Side doors: DELETE /api/v1/users/{userId}/grants (scope okta.users.manage) revokes all grants for the user; list them first with the user grants list operation so you have evidence of what was consented. If the user is an Okta administrator, also check for API tokens they created; see How to audit Okta API tokens and service apps.

Further hardening: see the Okta Security Hardening Guide.

Salesforce

• Sessions: in Setup, use Quick Find to open Session Management, filter to the user and select Remove for each active session. Session types include UI, Content, API and Visualforce, and the list includes sessions tied to JWT-based access tokens. Salesforce states the user must log in again after removal.
• What it leaves: for most services the associated access token is revoked immediately, but for some it can take up to 30 minutes. Record that as the residual window for the org.
• Side doors: connected app OAuth tokens and integration users are reviewed separately; see How to review Salesforce connected apps and integration users and the Salesforce Security Guide.

Slack

• Sessions: the Web API method admin.users.session.reset wipes all valid sessions on all devices for a given user and resets the Slack client's local cache. It needs a user token with the admin.users:write scope and is available on the Enterprise plan. By default it resets every session; mobile_only and web_only narrow it, and neither should be set during a compromise.
• What it leaves: bot tokens, user tokens and app installations the account created are separate credentials. Review apps installed or authorised by the user during the exposure window.
• Side doors: see the Slack Tokens Security Guide and the Slack Enterprise Security Guide.

For developer platforms the user could reach, treat personal access tokens as separate credentials: see How to revoke a leaked GitHub personal access token and check what it touched. For AWS role sessions, the documented action is the role's Revoke active sessions, covered in D3-ST Session Termination.

Proving the sessions are dead

A revoke action returning success is not evidence: Okta's session clear returns 204 while app-created sessions continue, and the platform documentation above lists delays measured in minutes. Verification uses the cut-off time you recorded for each platform.

• Post-cut-off success search: in Entra, query SigninLogs and AADNonInteractiveUserSignInLogs for the user with ResultType == 0 after the cut-off plus the residual window. Non-interactive records matter most, because replayed refresh tokens appear there rather than as new interactive sign-ins. In Okta, search the System Log for the user's events after the cut-off, especially new user.session.start events and token grants; see the Okta System Log Detection Guide. In Google Workspace and Salesforce, review login audit records and the session list for any session created after the cut-off.
• Session list re-check: reopen Salesforce Session Management, the Google user's Security panel and the Okta user's sessions after the residual window. Anything listed with a start time before the cut-off is a failed revoke.
• Side-door re-list: list Google ASPs and tokens, Okta grants and Entra app consents again. The expected result is an empty list or only items the user re-created after recovery.
• Downstream app audit logs: for each federated app in the inventory, confirm no API call or page view by the user after the cut-off. Apps that cannot show this need a manual session reset or a password change in the app itself.
• Replay test in exercises: replay a test user's captured cookie and refresh token after running this procedure, so you know in advance which apps honour revocation.

Decision guidance

• Disable or reset: disable the account for privileged users, developers with cloud or CI access and any account where persistence is suspected. For a standard user with a contained phishing event and no persistence found, a password reset plus full revocation is usually enough, and keeps the user working sooner.
• Suspend in Google Workspace: suspension resets cookies and stops new sign-ins in one step, so prefer it for confirmed compromise; reset cookies alone suits precautionary cases.
• Revoke one app or everything: if the evidence shows a single stolen cookie for one SaaS app, still revoke at the IdP, because the attacker may hold the IdP session that minted it.
• Small organisations: with one IdP and a handful of SaaS apps, a written checklist per app is enough. Record each app's revoke action and residual window now, not during the incident.
• Large organisations: script the IdP steps (Graph PowerShell, Okta API) behind a pre-approved runbook, with the admin roles held by on-call responders through just-in-time elevation. Prioritise global token revocation support in SaaS contracts so most apps can be reached in one call.

Detection and measurement

Measure the procedure, not only the incident. Track these over every account compromise and exercise:

• Time to full revocation: from containment decision to the last platform's recorded cut-off. Target an internal threshold such as 60 minutes for priority accounts.
• Post-cut-off successes: count of successful requests by the user after cut-off plus residual window. The target is zero; any non-zero value names the missed layer.
• Coverage of critical apps: percentage of critical SaaS apps with a documented, tested revoke action and known residual window.
• Side-door findings: number of app passwords, ASPs, grants and personal tokens found per incident. A falling trend shows legacy authentication and consent controls are working.
• Re-compromise rate: accounts re-compromised within 30 days, which usually points to an infected device or a missed persistence item.

The techniques this work answers in ATT&CK v20 are T1539 Steal Web Session Cookie, T1550.004 Web Session Cookie and T1550.001 Application Access Token (see the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide), and T1528 Steal Application Access Token. Persistence through new cloud credentials is T1098.001 Additional Cloud Credentials.

Common failure patterns

• Revoking before blocking: sessions are cleared while the password or a planted MFA method still works, and the attacker signs in again within minutes.
• Accepting defaults: an Okta session clear run without oauthTokens=true leaves refresh tokens that keep minting access tokens.
• Forgetting app passwords: the password is reset, but an app password kept by the attacker for IMAP or SMTP continues to work because it is not revoked by a reset.
• Stopping at the IdP: federated SaaS apps keep their own cookies; the user looks logged out in the IdP while the attacker browses the CRM.
• Ignoring what the user minted: personal access tokens, service tokens and third-party grants created or exposed during the compromise stay live, as the Cloudflare breach showed for credentials left unrotated.
• Restoring on an infected device: the user signs back in on the same machine and the stealer harvests the new sessions.

Framework mapping

Practitioner checklist

• For every critical app, record the admin action or API call that ends a user's sessions and its residual window.
• Pre-assign the roles and API scopes responders need (Entra User Administrator and Privileged Authentication Administrator, Okta okta.users.manage, Google User management, Slack admin.users:write).
• Isolate the device first when malware is suspected.
• Disable or reset, then remove planted MFA methods and devices, then revoke.
• Pass oauthTokens=true and an explicit forgetDevices on Okta session clears.
• Delete app passwords and Google ASPs, and block legacy authentication.
• List and revoke OAuth grants and personal tokens created in the exposure window, keeping the lists as evidence.
• Record a UTC cut-off per platform and search for successful activity after it plus the residual window.
• Re-enable only after verification and MFA re-enrolment on a clean device.

Standards and references

• Microsoft: Revoke user access in Microsoft Entra ID
• Microsoft: Continuous access evaluation
• Microsoft: Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords
• Google: Sign a user out of their managed Google Account
• Google: Directory API tokens resource
• Okta: Revoke all user sessions
• Salesforce: Monitor and manage user sessions
• Slack: admin.users.session.reset

Related NHI Mgmt Group resources: Session Token Theft Response Playbook, Account Takeover Response Playbook, Identity Incident Response Playbook, CAEP and Continuous Access Evaluation, App Passwords Security Guide.