What is the difference between idle timeout and absolute timeout?

An idle (inactivity) timeout ends the session after a period with no user activity, and is typically reset on each request. An absolute timeout caps the total session lifetime regardless of activity, forcing periodic re-authentication. OWASP recommends enforcing both.

What does NIST SP 800-63B say about session timeouts?

NIST SP 800-63B ties reauthentication to the assurance level: AAL1 allows up to 30 days, AAL2 requires reauthentication at least every 12 hours or after 30 minutes of inactivity, and AAL3 every 12 hours or after 15 minutes of inactivity. Higher-risk data warrants shorter windows than these maximums.

Why does authentication strength change the recommended timeout?

Stronger authentication lowers the cost of re-authenticating and reduces the chance an attacker can hijack a session, so phishing-resistant passkeys justify longer sessions. Password-only auth is more easily phished or replayed, so the tool shortens the recommended window to reduce exposure.

Should a shared or public device use a shorter timeout?

Yes. On a shared, kiosk, or public device the next person could resume an abandoned session, so the tool sharply shortens the recommendation. Pair the short timeout with a visible sign-out control and avoid persistent remember-me tokens on those devices.

Will a short idle timeout hurt the user experience?

It can, if active users get logged out mid-task. The calculator flags this when your typical session is longer than the idle window. The fix is sliding expiry — reset the idle timer on each request — combined with a separate, longer absolute cap rather than one short hard cutoff.

Session Timeout UX & Security Calculator

A session timeout that is too long leaves hijacked or abandoned sessions exploitable; one that is too short logs users out mid-task and drives them away. This tool turns four risk inputs into a concrete idle timeout and absolute re-authentication cap, anchored to NIST SP 800-63B and the standards real banks, SaaS apps, and content sites use.

How it works

The recommendation starts from a baseline idle timeout chosen by data sensitivity — 5 minutes for critical/banking data, 15 minutes for high-risk PII, 30 minutes for typical SaaS, and 24 hours for low-risk content. Two multipliers then adjust it:

Authentication strength scales the baseline: password-only multiplies by 0.6 (shorten), MFA by 1.0, and phishing-resistant passkeys by 1.4 (allow a longer window).
Device context scales it again: a personal/managed device multiplies by 1.0, a possibly shared device by 0.6, and a public/kiosk device by 0.3.

The result is clamped to a sensible floor and ceiling. The absolute session lifetime is then set to roughly three times the idle window, capped per sensitivity level (for example, critical data never exceeds a 30-minute absolute lifetime). If your typical active session is longer than the computed idle window, the tool warns that you should use sliding expiry (reset the idle timer on each request) so engaged users are not logged out while working.

Example

For high sensitivity data, MFA, and a mixed device: baseline 15 min, times 1.0 (MFA), times 0.6 (mixed device) gives a recommended idle timeout of 9 min and an absolute cap of about 27 min. Switching to a public device drops the idle timeout to roughly 4–5 min.

Notes and tips

Always implement both an idle and an absolute timeout — OWASP Session Management treats them as complementary controls, not alternatives.
Invalidate the session server-side on logout and timeout; clearing the cookie client-side is not enough.
For remember-me on personal devices, prefer rotating refresh tokens over a single long-lived session cookie, and never extend remember-me to shared devices.
These are starting points, not legal requirements — your regulator (PCI DSS, HIPAA, FCA) may mandate a specific maximum. Use the table as a sanity check against your sector’s norm.