Containment verification is re-reading the identity provider after a response action to confirm the final state, instead of trusting the API reply. When you disable an account or revoke its sessions, Microsoft Graph answers with a success code. That code says the request was accepted, not that the attacker's access has ended, and for some actions the two are minutes apart. Verification closes the gap with a second, independent read of the object you changed.
Why it matters to a lean team
A one to five person team runs incidents without a second pair of eyes. The person who submits the action usually writes the incident note too, so "contained" gets recorded at the moment the button was clicked. If the change did not hold, or reached only some workloads, nobody finds out until the attacker acts again. Verification turns "we revoked sessions" into "we revoked sessions at 14:07 and confirmed at 14:12 that the account was disabled and its session validity timestamp had moved". Only the second sentence stands up to an insurer, an auditor, or your own post-incident review.
How it shows up in Entra ID
Session revocation is the clearest example. The Graph call is POST /users/{id}/revokeSignInSessions. Microsoft documents that it invalidates all refresh tokens issued to applications for the user, plus browser session cookies, by resetting the user property signInSessionsValidFromDateTime to the current time. A successful call returns a 2xx response with {"value": true}, and Microsoft's own note on the same page reads: "After you call revokeSignInSessions, there might be a small delay of a few minutes before tokens are revoked." Nowhere does the page say the success code means sessions have ended.
Access tokens add a second lag. Revoking sessions forces a new sign-in; it does not end access tokens already issued, which last about an hour by default (60 to 90 minutes). Where client and workload both support Continuous Access Evaluation, an administrator revoking all refresh tokens is a critical event and the still-unexpired token is rejected within minutes, no more than about 15. For everything else, in Microsoft's words, "the user loses access when the access token expires." Disabling the account (PATCH /users/{id} with {"accountEnabled": false}) blocks new tokens and carries the same trade-off: Microsoft frames token lifetime as the time a client retains access after the account is disabled.
What to do about it
- Record when you submitted each action, then re-read the object: confirm
accountEnabledis false andsignInSessionsValidFromDateTimeis at or after your submission time. - Treat a success code as "submitted", not "contained". Read again after the few-minute delay Microsoft allows.
- Mark access as propagating until the longer window has passed: about 15 minutes for CAE-capable apps, about an hour for the rest.
- Verify the after-revoke steps separately. Microsoft notes that application deprovisioning typically runs every 20 to 40 minutes and that an Intune wipe needs the device online.
- Keep the before and after reads with the incident. They are the proof that the change held.
Related terms
- Privileged identity response: governed action on a compromised or over-privileged identity after detection, with the final state re-read from Microsoft where the action supports it.
- Identity blast radius: what an identity can reach before you act and what remains reachable after, the scope verification has to cover.
- Identity threat detection and response: the category this practice belongs to.
- Illicit consent grant: persistence that account-level containment does not reach on its own, so it needs its own verified response.
Browse the full glossary, or read revoke sessions versus disable user in Entra ID and the runbook for a compromised Entra admin account.
Orbitra connects Microsoft identity exposure analysis to approved response and evidence. It inventories human and workload access, prioritizes supported Entra privilege paths, and re-reads Microsoft state for supported actions. A named person approves every Orbitra-executed response today. See the workflow and coverage limits, or request a read-only exposure review.
Sources
- user: revokeSignInSessions (Microsoft Graph v1.0) (behavior, response code, delay note)
- Revoke user access in an emergency in Microsoft Entra ID (access token expiry, after-revoke best practices)
- Configurable token lifetimes in the Microsoft identity platform (default access token lifetime, disable trade-off)
- Continuous access evaluation (critical events, enforcement window)
- Update user (Microsoft Graph v1.0) (accountEnabled)
- All Microsoft Learn pages checked September 2026.