What access may remain after a password reset?¶
Potentially quite a lot.
A password reset changes one authentication route. It may not automatically remove every existing session, token, trusted device, delegated permission or connected application.
That is why continuing activity after a reset is worth investigating rather than simply calling the reset unsuccessful.
Check all the surviving access routes¶
Depending on the service, remaining access may include:
- active sessions;
- refresh tokens;
- trusted devices;
- consented applications;
- API/service keys;
- mailbox forwarding;
- delegated access;
- recovery methods;
- newly created administrators;
- remote-access tools;
- compromised endpoints.
Record state before and after the reset¶
A useful comparison might look like:
That turns “activity continued” into a specific technical question.
Provider behaviour matters¶
Different services handle password resets and token invalidation differently.
Where the exact behaviour is important, verify the provider's current documentation or records rather than assuming that password change means universal logout.
Continued activity may have another explanation¶
Post-reset activity could reflect:
- surviving attacker persistence;
- legitimate automation;
- shared access;
- another compromised device;
- connected account;
- delayed queued activity.
Follow the session, application or device involved.
Treat the reset as a timeline marker¶
The reset gives you a precise response event.
Ask:
- what stopped afterwards;
- what continued;
- what new sessions appeared;
- which security controls were separately revoked.
The practical point is: a password reset is one containment action, not a guarantee that every route is closed. Verify sessions, tokens, applications, recovery and delegated access separately.
