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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “How to revoke sessions and sign users out everywhere with the WorkOS Sessions API”.
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
Key questions
Q: What breaks when session revocation is missing from identity controls?
A: Without revocation, a valid session can continue to authenticate after the user resets a password, loses a device, or leaves the organisation.
Q: Why do long-lived sessions increase identity risk after a password change or offboarding event?
A: Because a password change only protects future authentication unless the application also kills existing sessions.
Q: How can organisations tell whether session revocation is actually working?
A: Look for rejected reuse attempts on revoked session IDs, complete revocation coverage after lifecycle events, and audit logs that show who revoked what and when.
Practitioner guidance
- Implement server-side session revocation Make session invalidation authoritative on the backend so stolen cookies and old devices stop working even if local browser state persists.
- Build sign-out-everywhere flows List active sessions for the user, revoke each session by ID, and clear the initiating device locally so the action actually ends access everywhere.
- Revoke all sessions after password resets Tie password change workflows to automatic revocation so a reset does not leave pre-existing sessions alive on laptops, phones, or shared devices.
Bottom line: SaaS session management is a containment control because active sessions can outlive password resets, device loss events, and offboarding.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 6:13 pm
Session revocation is the control boundary that turns authentication into containment: password resets, device loss response, and offboarding only reduce risk if the backend can invalidate active sessions immediately. In SaaS, access is often distributed across multiple devices and browser contexts, so the real security question is whether the platform can end those sessions centrally. Practitioners should treat revocation as a first-class identity control, not a convenience feature.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should organisations do when users sign in from multiple devices?
A: They should assume every device creates a separate active session and design controls that can list, revoke, and audit each one independently. That makes it possible to support enterprise features such as sign out everywhere without leaving hidden sessions behind on unmanaged devices or shared endpoints.
👉 Read our full editorial: Session revocation is the missing control in SaaS identity security
This post was modified 4 days ago by NHI Mgmt Group