Session Timeout Best Practices

Between July and September 2026, an attacker broke into Microsoft 365 email at 79 organizations without a single password. According to Huntress, the attacker replayed session tokens stolen after users completed MFA, logging 497 successful sign-ins. In one case, the hijacked session appeared four minutes after the victim reached the MFA prompt. Access ended only when a session expired or someone revoked it.

That detail explains why session lifetime matters. A stolen session works for as long as the system lets it live. A session timeout is a security control that ends an authenticated session after a set period of inactivity (idle timeout) or a fixed total duration (absolute timeout), forcing the user to sign in again. Set it too long, and a stolen token or an unlocked shared workstation stays open for hours. Set it too short, and users start finding workarounds.

This guide covers session timeout best practices: timeout types, values by risk, enforcement, the settings that defeat them, and shared devices.

What is a Session Timeout?

After sign-in, the server issues a credential that proves the login has already happened, so users don’t authenticate on every request. Applications store that proof in one of two ways:

• Stateful sessions keep the record on the server and hand the browser a random session ID in a cookie. Deleting the record instantly kills every copy of that cookie.
• Stateless tokens, such as JWTs, carry their own expiry time. They stay valid until expiry unless the system checks a revocation list.

Most logins run three timers at once: the application session, the identity provider’s SSO session, and the access and refresh tokens. A session timeout protects users only when all three agree. If the app session ends but a refresh token lasts 30 days, anyone holding that token can quietly get back in.

Session Timeout vs Reauthentication

Both require proving identity again, for different reasons.

OWASP recommends reauthentication after risk events like a new device or account recovery, even mid-session.

Why Session Timeouts Matter for Security and Compliance

Hijacking and fixation both need a session that stays valid, so shorter windows give attackers less time.

Compliance frameworks set clear limits:

• PCI DSS Requirement 8.2.8 requires users to reauthenticate after 15 minutes of idle time (PCI SSC), covered in our PCI DSS access control checklist.
• HIPAA lists automatic logoff (§164.312(a)(2)(iii)) as an addressable safeguard, covered in our HIPAA access control checklist.
• NIST SP 800-63B-4 sets reauthentication limits for each assurance level, reflected in the recommended timeout values in the next section.

Types of Session Timeouts

Session timeout best practices combine these four types.

Idle Timeout

An idle timeout ends the session after a set period with no user activity. It protects unlocked screens and unwatched browser tabs. OWASP recommends setting session expiration based on application risk, sensitivity of the data, and the impact of session compromise. High-risk applications should use shorter inactivity windows, while lower-risk applications may allow longer sessions. In both cases, an absolute timeout should limit the total session lifetime.

Absolute Timeout

An absolute timeout ends the session after a fixed duration, however active the user stays. It caps the damage from a stolen session, because an attacker who keeps it busy still gets cut off. OWASP suggests 4 to 8 hours for a typical office workday.

Rolling (Sliding) Timeout

A rolling timeout resets the clock with each user action, so it never cuts off an active user mid-task. The risk sits in what counts as activity. Background API calls and auto-refreshing pages can reset it forever, so count only real user actions and always pair a rolling timeout with an absolute limit.

Renewal Timeout

A renewal timeout issues a new session ID at intervals during a long session and invalidates the old one. It limits how long a copied session ID stays useful, which matters on long shifts where a short absolute timeout would disrupt work.

Recommended Session Timeout Values by Risk Level

Session timeout best practices scale each limit to the risk of the access.

Sources: NIST SP 800-63B-4, OWASP.

These values are practical starting points, not universal requirements. NIST assurance-level requirements and PCI DSS applicability should be evaluated separately from an organization's internal risk-based policy. The final configuration should account for the sensitivity of the application, the authentication method, and the consequences of session compromise.

How to Enforce Session Timeouts Correctly

Enforce Expiration on the Server

Client-side timers are easy to bypass, so session timeout best practices put enforcement on the server, which rejects expired sessions on every request.

Rotate the Session ID After Login and Privilege Changes

Issue a new session ID after sign-in, role changes, and password resets. Rotation blocks session fixation.

Secure the Session Cookie

