Should organisations let users revoke their own sessions or reserve it for admins?

Should users be able to revoke their own sessions?

User-facing session revocation is a practical control, not just a convenience feature. It gives people a fast way to contain suspicious activity when they lose a device, reuse a browser, or notice an unexpected login. The key design point is that self-service revocation should terminate active sessions immediately, while preserving a consistent backend policy and audit trail.

That matters because session revocation sits at the intersection of authentication, account recovery, and incident response. If the user path and the admin path use different revocation logic, you create uneven behaviour, inconsistent logging, and support confusion. A single revocation service with role-based entry points is usually the safest pattern, because it keeps the control model simple while still giving different actors the right level of authority.

For broader identity and session governance, the lifecycle view matters as much as the control itself. NHIMG’s NHI Lifecycle Management Guide is a useful reminder that revocation is only one stage in a larger ownership, rotation, and offboarding process. In practice, the same backend revocation logic should also support credential invalidation, token expiry, and any linked access cleanup so that a session kill actually reduces exposure.

When does admin-only revocation still make sense?

Admin-only revocation is appropriate when the action needs escalation control, for example during support cases, suspected compromise, or account recovery where the user cannot be trusted to act safely. It is also useful when the organisation needs to preserve evidence, prevent premature logout during an investigation, or apply a policy decision across multiple sessions or devices at once.

The trade-off is speed versus control. If only admins can revoke sessions, response quality depends on help desk availability and incident handling maturity. If users can revoke only their own sessions, they reduce the blast radius of an individual account, but they cannot help with broader containment after a suspected compromise. The best model is usually dual-path, with users handling self-protection and admins handling cross-account or cross-device enforcement.

That dual-path model is consistent with common identity hygiene issues such as stale sessions, shared devices, and excessive access persistence. The Top 10 NHI Issues and OWASP Non-Human Identity Top 10 both reinforce the same operational principle, access should be removable quickly, consistently, and with clear ownership when it is no longer safe to keep it active.

What should a good revocation design include?

A good design does three things well. First, it uses one authoritative backend revocation path so user-initiated and admin-initiated actions behave the same way. Second, it records who initiated the revocation, when it happened, and which sessions were terminated. Third, it handles edge cases such as mobile apps, refresh tokens, remembered devices, and single sign-on sessions so the session really ends rather than only appearing to end.

That is especially important for long-lived or distributed access patterns. If the session is tied to a token, key, or cached authentication state, revocation must invalidate the underlying grant, not just the browser cookie. NHIMG’s Guide to NHI Rotation Challenges and the Guide to the Secret Sprawl Challenge are both relevant because they highlight a broader truth: access only becomes safer when the controlling material is actually invalidated, not merely hidden from view.

Practitioner Guidance

What to prioritise: Give users self-service revocation for their own sessions, but keep admin revocation for support, incident response, and forced containment. The user path should be fast and low-friction; the admin path should be authoritative and auditable.

What to verify: Confirm that both paths call the same backend revocation function, terminate refresh capability where applicable, and write the same audit events. If the user action only logs out one device while the admin action kills all tokens, you do not have equivalent controls.

Common mistake: Treating “logout” as equivalent to “session revocation.” A visible UI logout that does not invalidate active tokens, device trust, or federated sessions leaves exposure behind.

Decision rule: If the session can be used to access sensitive data or privileged actions, the revocation control should be available quickly to the user and enforceably to admins, with escalation for exceptions rather than a single rigid workflow.

Practitioner takeaway: The control should be designed around one revocation engine with two entry points, because consistency, speed, and auditability matter more than deciding whether the user or the admin clicks the button.

Related resources from NHI Mgmt Group

• What happens when organisations let users run browser sessions without inside-the-browser controls?
• How should organisations establish trust when users bring their own identity across multiple services and devices?
• How should small and midsize organisations reduce the risk of credential compromise without adding too much friction for users and admins?
• What breaks when organisations let agencies use their own credentials to manage brand accounts?