Could an attacker create access that survives a password reset?¶
Yes. A password reset changes one credential. A separate session, application grant, new identity, authentication method, recovery route, service credential or sharing rule may remain valid until its own expiry, rejection, removal or revocation event.
The reset is a cut-off test, not a complete ending¶
At 10:05, a session associated with Dave's account grants application APP-73A1 access to files. Northstar resets Dave's password at 10:30. At 10:41, the application accesses object OBJ-8810 using its existing authority.
Build a before-and-after authority schedule¶
For each candidate route, record its stable identifier, creator, scope, creation and first-use time, state at the reset, later use and route-specific termination. Password changes and sessions explains why existing session authority can differ from a password. New users and administrators and malicious OAuth access show two other independent routes.
Activity after the reset is especially useful when its accepted authority can be named. It may establish that one control action did not end the relevant route. It does not by itself prove the route was attacker-created; authorised applications and administrators also continue operating.
Current Microsoft Entra example - checked 2 September 2026
Microsoft currently states that when it disables a malicious OAuth application, new token and refresh-token requests are denied while existing access tokens can remain valid until expiry. Microsoft also records application grant and removal activity separately from password changes.
Password, session, token and application behaviour varies by provider and configuration. Use the actual accepted/rejected events rather than a universal assumption about what a reset “should” have ended.
The point to remember
Treat a password reset as one timestamp on the authority timeline. Identify every surviving route and the separate event that expired, rejected, removed or revoked it.
