Disabled Account, Active Session

The access revocation procedure stops at disabling the account in the identity provider. But disabling an account only blocks new authentications — it does nothing to what already exists: open sessions, refresh tokens, persistent cookies, remote access sessions, API keys, credentials cached by applications that validate their tokens locally.

This is structural. The mental model of “account disabled = access cut off” dates back to interactive authentication, where every action revalidated the account. Modern architectures rely on tokens whose lifetime is independent of account status, and each application manages its own sessions under its own rules. Real revocation is therefore a multi-system operation — and the procedure only describes one step of it: the one visible in the console.

During an incident, “the account has been disabled” is often announced as the containment measure. If sessions survive, containment is declarative — and that is worse than no measure at all, for three reasons:

• the team stops monitoring an account it considers neutralized, while the attacker keeps using it via its tokens;
• residual account activity is misread: a trace showing “activity from a disabled account” gets filed as a logging inconsistency rather than recognized as the high-quality signal it actually is;
• the incident timeline becomes distorted: post-containment actions get attributed to other vectors, and the investigation goes looking for a second entry point that doesn’t exist.

The window between disabling an account and actual token expiry runs from hours to days depending on configuration — plenty of time to exfiltrate data or establish persistence that no longer depends on the account.

Direct testing is the most reliable approach, done in a controlled environment:

• open sessions with a test account across a web portal, email, remote access, and a business application;
• disable the account;
• measure how long each session stays functional. The results are almost always surprising, and give you the real duration of your exposure window.

Procedural questions to ask:

• does the revocation procedure (offboarding, compromise) explicitly list: refresh token revocation, per-application session invalidation, API keys, integration secrets, registered devices?
• do you know the configured token lifetime, particularly for privileged accounts?
• which applications validate tokens locally without rechecking account status? These take longest to expire.

Write a complete, ordered revocation procedure and build tooling around it:

• standard sequence: disable the account, reset the secret, explicitly revoke sessions and tokens at the identity provider, revoke sessions per application for those that manage their own sessions, rotate API keys and related secrets, remove registered devices;
• shorten token lifetime for privileged accounts: the residual exposure window is a configuration parameter, not a given;
• automate the whole sequence into a single action — a periodically tested “red button.” During a crisis, a twelve-step manual checklist will not get executed in full, especially overnight;
• alert on any activity from a disabled account: this is one of the highest-value, lowest-noise signals available.

Go back over every account already marked “neutralized” since the incident began:

• reset the secret, explicitly revoke sessions and tokens, and look for API keys and application secrets tied to the account;
• then verify in the logs that no account activity appears after revocation — verification is part of containment, not a post-incident audit item;
• monitor disabled accounts by name for the entire duration of the incident: any subsequent activity is an immediately actionable signal, not an artifact;
• extend this to identity-linked persistence the account may have created: registered devices, delegations, mail forwarding rules, application consents — account revocation does not remove any of these.