Changing a password does not describe every credential already issued to an account. A browser session, mobile application token, and connected service may each have a separate lifecycle. During account recovery or employee departure, the business needs to know when each access path actually stops working.
This is a verification problem with a timeline. The identity system may record that access was revoked while a downstream application continues honoring an existing session until its own checks or expiration rules take effect.
Map the credentials already in use
Microsoft's emergency access-revocation guidance distinguishes the identity provider's token behavior from sessions controlled by applications. It explains why removing identity access may not immediately terminate every application session. The Microsoft guidance provides one documented example of this boundary.
For an illustrative business account, record browser sessions, refresh tokens, mobile clients, application-specific passwords, and API keys. Not every product uses every category. The purpose is to identify the actual credentials that can continue operating after a password changes.
Define what revocation means for each service
A service may check authorization on every request, accept an access token until expiry, or maintain its own server-side session. These choices affect the delay between an administrative action and the last accepted request. The expected delay should be explicit in an offboarding or incident procedure.
Also distinguish removing access from deleting information. Terminating a session does not remove files already downloaded to a managed or unmanaged device. That is a separate data-handling question and should not be presented as a result of credential revocation.
Build a controlled revocation timeline
Sign a synthetic user into representative applications on two test devices. Record a successful request from each client, perform the approved reset and revocation actions, and repeat harmless read requests at defined intervals. Include token renewal attempts where the application supports them.
Record the administrative action time, the last successful request, and the first denial. Test an active connection as well as a newly opened session. A dashboard screenshot saying the user is disabled is evidence of the configuration change; the request results establish what the application enforced.
Turn the result into an operational procedure
If one application requires a separate session termination call, include it in the procedure and assign an owner. If another has a documented propagation delay, record the delay and any temporary containment available. The procedure can then describe an ordered response rather than assuming one identity action covers all services.
Retest when adding a new single sign-on application or changing token lifetime settings. The evidence can support a precise statement such as all tested application sessions were denied within the measured interval. It cannot establish the behavior of untested applications or personal devices outside the review's scope.
Sources
NIST: Session Management. The multi-application account and timing exercise are illustrative.
