ASVS 5.0 V7.1.1 (Level 2) requires a written record of your session inactivity timeout and your absolute maximum session lifetime, a statement that the two values fit together with your other controls, and a justification for any place you deviate from the NIST SP 800-63B reauthentication guidance.
Why it matters
Timeouts that live only in a config file get changed by accident. Someone raises the idle timeout to stop a support complaint, and nobody remembers why it was 15 minutes. A document gives reviewers, auditors and future developers a baseline to compare against.
It also forces a real decision. A banking admin console and a recipe site should not share the same numbers, and the document is where you explain the difference.
How to implement it
Write one short page per application, kept next to the code. Include these fields:
- Idle timeout, in minutes, per user role or assurance level.
- Absolute lifetime, in hours, after which the user must sign in again.
- Whether "remember me" exists and what it changes.
- The NIST SP 800-63B baseline you compared against, and each deviation with a reason, an owner and a review date.
- The config key or environment variable that holds each value.
A small file works well:
# docs/security/session-policy.yaml
idle_timeout_minutes: 15
absolute_lifetime_hours: 12
remember_me: false
nist_800_63b_deviations:
- topic: "Reauthentication at AAL2"
deviation: "Idle timeout is 15 minutes, guidance allows 1 hour"
reason: "Admin console handles payout approvals"
owner: "appsec"
review_by: "2027-04-01"
config_keys: ["SESSION_IDLE_MINUTES", "SESSION_MAX_HOURS"]
How to test it
Compare the document against reality. Sign in, stay idle for the documented idle period plus one minute, and confirm the next request is rejected. Then keep a session active past the absolute lifetime and confirm you are forced to sign in. If either result differs from the page, one of them is wrong.
Common mistakes
- Documenting only the idle timeout and forgetting the absolute lifetime.
- Copying the NIST numbers without checking what the application actually does.
- Letting the document go stale after a config change. Add the file to your pull request checklist.
Quick check
Does V7.1.1 require specific timeout values?
No. It requires that the values are documented, make sense together, and that deviations from NIST SP 800-63B are justified. Your risk analysis picks the numbers.
