Revoke Sign-In Sessions [FIX-9005]

The user's password is not touched. The user can continue working as normal after re-authenticating; no helpdesk follow-up is required to restore access.

Modern identity attacks often pivot on stolen session tokens rather than passwords. Adversary-in-the-Middle (AiTM) phishing kits, malware that scrapes browser session cookies, and token theft via OAuth grants all leave the password untouched but give the attacker working sessions that bypass MFA. Forcing a password reset in these scenarios is heavy-handed and disruptive when only sessions need to be killed.

This remediation calls revokeSignInSessions on Microsoft Graph, which resets the user's refreshTokensValidFromDateTime. Any existing refresh token issued before that timestamp can no longer be exchanged for new access tokens; existing access tokens continue to work until they expire (typically within an hour). For high-impact incidents where you cannot accept that hour window, combine this with FIX-9003 to also kill the password and prevent re-authentication.

Use this as the default response to a suspicious sign-in alert. Escalate to FIX-9003 only when credential compromise is confirmed — for example, when the password is known to have been phished or the user reports they entered it on a malicious page.

An automated fix is available through Attic.

Manual steps:

1. Navigate to the Entra ID portal at https://entra.microsoft.com
2. Go to Users > All users
3. Search for and select the affected user
4. Click Revoke sessions to sign the user out of all devices
5. The user will be required to authenticate again on next access attempt

• All refresh tokens issued to the user before the action are invalidated.
• The user must re-authenticate on every device and application.
• Existing access tokens remain valid until they expire (typically up to one hour).
• The user's password is unchanged — they can sign in normally with their existing credentials.
• No helpdesk action or password communication is required.

Revert

This action cannot be reverted. Revoked refresh tokens cannot be reissued.

No revert is needed. The password is unchanged, so the user signs in again and completes MFA as normal. There is no helpdesk action, no password to communicate, and no lasting change to the account.

If the user cannot sign back in, the cause is not this action. Look instead at whether the account is disabled (FIX-9000), an authentication method was removed (FIX-9008), or a Conditional Access policy is blocking.

• Microsoft Graph: revokeSignInSessions
• Microsoft: Token theft and session hijacking
• Microsoft: Adversary-in-the-middle phishing