What This Objective Requires
AC.L2-3.1.10[a] requires you to define an inactivity timeout period for interactive sessions. When a user is idle longer than the defined threshold, the session should lock or require reauthentication.
This control is about setting a clear, repeatable standard that can be applied consistently across systems that handle sensitive work. If you’re building a broader CMMC Level 2 compliance program, session timeouts are a foundational safeguard that helps reduce exposure from unattended access.
Why Inactive Sessions Are a Security Risk
Idle sessions create opportunity. If a workstation or remote session is left unattended, sensitive information may be viewed, copied, or altered without the user’s knowledge.
Defined timeouts reduce this risk by limiting how long an authenticated session stays open when no one is actively using it. This also improves accountability by making it clearer when user activity ended.
How to Define and Apply Session Timeout Durations
Choose a timeout duration that balances security and usability. Many organizations set the baseline between 10 and 15 minutes, then apply shorter timeouts for higher-risk scenarios such as administrative sessions or systems with elevated privileges.
Document the chosen duration in your Access Control Policy, System Security Plan (SSP), and configuration baseline or hardening guidance. For ongoing NIST 800-171 compliance, ensure the setting is implemented consistently and reviewed when system roles or risk levels change.
Apply the timeout broadly across endpoints and interactive access paths, including workstations and laptops, servers with interactive logins, and remote access portals where users can access CUI-related systems.
Session Timeout Implementation Table
| System or Access Type | Recommended Approach | Typical Timeout Range | What to Document |
|---|---|---|---|
| Workstations and laptops | Auto-lock after inactivity; require reauthentication | 10–15 minutes | Policy value, baseline setting, enforcement method |
| Servers with interactive logins | Restrict interactive use; enforce stricter idle lock | 10 minutes or less | Server standards, access restrictions, configuration evidence |
| Privileged/admin sessions | Shorter timeouts; require reauth for resumed access | 5–10 minutes | Role-based rationale, privileged access procedures, settings |
| Remote access portals and web consoles | Session expiration and idle timeout; re-login required | 10–15 minutes | Portal configuration, timeout policy, verification steps |
| Shared or kiosk-like systems (if used) | Minimize session persistence; enforce fast lockout | 2–5 minutes | Use case justification, compensating controls, configuration |
Evidence Assessors Commonly Expect
Assessors commonly look for documented timeout durations and proof the values are implemented. This may include policy language, SSP references, configuration standards, and screenshots or configuration outputs showing the lock or reauthentication threshold.
If different timeouts exist by role or system type, ensure the rationale is documented so variations are clearly risk-based rather than accidental.
Common Gaps to Avoid
Common gaps include having no documented timeout value, allowing inconsistent timeout settings across systems without justification, or using a threshold that is so long it leaves idle sessions exposed.
Another frequent issue is configuring a timeout but failing to enforce reauthentication when the session resumes, which can reduce the control’s practical effectiveness.
How Cuick Trac Supports This Objective
Cuick Trac supports this objective by helping teams apply consistent inactivity timeout expectations within controlled environments and maintain clearer documentation around baseline settings.
This helps reduce configuration drift and supports audit readiness by making the timeout standard easier to define, verify, and maintain over time.
FAQ
What does AC.L2-3.1.10[a] require?
It requires organizations to define how long a session may be idle before it automatically locks or requires reauthentication.
What is a common inactivity timeout duration?
Many organizations set inactivity timeouts in the 10 to 15 minute range, with shorter timeouts often used for higher-privilege access.
What evidence supports compliance with session timeout requirements?
Typical evidence includes documented timeout values in policies and the SSP, plus system configuration settings or screenshots showing the timeout applied.