Why do revoked user sessions sometimes remain active on other devices?

Why This Matters for Security Teams

Revoked sessions that still work elsewhere are rarely a sign that revocation failed completely. More often, the backend has invalidated the session, but the device has not yet learned that the token is no longer valid. That delay becomes a security problem when teams assume logout, password reset, or account disablement produces immediate containment across every client.

The practical risk is persistence. An attacker who already has a valid session, refresh token, or device-bound credential may continue operating until the next sync, poll, or reauthentication event. This is why session state, token TTL, and event propagation must be treated as a single control surface, not separate products. NHI Management Group’s NHI Lifecycle Management Guide shows that identity state only becomes useful when it is consistently enforced across issuance, use, revocation, and recovery.

OWASP’s OWASP Non-Human Identity Top 10 reaches the same operational conclusion for machine identities: revocation is only effective when the control plane and every dependent workload actually honor it. In practice, many security teams discover stale sessions only after an account takeover, not through intentional validation of their revocation path.

How It Works in Practice

Session revocation is usually a two-step problem. First, the authority decides that a session is no longer valid. Second, the clients, gateways, and downstream services must stop accepting it. The gap between those steps explains why a user may still look signed in on another device after a password change, MFA reset, or admin-initiated logout.

Effective implementations combine several mechanisms rather than relying on one:

• Short-lived access tokens reduce the window in which a stolen session remains useful.

• Refresh-token rotation makes replay harder and allows the server to invalidate the chain.

• Event-driven revocation pushes logout or disablement signals to active devices when the platform supports it.

• Forced reauthentication ensures high-risk actions check current session state instead of trusting old proof indefinitely.

• Session metadata, including device fingerprint, IP context, and last-seen time, helps distinguish legitimate stale state from active abuse.

This is also where NHI discipline matters. If a system relies on long-lived secrets, the revocation story is weak by design. The Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why dynamic credentials and tighter TTLs create a smaller blast radius than persistent tokens that survive across devices and sessions.

For teams designing stronger identity flows, NIST’s Digital Identity Guidelines support reauthentication and session management as part of the trust boundary, while the Guide to the Secret Sprawl Challenge shows how fragmented credential stores make it harder to ensure revocation reaches every place a session may still be cached. These controls tend to break down in offline-first mobile apps and disconnected desktop clients because the device cannot receive the invalidation signal until it reconnects.

Common Variations and Edge Cases

Tighter session control often increases friction, requiring organisations to balance fast containment against user experience and support load. That tradeoff is real, especially when the same account is active on multiple devices, browsers, or embedded clients.

There is no universal standard for instant revocation across all platforms yet. Some systems favor aggressive token expiry, while others depend on push-based invalidation or server-side session lookups. Best practice is evolving toward layered controls, not a single perfect switch. In higher-risk environments, such as finance or admin portals, the safer pattern is to combine short TTLs with explicit step-up authentication for sensitive actions.

Edge cases matter. A session may appear active because:

• the client caches identity state locally and has not refreshed it yet;

• a reverse proxy or API gateway still honors an older token until its cache expires;

• a refresh token was not revoked even though the access token was;

• device trust or SSO federation introduces another acceptance layer outside the primary app.

Where revocation is tied to broader identity hygiene, the Top 10 NHI Issues is useful because the same stale-credential patterns that keep machine identities alive can also keep user sessions alive. In environments with offline access, federated IdPs, or multiple cached tokens per device, revocation works unevenly because the authority is central but enforcement is distributed.

Related resources from NHI Mgmt Group

• Should organisations prioritise phishing-resistant MFA over other identity projects?
• How should organisations choose passwordless methods for different user types?
• What role should MFA play when passwords remain in use?
• What should organisations check before removing passwords from user access flows?