A password change may leave a stolen session usable. See how endpoint containment, token invalidation, application-session controls, and account recovery fit together.
A web application may still have an active session after the account password changes. Depending on its capabilities, an infostealer may collect stored passwords as well as session cookies, authentication tokens, API keys, and other local data. If that information has left the device, removing the malware does not invalidate it.
A password is a secret presented during authentication. An access token allows an application to reach specified resources, while a refresh token can obtain a new access token when the protocol permits. An application session commonly continues through a separate cookie or session secret issued after authentication. These mechanisms may belong to the same account, but they do not necessarily share a lifetime or a revocation control.
Which access can survive a password change?
A password change prevents new sign-ins that depend on the old password. It cannot be assumed to terminate every token or application session that remains valid. In Microsoft's emergency-access guidance for Entra, blocking new sign-ins and revoking refresh tokens prevents the user from obtaining new Entra tokens. An existing access token, however, may work until its default one-hour lifetime ends. Continuous Access Evaluation can shorten that interval in supported Microsoft 365 scenarios; it is not a promise of instant invalidation for every token.
An application-issued session cookie must be handled separately. Entra cannot directly revoke a session token issued by the application itself. NIST SP 800-63B-4 describes the same separation in federated systems: the identity provider (IdP) and relying party (RP) establish and terminate their sessions independently. Ending the identity-provider session does not, by itself, end every connected application's session.
That distinction is useful to an attacker. MITRE ATT&CK documents how a stolen web session cookie that is still valid and reusable may be imported into an attacker-controlled browser. Because the session is already authenticated, some authentication flows may not require a new MFA step. It describes a capability, not proof that a particular account was taken over.
Device containment and account controls
The suspected endpoint is isolated under the organization's incident plan while the need to preserve relevant evidence is assessed. If the account is privileged or reaches sensitive data, blocking new sign-ins and closing current access paths may begin before full endpoint analysis is complete. Password changes, account recovery, and administrative work take place through a trusted device and channel so that new credentials are not exposed to the suspected system.
Access data stored on the device
The review is not limited to passwords saved after the suspected infection window. The start of an infection may be uncertain, and an infostealer can reach credentials that were already stored on the device. Based on the incident evidence, the review covers browser profiles, accounts used or stored locally, session cookies, tokens, and API keys. Cleaning or rebuilding the endpoint does not invalidate passwords, tokens, or keys that may already have been taken.
Token and session controls
The identity provider's documented controls are used to block new sign-ins, invalidate refresh tokens where supported, and terminate IdP sessions. Critical applications are then checked separately, and their own sessions are terminated through application-level controls. A “success” message in an administration screen does not establish that all access has ended. The token type, its expected expiry condition, and the point at which each application will require authentication again still matter.
The password and other access data within the incident scope are rotated or invalidated from a trusted device. Whether that includes an API key, developer token, or another locally stored credential depends on the incident evidence and the affected system's behavior. The goal is not to reset every account blindly, but to determine which passwords, tokens, keys, or session cookies may have left the device and remain usable.
Persistence changes
An intruder may add a route back into the account instead of relying only on the current session. Microsoft's response guidance for a compromised Microsoft 365 mail account calls for reviewing unrecognized MFA methods and devices, unwanted application consent, unauthorized administrative roles, mail forwarding, and hidden inbox rules. That list is specific to Microsoft 365; equivalent controls and their effects differ across providers.
An unrecognized or suspicious MFA method is removed or invalidated. If the legitimate user's method needs to be enrolled again, ownership is first verified through a trusted recovery channel and only a new method controlled by that user is registered. Re-enrolling a method added by an attacker would preserve the access path rather than close it.
MFA does not revoke an active session
MFA creates another barrier to starting a new session with a stolen password, but it does not by itself invalidate a previously authenticated, reusable cookie. MFA methods also provide different protections. NIST's authenticator requirements do not consider manually entered one-time codes phishing-resistant and cite WebAuthn/FIDO2 as an example of phishing-resistant authentication. Stronger authentication protects future sign-ins; a stolen session that remains valid still needs to be terminated separately.
What logs can—and cannot—establish
Where available, sign-in and sensitive-action records for the incident window can reveal unusual locations, times, application grants, and account changes. For Microsoft 365, the provider advises against narrowing the initial audit search too early and recommends reviewing records from the onset of suspicious activity through remediation. Finding no suspicious event does not prove that the account is safe. The result is meaningful only within the available telemetry, retention period, queried sources, and time window.
Likewise, evidence that a credential or cookie was exposed is not, by itself, evidence of successful unauthorized use or account takeover. Exposure, observed attempted use, and confirmed takeover remain distinct. Potentially valid access paths still need a proportionate response, with scope driven by account privilege, data sensitivity, and the available evidence. LeakData's post-breach assessment guide discusses that broader distinction between exposure and confirmed misuse.
The incident record lists the sessions terminated at the identity provider and within applications, the expected expiry conditions for tokens, unauthorized changes removed, and gaps in the log review. This makes clear which access paths were addressed and which uncertainties remain.
