Revoke Microsoft 365 sessions with evidence—not assumptions about token expiry

Source facts: revocation timing depends on the token and application

Microsoft’s emergency user-access revocation guidance distinguishes access tokens, refresh tokens, and application session tokens. It explains that an administrator can block new sign-ins and revoke a user’s refresh tokens, while existing access can persist until enforcement occurs. An application that issued its own session token controls that session according to its own authorization behavior; Microsoft Entra cannot directly revoke every token issued by another application.

Microsoft’s continuous access evaluation documentation describes near-real-time evaluation for specified critical events in supported services and clients. It documents supported resource and client combinations, possible event-propagation latency, and limitations. CAE is not universal instantaneous logout for every Microsoft 365 feature, guest, application, or network condition.

Exact steps depend on whether the identity is cloud-only, synchronized, privileged, federated, a guest, or used by automation. Licensing, roles, APIs, service support, and hybrid synchronization affect the response. Password reset, disablement, token revocation, device disablement, and application deprovisioning solve different parts of the problem and should be chosen from current Microsoft and application guidance.

DSE recommendation: run containment as a measured incident workflow

Prepare a user-access containment runbook before an emergency. Define who can authorize it, which privileged role performs each step, how to protect emergency administration, when legal or human-resources coordination is required, and which systems must be checked outside Microsoft Entra. Test with designated accounts, never by improvising on a real employee.

1. Classify and preserve. Record the identity, event time, reason, reporter, current account and device state, relevant alerts, and authorized scope. Preserve sign-in, audit, mailbox, endpoint, and application evidence under the incident and legal process before changes erase useful context.
2. Stop new Entra access. Use the supported administrative control to block sign-in and revoke sessions or refresh tokens. For a hybrid identity, coordinate the authoritative directory and synchronization path. Do not assume an on-premises password change has already reached cloud services.
3. Address authenticators and devices. Reset or remove compromised authentication methods as authorized, invalidate recovery paths, review registered devices, and isolate or disable affected endpoints when the response plan calls for it. Avoid destroying evidence or locking out the response team.
4. Handle application sessions. Inventory critical Microsoft, SaaS, VPN, line-of-business, and mobile applications. Use their supported deprovisioning or session-revocation controls where Entra action is insufficient, especially for applications with local accounts, long-lived keys, app-issued cookies, or offline access.
5. Check delegated and non-user access. Review mailbox delegation, OAuth consent, app passwords where still present, service principals, API keys, shared credentials, forwarding, rules, role assignments, and access the person could exercise through a team or shared account. Remove only with authorized impact analysis.
6. Verify the outcome. From approved test paths, confirm that new authentication and representative existing sessions fail as expected. Review Entra sign-in logs, service audit logs, CAE details where available, application events, and help-desk reports. Document unsupported paths and compensating controls.

Keep a timeline of commands, portal actions, returned results, observed enforcement, and who verified each service. A “success” response from an API proves that a directory operation was accepted, not that every relying application ended access at that instant. Escalate residual access rather than waiting silently for an assumed token lifetime.

After containment, decide deliberately whether and how to restore the identity, devices, methods, roles, and sessions. Reissue access from known-good conditions and monitor. The final record should distinguish verified termination, expected delay, unsupported revocation, and untested application paths so leadership understands the actual exposure.

Set response timers by service criticality and escalate when observed enforcement exceeds the documented expectation. Never mark the identity contained while a tested high-value session still works. If an application cannot revoke immediately, record its maximum known exposure, disable access through another supported layer when safe, and maintain monitoring until the session is confirmed ended.

Official references

• Microsoft, Revoke user access in an emergency in Microsoft Entra ID.
• Microsoft, Continuous access evaluation in Microsoft Entra.