Your account was breached — does simply changing the password kick the attacker out?
Short answer
Not by itself. Many systems keep existing sessions and previously issued tokens valid after a password change — OAuth refresh tokens, 'app passwords', API keys, and persistent cookies — so an attacker with a live session can stay in. The correct response is to change the password AND invalidate all sessions and tokens, revoke app credentials, and audit MFA devices and recovery settings. Assuming a password reset alone evicts the attacker is a classic incident-response mistake.
It feels obvious: the attacker got in with your password, so change the password and they're locked out. In modern identity systems that intuition is often wrong, and acting on it gives a false sense of containment.
Why a password change doesn't always evict
Authentication and ongoing access are decoupled. You authenticate with a password once, but the system then issues longer-lived artifacts that don't recheck the password on every request:
- Active sessions / cookies — a logged-in browser session may stay valid for days regardless of the current password.
- OAuth refresh tokens — issued to connected apps, they mint new access tokens without ever seeing the password again.
- App passwords / API keys — separate long-lived credentials created precisely so they don't depend on the main password.
- Persistent device trust — "remember this device" flags that skip re-auth.
An attacker who established a live session or grabbed a refresh token simply keeps using it after you reset the password.
What actually evicts the attacker
Treat password reset as one step in a sequence, not the whole job:
- Reset the password — yes, still do this.
- Invalidate all sessions — trigger a global sign-out / "revoke all sessions" so existing cookies die.
- Revoke tokens and app credentials — kill OAuth grants, refresh tokens, app passwords, and API keys.
- Audit MFA and recovery settings — attackers frequently add their own MFA device, alternate email, or recovery phone so they can reset the password right back. Remove anything you don't recognize.
- Check forwarding rules and OAuth consents — common persistence on email accounts.
The interview takeaway
The misconception is treating authentication as a continuous gate when it's really a one-time checkpoint that issues durable tokens. Saying "change the password" alone signals you don't understand session and token lifecycles. The strong answer is "reset the password and revoke every session, token, and recovery path, then verify MFA."
Likely follow-ups
- Why can an OAuth refresh token keep working after the password is reset?
- What recovery-path artifacts should you audit so the attacker can't simply reset the password back?
- When is 'global sign-out / revoke all sessions' the right first action?