Logout fails when teams only clear the local browser session and never invalidate the authoritative session record. Other devices keep working until they are told the session is gone, which means revocation must be propagated through the backend, not assumed from a cookie deletion on one client.
Why logout often succeeds on one device but not the whole account
Logout only changes the state the application actually checks. If the backend still treats an access token, refresh token, or server-side session as valid, another browser, phone, or embedded client can keep using it. That is why “sign out” is a revocation problem, not just a UI problem.
The practical failure usually comes from treating the browser as the source of truth. Clearing a cookie or local storage entry ends that client’s view of the session, but it does not necessarily revoke the session record, invalidate an issued token, or notify downstream services that the account should no longer be trusted.
What has to be revoked for logout to be real
Real logout depends on the session architecture. In a server-side session model, the session identifier must be invalidated centrally. In a token-based model, the access token may remain usable until it expires, so meaningful logout often requires refresh-token revocation, token blacklisting, or another backend control that shortens the window of continued access.
That distinction matters because different devices may hold different credentials at the same time. One client may use a browser session cookie, another may hold a long-lived refresh token, and a third may be authenticated through a companion app or API client. If those authorities are not tracked and revoked consistently, logout becomes partial by design.
This is why logout flows are often paired with session management and token design choices. Standards such as RFC 6749: The OAuth 2.0 Authorization Framework and token-handling patterns such as RFC 8693: OAuth 2.0 Token Exchange show why delegated access needs explicit lifecycle handling, not assumptions about browser state.
Why multi-device sign-out is harder than it looks
Logout has to work across multiple trust boundaries: the client, the identity provider, the application, and often a set of APIs or companion services. If any one of those layers keeps accepting the old credential, the user experience may look signed out while the security boundary is still open.
Single sign-on adds another wrinkle. A user can end one application session while the identity provider session stays active, allowing silent re-authentication elsewhere. That is a normal consequence of federated login, but it means a strong logout design must define whether the goal is local app logout, global account logout, or full IdP session termination.
For teams that use browser sessions plus API access, the same problem appears in different form. The browser may be logged out, but a mobile app or background sync process can continue until its token is revoked or expires. Good implementations treat every device and client as a separately tracked session, not as a mirror of the current browser tab.
Practitioners working with OAuth-based stacks should review the session and token assumptions in OAuth 2.0 and OpenID Connect Guide for Identity Teams alongside the authoritative requirements in OWASP ASVS, because the hard part is usually not authentication itself, but session invalidation and post-logout access control.
Risk and Threat Considerations
When logout does not propagate, the risk is stale access: a stolen or simply forgotten session can remain usable long after the user believes it has ended. That becomes a real exposure when the account can reach sensitive data, administrative functions, or long-lived refresh paths on another device.
Failure mechanism: The application invalidates only the visible client state, while the authoritative server-side session, refresh token, or federated identity session remains active. An attacker who already has that surviving credential can continue access without triggering a fresh login.
Impact: Users and security teams lose confidence in the logout control, incident containment takes longer, and a compromised device or browser can preserve access beyond the intended boundary. At scale, incomplete revocation also makes account recovery and forced sign-out actions unreliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V7 — Session Management | Logout failure is a session invalidation problem across devices. |
| Recommendation — Validate that logout invalidates every active session and token path. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Revocation and expiry of session-linked credentials determine continued access. |
| AC-2 — Account Management | Account/session lifecycle controls govern whether access remains after sign-out. | |
| Recommendation — Enforce timely revocation and rotation of credentials tied to sessions. Centralize account and session lifecycle actions so sign-out is effective. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control policy must define when access ends after logout. |
| Recommendation — Define and enforce access revocation rules for all active sessions. | ||
Practitioner Guidance
What to verify: Confirm that logout revokes the authoritative session object, not just the client cookie or local storage entry. If the environment issues refresh tokens or supports SSO, verify the exact point where global sign-out is enforced and how long residual access can survive.
Decision rule: If a credential can still authenticate after logout from a different device, treat the design as incomplete until revocation is centralized or the token lifetime is acceptably short. If the user experience requires instant account-wide sign-out, do not rely on expiry alone.
Practitioner takeaway: Treat logout as a backend revocation workflow with multiple session types, because the control is only real when every surviving authentication path is invalidated or rendered unusable.
Related resources from NHI Mgmt Group
- Who is accountable when offboarding workflows fail to remove device access and application access in time?
- Why do ephemeral credentials still leave risk in machine access models?
- Why do access reviews fail to remove unnecessary permissions?
- Who should be accountable when access reviews fail to remove excessive privileges?
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