TL;DR: Stolen sessions can survive logout or idle expiry and keep Microsoft 365 email accessible at 79 organizations when session cookies, access tokens, and refresh tokens are not aligned, according to OLOID research. Timeout controls only work when the server ends the whole authentication state, not just the browser session.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OLOID's blog post: Session timeout best practices depend on aligning idle, absolute and token lifetimes, or stolen sessions can remain usable after MFA and logout.
Why it matters: IAM teams need to treat session lifetime as a control boundary across human and non-human access, because token persistence can defeat otherwise sound sign-in policy.
Context
Session timeout is not just a browser setting. It is a governance control that decides how long an authenticated state can survive after sign-in, and it only works when the application, identity provider session, and tokens all expire together.
The failure mode is familiar in IAM programmes: one layer ends while another stays valid. That mismatch matters for human access, but it also maps directly to the way long-lived tokens and shared device sessions extend exposure beyond the point where most teams think access has ended.
Key questions
Q: What should teams do first when a session token is stolen?
A: Revoke the stolen session, invalidate the server-side session record, and force credential reissue by rotating the underlying refresh tokens or other long-lived secrets. If the token was minted from an identity provider session, terminate that session too, then review logs for replayed use, abnormal IPs, and any scoped API access granted through the token.
Q: Why can logout fail to end access in SSO environments?
A: Logout can end the application session but leave the identity provider session active, so a new login may be created automatically without fresh authentication. In SSO, session state can also persist in browser cookies, SAML or OIDC refresh flows, or a central session cookie, so both the app and the identity provider session must be cleared.
Q: How do idle timeout and absolute timeout work together?
A: Idle timeout ends a session after a period of inactivity, while absolute timeout ends it after a fixed maximum lifetime regardless of use. Together they limit both abandoned sessions and overly long credential exposure, especially for API tokens, service account sessions, and admin portals. The shorter limit wins when both apply.
Q: How should teams secure sessions on shared workstations?
A: Secure shared workstations by using short idle timeouts, automatic screen lock, and re-authentication before any privileged action. Presence-based locking can combine proximity signals, badge state, or local presence checks with the lock state, but it should never be the only control for protecting active sessions, cached credentials, or open admin tools.
Technical breakdown
Idle timeout versus absolute timeout
Idle timeout ends a session after inactivity, while absolute timeout ends it after a fixed maximum duration regardless of use. The distinction matters because each control addresses a different abuse path. Idle timeout protects unattended devices and abandoned browser tabs. Absolute timeout limits how long a stolen session can be replayed even if the attacker keeps it alive with activity. In practice, both are needed because a session that never goes idle can still outlive the risk window if there is no hard ceiling. See the Token and Session Security Guide.
Practical implication: Set both timers on the server and make the absolute limit the final cutoff, even when activity continues.
Why refresh tokens can outlive session expiry
A browser session can end while a refresh token remains valid, which means the user interface looks closed even though the authentication state still exists behind the scenes. That is the core mismatch in modern SSO architectures: the session cookie, the identity provider session, and the token set are related but not identical. If logout only clears the browser state, an attacker with a copied refresh token can silently obtain new access tokens until the refresh token itself is revoked or expires. See the SaaS-to-SaaS and OAuth App Governance Guide.
Practical implication: Revoke refresh tokens at logout and align token lifetimes with the session boundary.
What shared workstations do to session controls
Shared devices break the assumption that one session belongs to one person for its full lifetime. In frontline environments, the next worker can inherit a live session if the previous user steps away, and a short idle timeout can push people toward shared passwords or risky workarounds. Presence-based locking changes the control model from time alone to occupant awareness, which is more suitable where devices move between users across a shift. The issue is not just convenience; it is attribution and session ownership.
Practical implication: Use presence-based locking and fast user switching on shared devices instead of relying on short timers alone.
Threat narrative
Attacker objective: The objective is to maintain authorized-looking access long enough to read mail, impersonate the user, or move into adjacent systems without reauthentication.
- entry: The attacker enters through a valid authenticated session rather than a guessed password, usually after a user completes MFA and a session token is captured or replayed.
- credential_harvested: The usable artifact is the session token or refresh token, which continues to prove identity even after the original login flow is finished.
- escalation: The attacker keeps the session alive or renews access until logout, token revocation, or expiry finally removes the privilege.
- impact: The attacker reads mail, acts inside the victim's account, or performs follow-on fraud while appearing to be an authenticated user.
Breaches seen in the wild
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Session timeout is only meaningful when every authentication state ends together. A browser session, an identity provider session, and a refresh token are separate control surfaces, so closing one does not guarantee the others are gone. The governance error is to treat logout as a single event when it is really a chain of expirations and revocations. Practitioners should review session design as one lifecycle, not three disconnected timers.
Long-lived tokens create an exposure window that defeats intuitive timeout policy. The problem is not merely that tokens last too long, but that they preserve authenticated state after the user believes the session has ended. That is why timeout policy must be paired with token revocation and token lifetime discipline, especially where federated sign-in is involved. Teams that miss this separation will keep seeing post-logout access in review and incident response.
Shared devices expose a session ownership problem, not just a timeout problem. On a warehouse scanner, terminal, or clinic workstation, a session can outlive the person who started it and become attributable to the wrong user. Authentication Guide is useful here because the issue is identity continuity across a device handoff, not simply inactivity. The practitioner conclusion is that presence and handoff controls matter as much as timer length.
Presence-based locking is the better control model for shift-based environments. A timer assumes the only risk is time; shared frontline workflows introduce turnover, interruption, and physical movement. That means the security decision must track whether the worker is still present, not just whether the session has been idle. For high-churn environments, session governance should shift from duration-first thinking to occupancy-aware access control.
Session hygiene is now part of identity lifecycle governance. A session that ends late, or not at all, is a lifecycle failure because access outlives the business context that justified it. The named concept here is session lifetime mismatch: the period in which a token remains valid exceeds the period in which the session was intended to exist. Practitioners should treat that mismatch as a governance defect, not a user-experience compromise.
What this signals
Session governance is shifting from timer management to state management. Organisations that only tune inactivity windows will keep missing the bigger failure mode, which is a session, token, or identity-provider state that survives after the user thinks access is gone. The operational question is no longer how long a session lasts, but which state changes actually terminate it.
Session lifetime mismatch: when the browser session, token lifetime, and federation session are not aligned, logout becomes an event with uneven effects. That pattern will keep surfacing in incident response because attackers do not need a password if a valid token still exists. Identity teams should expect more scrutiny of revocation paths, not just timeout values.
Where shared devices are part of the workflow, security programmes need to treat physical presence as an identity signal. Duration-based controls will always be weaker than occupancy-aware controls in shift work, retail, logistics, and healthcare. The practical implication is that session policy must be adapted to device sharing rather than copied from single-user office assumptions.
For practitioners
- Set both idle and absolute timeouts Define a short inactivity window and a hard total lifetime for each application, with stricter values for privileged and regulated access. See the Token Lifetime Policy Design Guide.
- Revoke every token at logout Invalidate the server session, revoke refresh tokens, and ensure federated sign-out ends the identity provider session as well.
- Move enforcement to the server Reject expired sessions on every request and use client-side timers only for warnings, not enforcement.
- Harden shared workstations Use presence-based locking and fast user switching where devices are shared across shifts so the next user never inherits the prior session.
- Require step-up for sensitive actions Ask for reauthentication before high-risk actions such as password changes, exports, or recovery events even when the user is already signed in.
Key takeaways
- Session timeout policy fails when one layer ends while another still accepts the user, because stolen or copied authentication state can keep working after the visible session closes.
- The Microsoft 365 intrusion described here shows that replayed session tokens can remain effective after MFA, with 497 successful sign-ins across 79 organisations.
- The control gap is not just a short idle timer. Teams need server-side enforcement, token revocation, and shared-device controls that follow the person using the workstation.
Related NHI Mgmt Group resources: SaaS-to-SaaS and OAuth App Governance Guide · Token and Session Security Guide · Token Lifetime Policy Design Guide · Authentication Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived sessions and refresh tokens extend exposure beyond the intended access window. |
| NHI-04 — Insecure Authentication | Session replay after MFA shows that authentication state can remain exploitable after sign-in. | |
| Recommendation — Audit session and token lifetimes against NHI-07 and shorten any path that outlives the session boundary. Apply NHI-04 to close replay paths and align post-authentication state with revocation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Session and refresh token handling are part of authenticator lifecycle management. |
| AC-6 — Least Privilege | Overly durable sessions preserve access longer than the business need justifies. | |
| Recommendation — Use IA-5 to govern token issuance, renewal, revocation, and expiry as one lifecycle. Constrain session duration and reauthentication scope to the minimum necessary access window. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Session expiry and token revocation determine whether authorisation still exists after logout. |
| Recommendation — Tie session expiration and revocation to entitlement changes so access stops when authorisation ends. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Replayable session tokens enable attackers to reuse credentials and move through email and SaaS. |
| Recommendation — Map token replay to TA0006 and TA0008, then hunt for post-MFA session abuse in your telemetry. | ||
Key terms
- Session Timeout: Session Timeout is the automatic ending of a user session after inactivity or after a fixed duration. It limits how long a stolen or unattended session remains usable. Practitioners should set timeouts based on risk, protect reauthentication for sensitive actions, and review whether idle sessions remain active in browsers, apps, and remote access tools.
- Idle Timeout: Idle timeout is the period of inactivity allowed before a session, connection, or application automatically ends. It is usually enforced by tracking keyboard, mouse, network, or API activity, then invalidating the session or token when no activity occurs within the configured window.
- Absolute Timeout: Absolute timeout is the maximum lifetime of a session, regardless of activity. After the fixed limit is reached, the user must authenticate again and any session token or cookie tied to that session should no longer be accepted.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org