Notifications
Clear all
Topic starter
08/06/2026 4:31 pm
TL;DR: Long-lived sessions can remain valid for weeks or months after password resets, device loss, or employee offboarding, according to WorkOS, which is why the ability to list and revoke active sessions is now a core SaaS security control. Session management is no longer just UX plumbing; it is the control that determines how quickly identity risk can be contained.
NHIMG editorial — based on content published by WorkOS: How to revoke sessions and sign users out everywhere with the WorkOS Sessions API
Questions worth separating out
Q: How should security teams handle active sessions after a password reset?
A: Security teams should revoke every active session when a password is reset, then force all authenticated clients to revalidate on the next request.
Q: Why do long-lived sessions increase account takeover risk?
A: Long-lived sessions increase risk because they keep working after the event that should have invalidated them, such as device theft, offboarding, or credential exposure.
Q: What breaks when sign out everywhere only clears local cookies?
A: If sign out everywhere only clears local cookies, other devices and API clients can stay authenticated until their sessions expire naturally.
Practitioner guidance
- Revoke all active sessions after password resets Treat password change as an access termination event, not just a credential update.
- Expose session inventory to users and admins Show active session metadata such as device, IP address, and last active time so users can terminate unfamiliar sessions and support teams can target specific risk.
- Validate revoked sessions on the server side Reject revoked session IDs at the application boundary and clear local tokens or cookies only after the server confirms the session is no longer valid.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Node.js code for listing active sessions and revoking them by session ID.
- A complete sign out everywhere flow that clears the initiating device and handles invalid sessions on other devices.
- Session metadata examples showing how IP address, user agent, and expiry can support selective revocation.
- Event-driven revocation handling through the session.revoked event and webhooks.
👉 Read WorkOS's guide to revoking sessions and signing users out everywhere →
Session revocation and sign-out everywhere: are your controls enough?
Explore further
08/06/2026 6:13 pm
Session revocation is the control boundary that separates authentication from access termination. Password reset alone does not end access if old sessions survive across devices and clients. That is not a minor implementation detail. It is the point where identity assurance stops and residual access risk begins, which is why session lifecycle governance belongs in the same conversation as offboarding and privilege removal.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when revoked sessions keep working after access should end?
A: Accountability sits with the identity and application owners because session termination is a governance control, not a convenience feature. In regulated or audited environments, teams should be able to show that offboarding, password reset, and incident response all trigger authoritative session invalidation. If they cannot prove that, the control is not complete.
👉 Read our full editorial: Session revocation is the missing control in SaaS identity security
