DAILY ANALYSIS
After account compromise, verify that existing sessions are closed
A practical way to verify that identity-provider and application sessions stop working after an account compromise.
Identify who issued the session
Start with the identity provider, the applications the account accessed, and the devices involved. In Microsoft Entra ID, refresh tokens can let a client request new access tokens, while a web application can maintain a separate session cookie. Microsoft documents that Entra cannot directly revoke a session token issued by the application. Ask each application owner which administrative action invalidates its own sessions and whether the action takes effect immediately.
Contain access across the affected services
Use your incident response process to decide when to disable the account, revoke identity-provider sessions, and isolate a suspected compromised device. Identify the applications that keep independent sessions and use their documented sign-out or session-revocation controls. Review the account’s roles, authentication methods, and recent security changes before restoring access. A central password reset is one step in a larger containment process.
Measure the delay in an authorized test
In a hypothetical tabletop exercise, an administrator disables a synthetic account while a tester has an established browser session in a test application. Record the revocation timestamp and then attempt a harmless action that makes a fresh server request. Check whether the application denies the action, how long enforcement takes, and whether the identity provider denies a new sign-in. Test an independent application session separately and document any required action by its owner. Avoid using live customer records or capturing session secrets.
Reduce the chance of repeat compromise
CISA recommends phishing-resistant MFA, including FIDO/WebAuthn. Prioritize privileged accounts and users with access to sensitive systems. Pair the rollout with a review of recovery and enrollment paths, and practice session revocation with application owners. Authentication controls and post-compromise containment address different points in the incident.
Record the limits of your evidence
A successful revocation check establishes the result for the tested application, client, and action. It cannot show what happened before revocation or whether another application still accepts an old session. Record the affected scope, timestamps, checks performed, remaining gaps, and owners. Keep suspicious pre-revocation activity in the investigation even after the access tests pass.