A responder resets an account password, closes the ticket, and later learns that the application was still open in another browser. The password action succeeded. The conclusion about access was never verified.
Passwords establish one way to authenticate. Sessions and delegated access can follow different lifecycles.
Ask what the reset actually invalidated
OWASP's session guidance explains why an authenticated session needs its own security controls. Do not assume that changing one secret terminates every access artifact associated with the account.
Check the affected provider's documented behavior. Does the action end browser sessions? Does it revoke refresh capability? What happens to a connected application that manages its own session?
Microsoft's emergency access-revocation guidance illustrates the distinction between actions at the identity provider and access already established in applications. Its behavior should not be generalized to every provider.
Make access types explicit
Use separate checklist items for:
| Access type | Verification question |
|---|---|
| Password sign-in | Was the credential changed or the route disabled? |
| Identity-provider sessions | Which documented revocation action was performed? |
| Application sessions | Does the application require a separate administrative action? |
| Delegated grants | Are unexpected application permissions still present? |
| Recovery methods | Can an unauthorized party regain access? |
The owner should be able to say what was done and what remains uncertain. “Logged out everywhere” is not a substitute for provider-specific evidence.
Preserve enough context to investigate
Before broad changes, preserve relevant administrative and sign-in records where the response plan permits. When access is actively being abused, containment may be more urgent than collecting a perfect snapshot.
Record the times of containment actions. They help distinguish activity that occurred before revocation, an expected delay, and access through a separate mechanism.
Do not validate containment by attempting to use a stolen credential or copied session artifact. Use authorized administrative checks and approved test accounts for exercises.
End with a verification, not a button click
A hypothetical support team might reset the email password while a third-party app retains its own authenticated session. Closing both questions requires the email administrator and application owner to coordinate, not repeat the same password reset.
Document which systems were checked, who confirmed the result, and any remaining provider limitations. If endpoint compromise is suspected, address that separately before returning the user to normal work.
Read OAuth tokens versus passwords for another access distinction and the first hour of an exposure response for the broader sequence. Successful containment is an evidenced outcome, not a single administrative command.