Because a password change only protects future authentication unless the application also kills existing sessions. An attacker, former employee, or user on a stolen device can continue operating under the old session if it stays valid. That creates a gap between identity change and access termination that many SaaS platforms still leave open.
Why sessions remain a risk after the password changes
A password change updates the credential used for new logins, but it does not automatically invalidate session state that was already issued. If a browser, mobile app, API client, or stolen device still holds a valid session token, the user can continue acting until that session expires or is revoked. That is why identity risk persists after the password itself is no longer valid.
Long-lived sessions create a separate trust path from the password. The password authenticates the next login attempt, while the session often acts as a standing proof of prior trust. In many SaaS environments, that distinction is blurred operationally, which is why a password reset can look complete while access is still active in practice.
In governance terms, the useful question is not whether the password changed, but whether all active sessions were terminated across every device, browser, and API channel. If session invalidation is inconsistent, the old access path survives even though the human identity has moved on or the credential has been reset.
What makes offboarding especially sensitive
Offboarding is where the gap becomes most dangerous, because the organisation is no longer trying to preserve convenience for a current user. If a former employee keeps a live session, they may retain access to email, SaaS apps, file stores, or admin consoles long after HR, IT, or the application owner believes access is gone. Joiner-Mover-Leaver (JML) Guide is a useful reference point for why leaver controls must cover revocation, not just account status.
Session persistence also matters when access is delegated through shared devices, remembered browsers, or single sign-on flows that rely on refresh tokens and cached sessions. The organisation may revoke the primary account, but any surviving session on a laptop, browser profile, or mobile app can still be enough to keep operating until the platform checks again.
This is why offboarding needs a termination mindset rather than a password-change mindset. The control objective is to remove the ability to act, not merely to change the login secret used for future authentication events.
Where the control gap usually appears in practice
The failure is usually not the password reset itself. It is the missing linkage between identity lifecycle actions and session lifecycle actions, especially across SaaS applications, federated sign-on, mobile clients, and API tokens. A user may be forced to reauthenticate later, but that delay can still leave a live path open long enough to matter.
Platform behaviour also varies. Some applications immediately revoke all sessions on password change; others only do so for certain session types, or only when an administrator explicitly forces sign-out. The more distributed the environment, the more likely it is that at least one session store, refresh token, or connected app remains active after the intended cutoff.
That is why practitioners should treat session lifetime as part of identity risk management, not as a minor usability detail. The longer the session remains valid, the larger the window for misuse after compromise, theft, or offboarding.
Risk and Threat Considerations
Long-lived sessions extend the attacker’s window of opportunity after a password reset, and they can undermine offboarding if the user or attacker already has a valid token. The same weakness also increases exposure from lost devices, browser theft, and delayed revocation in federated SaaS environments.
Failure mechanism: The application or identity layer does not revoke or invalidate existing sessions when the password changes or the account is disabled, so previously issued session tokens remain trusted until expiry or manual termination.
Impact: An attacker or former user can continue accessing data and actions under the old session, bypassing the intended security effect of the password change or offboarding event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Session persistence and revocation depend on credential and token lifecycle control. |
| IA-2 — Identification and Authentication (Organizational Users) | The issue arises from how user authentication and subsequent session trust are handled. | |
| AC-2 — Account Management | Offboarding is an account lifecycle event that must remove effective access, not just disable login. | |
| Recommendation — Revoke or rotate authenticators and tokens when identity status changes. Require reauthentication and terminate trusted sessions after identity changes. Disable accounts and associated access paths as part of leaver processing. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | Authenticator and session handling must support timely access removal after password resets or offboarding. |
| Recommendation — Invalidate old sessions and credentials when identity state changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Leaver events are a direct example of access persisting after identity change. |
| NHI-07 — Long-Lived Secrets | Long-lived sessions behave like durable bearer material that extends access after change. | |
| Recommendation — Terminate all surviving sessions and secrets during offboarding. Shorten session and token lifetimes to reduce post-reset exposure. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Persistent sessions weaken the effective authentication boundary after a password change. |
| Recommendation — Ensure authentication events invalidate previously issued API and user sessions. | ||
Practitioner Guidance
What to verify: Confirm whether the application actually kills active sessions, refresh tokens, and connected device sessions when a password is changed or a user is deprovisioned. If it does not, require an explicit sign-out or token revocation step as part of the workflow.
Decision rule: If the account change is tied to compromise, termination, or device loss, treat session revocation as urgent containment, not a follow-up task. If the platform cannot revoke sessions reliably, compensate with shorter session lifetimes, stronger reauthentication triggers, and tighter monitoring.
What good looks like: A leaver or reset event should end access across browsers, mobile apps, API clients, and federated sessions quickly enough that there is no practical overlap between identity change and continued use.
Practitioner takeaway: Password changes reduce future login risk, but only session invalidation closes the already-issued access path that attackers and former users can still exploit.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org