Access Control 3.1.10 (3.1.10)
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity
Get Full GuidanceWhat Is This CMMC Control?
This control requires systems to automatically lock after a period of inactivity and hide what was on the screen to prevent unauthorized viewing of CUI. The lock must activate when users step away temporarily without logging out completely. The screen must show something generic (like a blank screen or screensaver) that doesn't reveal any sensitive information.
Control Intent
Prevent unauthorized access to and viewing of CUI when authorized users temporarily leave their workstations unattended without fully logging out of the system.
Who This Control Applies To
- •Workstations (desktops and laptops) that access, process, or store CUI
- •Servers with interactive console access where CUI is displayed
- •Virtual desktop infrastructure (VDI) sessions accessing CUI
- •Mobile devices (tablets, smartphones) used to access CUI
- •Thin clients and zero clients accessing CUI systems
- •Kiosks or shared workstations in CUI environments
- •Jump boxes and privileged access workstations
- •Remote desktop sessions to CUI systems
Not Applicable When
- •Systems have no interactive user interface or display (headless servers, network devices)
- •Systems are physically secured in locked rooms with no CUI displayed on screens
- •Automated systems with no human interaction or session concept
- •Systems that only transmit or store CUI but never display it to users
- •Embedded systems or IoT devices without user sessions
- •Systems where users are required to fully log out rather than lock (though this is less secure)
Key Objectives
- 1Automatically lock user sessions after a defined period of inactivity to prevent unauthorized access
- 2Hide displayed information during session lock to prevent visual compromise of CUI
- 3Ensure locked sessions require re-authentication before resuming access to CUI
Sample Self-Assessment Questions (Partial)
Does your organization have a defined inactivity timeout period for workstations and devices that access CUI?
What is the maximum inactivity period before screens automatically lock?
Implementation Approaches (High-Level)
Windows Group Policy Session Lock
Centralized enforcement of session lock through Active Directory Group Policy Objects applied to all Windows workstations and servers with interactive access to CUI.
macOS Configuration Profile Session Lock
Centralized enforcement of session lock through MDM-deployed configuration profiles for macOS devices accessing CUI.
Linux/Unix Screen Lock Utilities
Per-system or centrally managed configuration of screen lock utilities (xscreensaver, gnome-screensaver, xlock) on Linux/Unix workstations accessing CUI.
Mobile Device Management (MDM) for Mobile Devices
Centralized enforcement of automatic lock and pattern-hiding through MDM policies for iOS and Android devices accessing CUI.
Virtual Desktop Infrastructure (VDI) Session Timeout
Session lock enforcement at the VDI platform level for virtual desktop sessions accessing CUI, independent of endpoint device configuration.
Application-Level Session Timeout (Compensating Control)
Session timeout and lock implemented within specific applications when OS-level session lock cannot be enforced, used as a compensating control for limited scenarios.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If session lock cannot be immediately implemented on all systems, prioritize systems with highest CUI exposure or physical access risk For legacy systems that cannot support session lock, document compensating controls such as physical security, application-level timeouts, or restricted access If timeout period is currently too long, create a phased approach to reduce it incrementally to minimize user disruption If pattern-hiding displays are not configured, this is typically a quick fix and should be remediated rapidly For mobile devices without MDM, consider requiring MDM enrollment or prohibiting CUI access from unmanaged devices If users have local admin rights preventing enforcement, address privileged access management as a prerequisite For systems where session lock is technically infeasible, consider whether those systems should access CUI at all Include user training and communication in POA&M to address resistance to session lock policies If monitoring/compliance checking is not in place, include implementation of compliance monitoring tools For VDI environments, ensure both VDI platform and virtual desktop OS are addressed in POA&M
Frequently Asked Questions
What is an appropriate inactivity timeout period for session lock?
NIST and CMMC do not specify an exact timeout, but 15 minutes or less is commonly accepted and aligns with industry best practices. Organizations should balance security needs with operational requirements. Higher-risk environments or privileged accounts may warrant shorter timeouts (5-10 minutes). The key is to document your chosen timeout and ensure it is consistently enforced.
Is session lock required on servers, or just workstations?
Session lock is required on any system with an interactive user interface where CUI is displayed, including servers with GUI consoles. However, headless servers (no monitor, no GUI) or servers accessed only via command-line SSH typically do not require session lock at the OS level, though SSH session timeouts are still recommended. If administrators use remote desktop or console access to servers displaying CUI, session lock must be configured.
Can we use application-level session timeout instead of OS-level session lock?
OS-level session lock is strongly preferred because it protects all applications and data on the system. Application-level timeout should only be used as a compensating control when OS-level lock is not technically feasible (e.g., legacy systems, specialized kiosks). If using application-level timeout, you must document why OS-level lock cannot be implemented and ensure the application timeout meets the same objectives (automatic lock, pattern-hiding, re-authentication required).
What should be displayed on a locked screen to meet the pattern-hiding requirement?
The locked screen should display something that does not reveal any CUI or sensitive information. Acceptable options include a blank screen, solid color, generic screensaver (e.g., blank or abstract patterns), or a login prompt. Do NOT display usernames, computer names, recent documents, window previews, notification content, or any other information that could aid an attacker or reveal CUI. The Windows lock screen showing username is generally acceptable, but avoid showing full names or other identifying details if possible.
Do mobile devices like smartphones and tablets need session lock?
Yes, if mobile devices are used to access, process, or store CUI, they must have automatic lock enabled with an appropriate timeout period (typically 15 minutes or less). This is usually enforced through Mobile Device Management (MDM). The device should require a passcode, PIN, or biometric authentication to unlock. Lock screen notifications should be configured to not display CUI content.
How is session lock different from logging out or session termination (3.1.11)?
Session lock is a temporary action for short absences (e.g., stepping away from desk for a meeting). The user's session remains active but is protected by a lock screen requiring re-authentication. Session termination (3.1.11) is a permanent action that ends the session after a longer period of inactivity or at the end of the workday. Users must fully log back in after termination. Session lock is not a substitute for logging out at the end of the day.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.