A credential turns up in an exposure report. Someone resets the password, marks the ticket done, and moves on. It is the obvious first move and it is rarely the wrong one. It is just rarely sufficient, because a password is only one of several things that will let somebody into an account, and the reset acts on exactly one of them.
The gap between resetting a password and ending an attacker's access is not a subtle one. It is written into the published defaults of every major identity provider, and in two of the three cases the vendor's own documentation says plainly that the reset and the revocation are separate actions. Knowing which is which decides whether your incident response closes the door or just changes the lock while the attacker is already inside.
The thing a password protects is the moment of sign-in, not the session that follows. Authentication happens once. After it succeeds the system issues tokens, and from that point the tokens are what grant access, not the password. That is the whole point of them. It is also why changing the password afterwards does not, by itself, reach anything that was issued before. The old password is dead and every token minted with it is still alive.
Microsoft Entra ID
Microsoft publishes the default lifetimes, and they are worth reading carefully because the useful number is not the one people quote.
An access token lasts a random value between 60 and 90 minutes, averaging 75 minutes. Microsoft randomises it deliberately to avoid synchronised reissue storms. The figure also varies by client, by resource, and by whether Conditional Access is in play. Where Continuous Access Evaluation applies, Microsoft states the lifetime may be extended to 24 to 28 hours, because CAE is designed to revoke on an event rather than wait for expiry. That trade is the right one in general, but it means that in a tenant with CAE and an application that is not CAE capable, an access token issued before your reset can remain valid for more than a day.
Refresh tokens and session tokens both default to a maximum age of until-revoked. Not a number. Microsoft's configurable token lifetime documentation gives the default MaxAgeSingleFactor, MaxAgeMultiFactor, MaxAgeSessionSingleFactor and MaxAgeSessionMultiFactor values all as until-revoked, and marks none of them configurable. Refresh tokens carry a maximum inactive time of 90 days. Non-persistent session tokens have a maximum inactive time of 24 hours and persistent ones 90 days, and each use inside the window extends it again. The practical reading is that a refresh token in regular use does not expire on a schedule. Something has to revoke it.
Refresh and session token lifetimes stopped being configurable on 30 January 2021. Microsoft retired those policy properties, and existing policies that set them are ignored. Sign-in frequency in Conditional Access is the replacement lever. Any runbook written before 2021 that relies on shortening refresh token lifetime is configuring something that no longer has an effect.
Revoking the session is its own command. In Microsoft's guidance for revoking user access in an emergency, the cloud sequence is to disable the account, run Revoke-MgUserSignInSession, and disable registered devices. The password reset instructions in that same document apply to on-premises Active Directory, where Microsoft advises resetting the password twice to mitigate pass-the-hash if there are replication delays. There is no step in which changing the cloud password revokes tokens as a side effect.
And some sessions are beyond Entra's reach entirely. Microsoft states that to revoke a session token the application must revoke access under its own authorisation policies, and that Microsoft Entra ID cannot directly revoke a session token issued by an application. Where disabling the account does propagate to an application, it propagates on the provisioning cycle, which Microsoft says typically runs every 20 to 40 minutes.
Google Workspace
Google is the most generous of the three, and it is still conditional.
A password change does revoke OAuth tokens, including refresh tokens. Google states that OAuth 2.0 tokens issued for access to certain products are automatically revoked when a user's password is changed, and that the change invalidates access tokens as well as refresh tokens. Third-party mail applications, including mobile mail apps, stop syncing until a new token is granted. That is a real and meaningful difference from Microsoft's default behaviour.
Password expiry is not a password change. Google says the revocation is not triggered by expiry alone. An account that lapses past its expiry date has not had its tokens revoked.
Resetting to the same password may not count as a change at all. Google notes that setting a user back to the same password through the Directory API users update, using the same hashing function and the same salt where one is used, is not treated as a password change. Worth knowing if your tooling pushes password values programmatically.
Applications built on Apps Script are excluded. Google states the revocation process does not include them, and says so even where those applications access mail.
A password change made from an Android device does not revoke that device's own sync token. Google calls this out specifically: the OAuth token for the account sync used by that Android device is not revoked.
App passwords are untouched. Google's position on app passwords used with 2-step verification is stated in three words: currently, there is no impact. An app password is a 16-character credential that bypasses the second factor by design, and a password reset does not invalidate it. If one was captured, resetting the password does not take it away. The separate Less secure apps setting likewise has no bearing on whether tokens are revoked.
Gmail IMAP sessions over OAuth are not interrupted by the change, though they remain bounded by the access token's life, which Google describes as usually about one hour.
Okta
Okta treats revocation as a decision, not a consequence. Session and token revocation appears as an option an administrator selects during a password reset, and separately as a Clear User Sessions action under More Actions on the user record, which confirms through a dialog named Clear Sessions and Revoke Tokens. When the option is selected during a reset, Okta states the user is signed out of Okta sessions on all devices and browsers. If self-service password reset is enabled, Okta-sourced users can sign themselves out of other devices when they reset. The documentation does not describe a reset revoking anything on its own, which means the checkbox matters.
Universal Logout covers more, with named gaps. For SaaS and Okta applications it revokes session cookies, refresh tokens and access tokens across all four of its triggers. For Okta's own session management it clears state tokens, password reset tokens and account unlock tokens, though not when the trigger is an authentication policy violation. SSWS API tokens are cleared only on an admin-initiated clear or an entity risk violation. Custom authorization servers are not marked as revoked under any trigger at all, which is the gap most worth checking against your own configuration.
Two scope limits are easy to miss. When a global session policy violation triggers the logout, Okta revokes only the cookies and tokens for the session on the device where the violation happened, not everywhere. When an application triggers an authentication policy failure, only that application's cookies and tokens are revoked. And in every case each application manages its own cookies and tokens, so the application's documentation governs the detail.
What none of them fix
If the machine is still infected, the new password is already gone. Infostealer malware takes what is stored on a device and keeps taking it. A reset performed on a compromised endpoint produces a fresh credential in the same browser profile the malware is reading. This is the difference between a credential that leaked from somebody else's breach and a credential that came out of a stealer log, and it is why the source of the finding changes the response. A breach-sourced credential needs a reset. A stealer-log-sourced credential needs the device dealt with first, and the reset afterwards.
MFA enrolment is a separate object. None of the three vendors describes a password change as affecting registered authenticators. If an attacker enrolled their own factor during the window they held the account, the reset does not remove it. Reviewing registered methods is its own step.
Anything that was exfiltrated stays exfiltrated. Mail rules, forwarding addresses, OAuth application grants made during the intrusion, and data already copied out are not reversed by a credential change. Mail forwarding in particular survives everything in this article and is a common persistence mechanism precisely because it does.
The order that actually closes access
The sequence matters more than any individual step, because doing them in the wrong order means repeating them.
Deal with the device before the credential, when the finding came from a stealer log. Reset first on an infected endpoint and you have burned a reset and produced a new exposed password.
Revoke sessions and tokens explicitly. Not as a side effect. In Entra that is Revoke-MgUserSignInSession or the revoke sessions control. In Okta it is the checkbox or Clear User Sessions. In Google it happens with the change, subject to the exceptions above.
Then change the password, to something that has been checked against known-compromised values. NIST SP 800-63B-4 section 3.1.1.2 requires that verifiers compare a prospective secret against a blocklist containing known commonly used, expected or compromised passwords.
Then remove what the password reset cannot reach. App passwords, which in Google survive by design. Registered MFA methods you do not recognise. OAuth application grants. Mail forwarding and inbox rules.
Then check the finding was not already stale. A credential that surfaced in a report may have been valid for weeks before you saw it, and the question of what else was done with it in that window is a different investigation from the reset.
Why this argues against routine rotation
There is a tempting conclusion here that passwords should simply be changed more often. The current standard says the opposite, and says it in the same section.
NIST SP 800-63B-4 section 3.1.1.2 states that verifiers and credential service providers shall not require subscribers to change passwords periodically, and in the same item that verifiers shall force a change if there is evidence that the authenticator has been compromised. Rotation on a calendar is prohibited. Rotation on evidence is required.
That pairing only works if you have a way of knowing. A scheduled reset every ninety days is a ritual that NIST now rules out, and it would not have helped here anyway, because the tokens it fails to touch are the ones attackers use. Knowing that a specific credential is exposed, when it surfaced and whether it came from a breach or from malware on a machine you own is what turns the standard's requirement into something you can actually act on.
Check your own exposure
SphereTI monitors credential exposure across breach corpora, infostealer logs and credential lists, and reports which of your domains appear, where, and when. If you want to know what is already out there before you decide what to revoke, request a free exposure report. No password is needed.