Set Secure, HttpOnly, and an explicit SameSite value, and use the __Host- prefix where possible. Keep tokens out of localStorage, where any cross-site scripting flaw can read them.

Revoke Every Token at Logout

Logout must invalidate the server session and revoke refresh tokens. For federated sign-in, use single logout so the identity provider session ends too.

Settings That Defeat Your Session Timeout

These settings undo timeouts in production:

• Tokens that outlive the session. An Auth0 community thread shows access tokens working after session expiry until their lifetime matches the session’s.
• Remember Me cookies. ServiceNow notes that Remember Me lets users resume after the 30-minute default timeout.
• Auto-refreshing dashboards. Pages that poll the server keep sessions active indefinitely.
• Browser session restore. A restored browser can revive a session the user thought had ended.

Session Timeouts on Shared Devices and Frontline Workstations

Most session timeout best practices assume one person per device. Warehouse scanners and retail terminals break that assumption. A 30-minute idle timeout means the next worker can inherit an open session, and every action gets logged under the wrong name. A 2-minute timeout forces frontline workers to sign in dozens of times a shift, which pushes teams toward shared passwords.

Presence-Based Locking and Fast User Switching

Shared workstations need session controls tied to the person at the screen. Presence detection locks the session when the worker steps away, and fast user switching lets the next worker sign in without inheriting the last session. OLOID’s continuous authentication applies this to shared devices.

Balancing Session Security and User Experience

Session timeout best practices only work if people accept them. Show a countdown warning before logout. Reserve the tightest limits for privileged access and regulated data.

Monitoring Sessions for Hijacking

Session timeout best practices also need monitoring. Log session creation, renewal, timeout, and logout, using hashed session IDs. Alert when a session suddenly changes IP, device, or location, and let users end their active sessions.

Session Timeout Best Practices Checklist

• Set an idle and an absolute timeout for every application.
• Enforce expiration on the server.
• Rotate session IDs after login and privilege changes.
• Harden session cookies with Secure, HttpOnly, and SameSite.
• Match token lifetimes to session lifetimes.
• Revoke refresh tokens at logout.
• Require reauthentication for sensitive actions.
• Use presence-based locking on shared workstations.

Secure Sessions Beyond the Timeout

Session timeouts are an essential security control, but they are only one part of session management.

Organizations must also enforce expiration on the server, manage token lifetimes, revoke access when sessions end, and require reauthentication when risk increases.

For frontline environments, the challenge is making those controls work across shared workstations without disrupting the workforce.

OLOID helps organizations secure shared devices with passwordless authentication, presence-based locking, and individual user accountability. Workers can sign in quickly, while sessions remain tied to the person using the device.

The result is stronger session security without relying on short timers or shared credentials to protect frontline workflows.

Book a demo to see how OLOID secures shared workstations.

FAQs

1. What is a good session timeout?

Session timeout best practices size it to risk. NIST recommends no more than 1 hour idle and 24 hours overall for most workforce apps (AAL2), and 15 minutes idle with a 12-hour cap for privileged access (AAL3). PCI DSS requires reauthentication after 15 minutes idle for systems in scope.

2. What is the difference between idle timeout and absolute timeout?

An idle timeout ends a session after a period without user activity, which protects unattended screens. An absolute timeout ends it after a fixed total time, which caps how long a stolen session can last. Session timeout best practices use both together, since each covers a gap the other leaves open.

3. Does PCI DSS require a 15-minute session timeout?

Yes. PCI DSS Requirement 8.2.8 requires users to reauthenticate after 15 minutes of idle time. The PCI Security Standards Council notes that a screensaver lock that requires reauthentication can satisfy it, and that single-transaction POS accounts fall outside it.

4. Does ending a session revoke access tokens?

Not automatically. Access tokens issued before logout keep working until they expire unless the application revokes them. Match token lifetimes to session lifetimes, revoke refresh tokens at logout, and invalidate the server session so copied cookies stop working immediately.

5. Should session timeouts be enforced on the client or server?

Session timeout best practices put enforcement on the server. Client-side timers help by warning users before logout, but attackers can bypass them. The server must reject any request that uses an expired session.