After reset, all existing sessions must be invalidated

What it is

People recover a password usually because the old secret may no longer be only theirs. Invalidating all old sessions after a successful reset means the server revokes every refresh and access token issued for that account before the change; each device returns to signed-out; only the end that finished this reset (or that then signs in with the new password) receives a new session. This is insurance after a password change, not kicking one row in the everyday session list, and not tapping sign-out on this device.

Why it happens

Session tokens, once issued, do not re-check the current password hash. If an attacker already holds an old session, the owner’s reset only changes the key for future sign-ins; the intruder stays inside to change email or turn off MFA. Revoking all makes “I changed the lock” mean “everyone inside leaves.” Collateral damage is that the owner’s other devices must sign in again; that cost is acceptable in recovery, because recovery already assumes control may have been lost. Revocation must include refresh tokens and “remember me”; clearing only access tokens lets refresh mint them again minutes later. The new session from this reset flow must be exempt, or the person is kicked to login immediately after changing the password and reads it as failure.

Studying it

Arrange “device A is signed in, device B completes reset” and watch whether A’s token dies immediately.

Independent variables: revocation scope (current only, all except current, with or without refresh tokens), whether the reset page says other devices will be signed out. Dependent variables: whether A’s later authenticated requests fail, whether B stays signed in, whether people understand other devices must re-enter.

Do not import single-row kick experiments from the session list—that is everyday control with a weaker threat model. Hit real APIs, not only a refreshed list. Copy studies should watch whether fear of losing every device stops people from resetting; if so, the explanation must say why the drop is required.

Where it stops holding

Enterprise SSO sessions may belong to the IdP; an in-app change may be a local password or a binding, and copy must say “this app’s sessions” versus “the company account.” Changing a display name or preference is not a reset and must not kick sessions. When a signed-in person changes the password in settings and can prove they still hold the old one, policy may offer “optionally kick other devices,” because control is not assumed lost; self-serve recovery must not use that lax default. Concurrent “remember me” cookies, mail-client app passwords, and third-party OAuth grants belong on the “old session” list, or only the web was kicked.

Applying it

• On successful self-serve reset, revoke every pre-change refresh/access token and “remember me” for that account; void app-specific passwords and tell people to regenerate them.
• The end that finished reset keeps or immediately receives a new session; other ends, on the next request, show “the password was changed, sign in again.”
• Confirm copy should say other devices will sign out, so the drop is not later read as a fault.
• Verify: A is signed in, B completes recovery; A’s old token fails the API, B still works. Check that “remember me” and mail-client app passwords died too. A signed-in change that used the old password may be tested separately and must not share recovery’s “don’t kick devices” default.

Related

• Within the group: H6.11.1 Recovery must not leak answers easier to guess than the password · H6.11.2 Reset links must expire and be single-use · H6.11.4 Recovery must not reveal whether an account exists to an unverified party
• Adjacent: H6.06 Multi-device sessions · H6.07 Sign out
• Search terms: session invalidation · password reset · revoke all sessions