Disable the account or revoke sessions first? The order that actually works

Block sign-in first. Then revoke every active session and refresh token. Then reset the password. Do all three within minutes of each other, and don't stop at any one of them. Disabling the account stops new logins; it doesn't always kill what's already running. Revoking sessions kills what's running; it doesn't stop the attacker logging back in with the password they already have. The reset closes that door. Treated as a sequence they cover each other's gaps. Treated as alternatives, each leaves one open.

Why the order is block, revoke, reset

I get this question from people who've just found a compromised account and have about ninety seconds to act. The instinct is to reset the password, because that's the step everyone knows. The problem is that a reset doesn't reliably end sessions that are already authenticated. An attacker holding a valid access token, an authenticated mail client, or an app password can keep working after the password changes, sometimes for hours.

Microsoft's own response guidance for a compromised cloud mailbox puts the steps in this order: disable the account (block sign-in) as the preferred first move, reset the password if you can't disable, enforce multi-factor authentication, then revoke sessions and refresh tokens, then review MFA methods, consented apps, admin roles, and mail forwarding rules (Microsoft, 2026). The same logic applies to Google Workspace, where suspending the user blocks access to the organisation's services without deleting any data, so you lose nothing by acting fast (Google, n.d.).

Blocking first matters for a second reason: it buys you a stable target. Once sign-in is blocked, nothing new can be established while you work through the rest. Revoking sessions on an account that can still sign in is a race you're running against someone who's already inside.

What each step misses

Disabling the account doesn't remove authorisations the attacker granted to themselves. OAuth consents to third-party apps, extra MFA devices, mailbox delegations, and inbox rules all survive a disable and a reset. Microsoft's guidance lists each of these as a separate review for exactly that reason (Microsoft, 2026). The forwarding rule is often the whole attack. The account gets "fixed," and every invoice email still goes to the attacker.

Revoking sessions doesn't cover every token type. App passwords and some legacy protocols aren't revoked by a session reset and have to be removed separately. If the account is synced from on-premises Active Directory, reset the password twice to invalidate cached credentials, and if it's federated, change it at the source, not in the cloud console (Microsoft, 2026).

Resetting the password does nothing if the attacker can read the reset. Don't email the new password to the user's mailbox. The attacker is in that mailbox.

Evidence before you touch anything, if you can

NIST's current incident response guidance frames response as a cycle of detection, analysis, containment, eradication and recovery, with evidence handling running through all of it (Nelson et al., 2025). In practice that means: before you disable, export the sign-in log, the audit log, the inbox rules and the consented apps for that account. It takes two minutes and it's the difference between knowing what the attacker did and guessing. If you have to choose between evidence and containment because the attacker is actively sending mail, contain. But most of the time you don't have to choose.

Where this goes wrong in real organisations

The step order isn't usually the problem. Authority is. The help desk can reset a password but can't disable an executive's account without a manager's say-so. The identity team can revoke sessions but doesn't have rights in the mail system to check forwarding rules. By the time the three people who each hold one piece of the fix are on a call, the attacker has had an hour. Whoever can see the compromise should be able to execute all three steps, or the plan should name someone who can, reachable at 2 a.m., with the authority pre-approved. That's a governance decision, and it's the one I'd fix first.

What I'd do next

Write the three steps into a one-page runbook for your identity platform, with the exact commands or console paths, and test it on a dummy account this week. Then answer the authority question above in writing. If you'd like me to look at how your decision rights and your identity tooling line up before you need them, request a briefing. The rest of what I've written on this lives in Incident response.