Why does resetting a compromised user's password not end an intruder's access?
answer
- a password is only one factor
- issued tokens have their own lifetimes
- consent is not a credential
- they may have enrolled their own MFA
- revoke sessions, grants, keys, devices
basics
~20 sA password change only stops future logins that present the old password. Already-issued sessions, access and refresh tokens, Kerberos tickets, application consent grants, app passwords, API keys and intruder-enrolled MFA devices are separate objects that must each be revoked.
solid answer
~50 sA password is one authentication factor, and changing it guarantees exactly one thing: an authentication attempt that presents the old password fails from now on. Everything an identity system issues so a client does not have to re-authenticate is a separate object with its own lifetime. An access token already minted stays acceptable to the resource until it expires; an OAuth application grant the intruder tricked the user into approving keeps its own tokens; a Kerberos TGT issued before the reset lives out its lifetime; client secrets on a service principal, API keys, app passwords, an authenticator the intruder enrolled and a mailbox forwarding rule are all untouched. So the reset is one item on a revocation list, not the list. Build the list from the intrusion timeline and then verify in the identity audit trail that nothing authenticates with pre-reset material.
go deeper
Be ready to list, without prompting, what a password reset does not touch: live sessions, access and refresh tokens, Kerberos tickets, consent grants, API keys and enrolled MFA devices.
Explain why each artefact survives in mechanical terms, and give the residual-access window created by an access token that a resource accepts until its expiry.
Show that you build the revocation set from the intrusion timeline and then verify it, treating the absence of post-reset authentication with pre-reset material as the actual evidence.
Own the trade-off between revocation completeness and business disruption, and the standing design question of which token lifetimes and revocation controls the estate should carry before an incident.
## What a password reset actually guarantees An account password is one authentication factor. The directory or identity provider stores a verifier derived from it, and every authentication that presents a password is checked against that verifier. Resetting it changes the verifier, so from that moment an attempt that presents the old password fails. That is the whole guarantee, and it is narrower than most people assume, because modern identity systems exist precisely so that clients do **not** have to present a password on every request. Each of the things they issue instead is a separate object, with its own storage, its own lifetime and its own revocation path. ## What survives the reset - **Interactive sessions.** The browser cookie at the identity provider, and the application session cookies downstream of it, are already established. Nothing about them re-consults the password. - **Access tokens.** A bearer access token is typically short-lived (an hour is a common default) and is usually accepted by the resource until its expiry unless that resource actively re-checks revocation. There is a window after the reset where the intruder still reads mail or calls APIs. - **Refresh tokens.** Long-lived, and used to mint fresh access tokens without re-authenticating. Many identity providers do revoke a user's refresh tokens on password change, but that behaviour is configuration-dependent and never covers tokens held under an application grant, so treat it as something to confirm rather than assume. - **Kerberos tickets.** A ticket-granting ticket issued before the reset remains valid for its lifetime (ten hours by default, renewable for longer). The password change does not reach back and invalidate it. - **OAuth application consent grants.** If the intruder got the user to approve an application, that application holds tokens in its own right. A grant including `offline_access` carries a refresh token. Withdrawing consent is a separate administrative action. - **Non-password credentials on identities.** Service-principal client secrets and certificates, API keys, personal access tokens in SaaS and source hosting, and app passwords for legacy protocols all authenticate without the user's password. - **Registered authentication methods.** An authenticator app or security key the intruder enrolled on the account survives, and it is worse than it looks: with a second factor they control, they can often drive the self-service reset flow and set the next password themselves. - **Data-flow persistence with no authentication at all.** A mailbox forwarding rule, a delegated mailbox permission or a sharing link keeps delivering content after every credential in the account has changed. ## Getting the direction of the claim right A reset removes one way in. It is not evidence that access ended. The evidence is negative and it lives in the audit trail: after time T, no authentication, token issuance or API call succeeds using material that predates the reset. Until you have looked, all you know is that one door was re-keyed. ## What to do instead Treat the password as one line in a revocation set derived from the intrusion timeline, not from a generic checklist. For the affected identity that usually means: reset the password; revoke sessions and refresh tokens; enumerate and withdraw application consent grants, paying attention to mail and file scopes; delete non-password credentials on any application or service identity the account created or modified; audit and remove registered authentication methods, re-enrolling the real user through an out-of-band identity check; remove forwarding rules, delegations and sharing links; and rotate any static cloud key or personal access token the account could reach. Then look at the window: if access tokens live an hour, you either accept sixty minutes of residual access or use the provider's near-real-time revocation and conditional-access controls to shorten it. ## The common wrong answer The weak answer is that the password change invalidates everything issued under it, so the account is clean. The stronger answer names the artefacts, notes that the important ones were created by the intruder rather than the user, and observes that some of them (a consent grant, an enrolled authenticator, a service-principal secret) were designed to be independent of the password on purpose. That independence is a feature for legitimate automation and a persistence mechanism for an adversary, and the incident-response job is to enumerate it rather than trust the reset.
- You revoke the user's sessions and refresh tokens. How long can the intruder still act?Until any access token they already hold expires, which is commonly around an hour. Revocation removes the ability to mint new tokens; it does not reach into a bearer token a resource server will accept until its expiry unless that resource participates in near-real-time revocation. Plan for that window: either accept it and watch the audit trail, or apply provider controls that force re-evaluation on the resources that matter most.
- Why is an authenticator the intruder enrolled on the account worse than the stolen password itself?Because it is the factor that guards recovery. With a second factor they control, the intruder can often complete self-service password reset and set the next password themselves, so your reset hands the account back to them. Removing intruder-registered authentication methods, and re-enrolling the genuine user through an out-of-band identity check, has to happen alongside the reset rather than after it.
- Does a password reset stop an intruder who has the account's password hash?For that account, yes in the sense that the old hash no longer authenticates once the verifier changes, so replaying it fails. But it says nothing about hashes for other accounts they harvested, about tickets already issued, or about non-password credentials. Scope the reset to every identity the harvested material covered, not just the one that raised the alert.
Re-keying the front door does nothing about the spare key you handed to a delivery service, the window someone left unlatched, or the mail redirection they filed.
saying these in an interview costs you the question
- Claims a password change invalidates every token issued under it
- Treats the reset as proof the account is clean
- Forgets application consent grants and service credentials entirely
- Ignores authentication methods the intruder registered themselves
- Never checks the audit trail for post-reset use of old material