AC.L2-3.1.10 Session lock: requirements and evidence

What session lock requires and why assessors check it

AC.L2-3.1.10 asks an organization to lock a user session after a defined period of inactivity, using a pattern-hiding display so that whatever was on screen can no longer be read or reached. It is a 1-point requirement, which makes it one of the lower-weighted items in the Level 2 score, but it is one that every CUI workstation has to meet. Picture a contractor's engineering laptop with a controlled drawing open, left on a desk in a shared office while its user walks to a meeting. Without a lock that engages on its own, anyone passing by can read the drawing or continue the session. The risk is simple, and the fix is usually simple too: an operating system or endpoint management policy that locks the screen after a set idle period and blanks the display with a neutral image instead of leaving the document visible. That ease is exactly why the requirement is often weakly evidenced. Teams set the timeout once on a few machines, never check the setting on laptops or shared kiosks, and then cannot show an assessor the configuration or the inactivity period they chose. The CMMC Assessment Guide leaves the minimum settings to the organization and gives five minutes of idle time as an example, so the decision and its justification belong to you. Confirm the value against your system security plan and your own risk tolerance, not against the example alone. CMMC Level 2 uses the same requirements as NIST SP 800-171 Rev. 2, so the expectation for this control is the same one your organization already carries for DFARS 252.204-7012. The Department of War suspended CMMC Phase II on 13 July 2026, which removed the scheduled C3PAO certification step for applicable contracts. Phase I self-assessments, SPRS postings and affirmations still apply, so your score for 3.1.10 still has to be accurate and supported. Confirm the current status with the contracting officer and the DoW CIO About CMMC page before you plan any certification work.

Which systems, devices and teams fall under session lock

Session lock applies wherever a person can reach CUI through an interactive session, so scoping starts with the asset inventory, not the policy document. The decisions below determine which endpoints, consoles and remote paths need configuration evidence and which ones need a documented reason for falling outside the boundary.

Workstations and laptops

Standard desktops and laptops that open CUI are the most common scope item. Each one needs the inactivity timeout and pattern-hiding display enforced, usually through directory policy or endpoint management, so a single exception can fail the requirement. Check that the setting applies to the device and not only to a user profile, and that users cannot override it locally. Confirm which operating system builds are in the boundary before you collect settings.

Servers with interactive sessions

Servers are in scope when administrators log on at the console or through a desktop session that displays or can reach CUI. Headless servers that run only services and accept no interactive logon usually need a different argument, which assessors will want written down. Where a server does have an interactive desktop, its lock behavior must be configured and recorded separately from the workstations that administer it.

Thin clients, kiosks and shared terminals

Thin clients, kiosks and shared terminals are often configured by image or vendor firmware rather than by the standard policy, so they drift from the rest of the fleet. A shared terminal raises a specific question: when one person walks away, the next person must not see the previous session. Decide whether these devices lock, log off or both, and document the choice against the inactivity period you set.

Cloud administration consoles

A browser-based administration console for a cloud tenant that holds or reaches CUI is a session in the boundary even though no workstation stores the data. Session lock on the endpoint does not cover an idle browser tab that stays signed in, so you must confirm how the console handles inactivity, how long sessions remain valid and which setting governs them. Record the console in the system inventory with its owner.

Remote and mobile sessions

Remote desktop sessions, VPN-connected laptops and mobile devices that open CUI all need the same lock decision as on-premises equipment. A remote session may lock at the host while the client keeps displaying content, so test both ends. Mobile devices managed under a separate policy must still show an inactivity lock and a concealed display. Assessors will ask how each remote path was tested, not only how it was configured.

Third-party managed endpoints

Endpoints administered by a managed service provider, outsourced help desk or subcontractor are still part of the assessed environment if they access CUI. Contracts and service agreements should state who sets the inactivity period, who evidences it and who responds when a device falls out of policy. Obtain the provider's configuration output for the assessment rather than relying on a verbal assurance, and include the provider in your responsibility matrix.

Setting the inactivity period

The requirement leaves the inactivity period to the organization, so the value is a documented decision that must be applied consistently. The CMMC Assessment Guide gives five minutes of idle time as an example, not a mandated value. Set the period per system or per policy based on the sensitivity of the data and the physical setting, record the rationale, and make sure the exceptions list is short and approved.

How an assessor tests session lock

This table walks through the three NIST SP 800-171A objectives behind AC.L2-3.1.10, showing how an assessor tests each one, what evidence they request and where organizations most often fail. Read each row as a question the assessor will ask, then confirm your environment can answer it with final-form evidence.

Assessment objective	Test approach and evidence requested	Common findings
Objective a: the inactivity period is defined	Examine the documented inactivity period in policy, the system security plan or configuration standards. Request the configuration settings that enforce it on each system type in scope, such as operating system, application and virtual desktop policies.	No period is defined, the period differs across systems without a documented reason, or the value exists only in a draft policy.
Objective b: a session lock starts after the period and prevents access and viewing	Observe or test a lock on a representative sample of endpoints and applications. Request identification and authentication procedures showing how a locked session is reopened, plus screenshots or test records taken during the test.	The lock engages but can be bypassed by switching users or closing a window, the session is not locked at all for some application types, or no test records exist.
Objective c: previously visible information is concealed by a pattern-hiding display	Examine the display behavior during lock, including whether the screen shows a blank, generic or pattern-hiding image rather than the last open document. Request sample screenshots of the locked screen and the configuration that controls the display.	The locked screen still shows the last document, a thumbnail, or a preview of email, or the setting applies only to the desktop and not to remote or virtual sessions.
Mechanisms that implement session lock	Assessors may test the tools that enforce the lock, such as directory group policy, mobile device management profiles, endpoint agents or hypervisor settings. Request the policy objects, their assignment to the systems in scope and change records showing when they were last modified.	Policies exist but are not assigned to every device group, local overrides allow users to disable the lock, or the mechanism changed without updated documentation.
Evidence in final form	Assessors accept only evidence in final form. Request signed or approved policies, dated configuration exports and test records that match the current system state at assessment time.	Evidence is an unapproved draft, screenshots are older than the current configuration, or the records do not identify which system was tested.
Scope of systems tested	Confirm that every system that stores, processes or transmits CUI is covered, including laptops, desktops, servers used interactively, and remote sessions. Request an inventory that links each system to the lock setting applied to it.	Systems outside the inventory, such as a legacy workstation or a jump host, have no lock setting, or the inventory does not match the system security plan boundary.
Sampling and retesting	Expect the assessor to select a sample of systems and users, then repeat the lock test on several of them. Prepare a repeatable test script and keep records from each run so the result can be reproduced during the assessment.	A single successful test is treated as representative, or the lock fails on a sampled device that was not tested internally before the assessment.

How to implement session lock and choose the inactivity period

This sequence turns AC.L2-3.1.10 from a policy statement into a configured, tested and documented control, so that an assessor can see a defined inactivity period, a working lock and a concealing display on every in-scope endpoint.

Define the inactivity period in a written standard
Decide the idle time after which a session locks for each class of system that handles CUI, and write it into an access control or endpoint security standard approved by the system owner. The CMMC Assessment Guide for Level 2 leaves the minimum setting to the organization and uses an automatic lock after five minutes of idle time as an example, so the period you choose must be justified against your own risk, physical environment and user population. Ask the approving authority to record the reasoning. The output is a signed standard that names the period, the systems it covers and the review date.
Weigh the trade-off before fixing the value
A shorter period reduces exposure when a workstation is left in a shared office, a lobby, a production floor or a site with visitors, but it interrupts work and can push users to disable locks or install workarounds such as mouse jigglers. A longer period suits controlled offices with few passersby but leaves CUI visible for longer. Test the proposed value with a small group of representative users and note the interruptions they report. The output is a short decision record that shows the options considered and why the chosen period fits the risk.
Enforce the setting through directory or OS policy
Apply the approved period centrally, using a group policy, mobile device management profile or configuration management baseline, rather than relying on each user to set a screen saver. Confirm that the setting cannot be changed by standard users and that new devices inherit it when they join the environment. Where an endpoint runs a Linux desktop or a server with a console, configure the equivalent screen lock timeout and record the file or policy that holds it. The output is an exported policy object or configuration file for each platform, with the owner and change history.
Confirm the pattern-hiding display on each platform
Session lock must conceal what was on screen, so check on every operating system and device type that the lock screen replaces the desktop and open applications with a display that hides them, and that the session cannot be resumed without authentication. Test this by leaving a sensitive document open, triggering the lock and checking that the content is not visible on the lock screen, in task switching previews or in notifications. Record the result per platform, including any version where behavior differs. The output is a short test log with screenshots or notes for each platform tested.
Test a sample of endpoints against the setting
Select a sample across departments, operating systems and device types, and verify that the effective setting matches the standard. Pull the applied policy from each sampled device and confirm it shows the defined period, then trigger a real idle lock and check that re-entry requires authentication. Sampling is appropriate, but include every platform class and any device that was a recent exception. Use an endpoint management or configuration assessment tool if you have one, such as a Wazuh Security Configuration Assessment policy or a Fleet policy written as a yes or no query, to show which devices pass or fail. The output is a sample report listing device, setting found, result and tester.
Document exceptions with compensating controls
Some devices, such as kiosks, lab instruments, shop-floor terminals or specialized test equipment, may not support the standard lock behavior. For each one, record the device, the reason it cannot comply, the owner, the physical or logical controls that reduce exposure, and an approval date and review interval. Confirm that the exception is recorded in the system security plan rather than held informally by the help desk. The output is an exception register that an assessor can read alongside the standard and the sample results.
Record outputs and keep them current
Gather the standard, the trade-off record, the policy exports, the platform test log, the sample report and the exception register into one evidence folder for AC.L2-3.1.10, with the date and owner of each item. Rerun the sample after major operating system upgrades, policy changes or new device types, and file each rerun with the same structure. Ask your assessor, or the C3PAO if you engage one, which artifacts they expect in final form, because the assessment uses evidence in final form rather than drafts. The output is a dated evidence package that matches the requirement's three assessment objectives.

Evidence that satisfies session lock

An assessor testing AC.L2-3.1.10 looks for three things: a defined inactivity period, a configuration that enforces it, and proof that the screen hides prior content. The cards below cover the artifacts that show each of these, and how to keep them current between assessments.

Written inactivity period and approval

The first artifact is a written statement of the inactivity period the organization chose, such as a standard or system security plan section, with the approval record that shows an accountable owner signed off on it. The CMMC Assessment Guide leaves the minimum to the organization and uses an automatic lock after five minutes of idle time as an example, so the document should justify the value against the system's risk. Confirm the approved version is final, dated and matched to the system security plan.

Exported OS and MDM configuration

Assessors want the setting itself, not a description of it. Export the Group Policy, MDM profile or operating system configuration that sets the idle timeout and the screen lock, and show that it applies to the in-scope endpoints. Look for the inactivity value, the lock behavior and the scope of assignment, and confirm that users cannot override it locally. Exports should name the policy object and its last modified date.

Pattern-hiding display test records

Assessment objective 3 requires that previously visible information is concealed by a pattern-hiding display once the session locks. Record a test on a representative endpoint: let the session idle, show the lock screen, and capture a screenshot or short recording confirming that no document, record or application content remains visible. Note the tester, date, system and build, and repeat the test after any change to the display or lock settings.

Unlock identification and authentication procedures

A lock only protects data if returning to the session requires the user to authenticate. Document the identification and authentication procedure used to unlock, including whether a password, smart card or other factor is required and how it ties to the IA controls. Assessors compare this procedure with the observed lock screen during testing, so a procedure that promises a credential prompt must match what the screen actually requests.

Sample endpoint compliance results

Continuous compliance output shows that the setting holds across the fleet, not only on the machine used for testing. Use a configuration assessment tool or a policy query on endpoints to report whether the inactivity and lock settings are present, then retain sample results with the device names, dates and any failures. Fleet's policies page, which shows which devices pass or fail each yes or no policy, can serve as one source, but confirm that the policy definition itself is exported and dated.

Keeping evidence current between assessments

Evidence must be in final form, and a draft or outdated export does not satisfy an assessor. Schedule periodic configuration exports, file a change record for each change to the timeout or lock settings, and maintain an exception register for any endpoint that cannot meet the standard, with an approved reason and owner. Confirm the schedule and retention period with your assessor, since the rule does not set a single cadence for these exports.

What meeting session lock costs in money and effort

This table breaks the cost of session lock for AC.L2-3.1.10 into components, showing who is paid, whether each item is one-time or recurring, and what pushes it up or down. Read it to decide what to budget internally and what to put in a fixed-scope quote. No price is given here, because costs depend on the endpoints and policies in scope.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Endpoint management tooling	Usually already owned by the organization; the cost is configuration time, not a new license	Often none added; confirm with the current vendor	Whether existing tools can enforce a lock policy on every in-scope device
Policy engineering and testing	Internal IT or an implementation partner	One-time, plus retesting after OS or tool changes	Number of operating systems, device types and enrollment methods in scope
Defining the inactivity period and exceptions	Security and compliance staff, with input from system owners	One-time, then reviewed on a set cycle	Number of exception requests and how many CUI systems need different settings
Documentation and configuration evidence	Internal staff or a documentation partner	One-time build, recurring refresh	How well the policy is written down and tied to the system security plan
Evidence upkeep	Internal operations staff	Recurring	Frequency of exports, reports and change records assessors will sample
Exception handling and drift checks	Internal IT and security operations	Recurring	Heterogeneous endpoints, many exceptions and no central management all increase this
External review or assessor time	Independent assessor or certification body, paid directly by the organization	Per assessment cycle	Scope size, evidence quality and the number of findings to resolve

Open-source tools that check session lock configuration

Session lock evidence is usually a configuration setting on each endpoint, so the question is whether something checks that setting continuously instead of once a year. The two tools below can each record whether lock settings are in place across a fleet, but they answer different questions and neither one tests the screen itself.

Wazuh configuration assessment policies

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation for each failed check. The policies read files, directories, registry keys and running processes, so a lock timeout stored in an OS setting can be checked. The stock policies will not know your inactivity period, so a custom check is needed to test the value your organization set in its 3.1.10 definition. Confirm that the lock setting on each operating system you run can be read by a policy in your environment.

Custom YAML policy for the inactivity period

Illustrative example: if the organization defines a five-minute idle period, a custom policy would check that the lock timeout on each endpoint matches that value and report any device where it does not. The CMMC Assessment Guide uses five minutes only as an example, so the value must come from your own documented decision. Write the check so that it fails on a missing setting as well as a wrong one, because a missing timeout is the more common gap.

Fleet policies as yes or no queries

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries. A policy that asks whether the screen lock timeout is set to the approved value returns a pass for devices that answer yes and a fail for those that answer no. The policies page then shows, for each fleet, which devices are passing or failing, which gives you a list to remediate and a dated record for an assessor. Confirm that osquery can read the lock setting on each operating system in scope.

Mixing scan and query results

Wazuh checks against a benchmark-style policy and Fleet checks through live queries, so running both gives two records of the same setting from different collection paths. This is useful when one tool cannot read a particular platform. The risk is that the two disagree and nobody decides which one is correct. Document which tool is the system of record for each device group and how a conflict is resolved.

What these tools cannot prove

Neither tool verifies pattern-hiding behavior. A passing check shows that a timeout value is configured, not that the display conceals what was on screen when the lock engaged. Assessors look for that behavior separately, so plan a manual test on a sample of each device type and keep the result with the configuration evidence. Treat the tools as proof of configuration only.

Who owns session lock, who can help, and where the auditor stops

Your organization owns AC.L2-3.1.10. That starts with defining the inactivity period, which is the first of the three assessment objectives in NIST SP 800-171A. The CMMC Assessment Guide leaves the minimum setting to the organization and uses an automatic lock after five minutes of idle time only as an example, so the number must come from your own risk analysis and the sensitivity of the CUI on each system.

Defined period: Record the inactivity period per system class, such as workstations, shared terminals and privileged administration consoles, and approve it in writing.
Policy and exceptions: Document which systems are exempt, why, and who approved the exception and when it expires.
Operating procedure: Describe how users are told the lock applies and how they re-authenticate.
Evidence ownership: Keep final-form configuration exports, policy documents and approvals under change control, not drafts.
Risk decision: Decide whether a temporary gap is acceptable and, where the rules allow, record it through the plan of action process.

Before an assessment, confirm that the person who signed the period can explain why it fits your environment.

Where session lock assessments usually fail

Session lock looks simple, so it is often checked last and documented least. Assessors tend to find the same few gaps: no defined inactivity period, locks that fail to hide what was on screen, devices outside the policy, unapproved exceptions, and evidence that is not final. Each gap below is one place where a working setting can still fail the test for AC.L2-3.1.10.

No written inactivity period

The first objective of AC.L2-3.1.10 requires the organization to define the period of inactivity before the lock starts. Many organizations rely on a default that nobody chose, such as an operating system setting from a fresh image. The fix is a written value in the system security plan or an access standard, with a stated reason for it. The CMMC Assessment Guide leaves the number to the organization and uses five minutes of idle time as an example, so confirm your own value against your risk profile and the CUI in scope.

Lock that does not hide the screen

A session can lock correctly and still fail if the previous screen stays visible behind the password prompt, or if a preview of open files remains on the lock screen. The second objective of 3.1.10 covers the lock itself, and the third covers a pattern-hiding display that conceals earlier content. Test this by leaving a CUI document open, letting the timer run, and photographing the lock screen. Keep the captured result as evidence.

Unmanaged and personal devices

A policy that sets a lock timer means little on a laptop that no management tool can see. Assessors ask which devices hold or access CUI, then check that each one receives the setting. Personal phones and home computers used for work are a frequent gap. Confirm that every in-scope device appears in your inventory, that policy is pushed to it, and that devices failing the setting are visible to administrators.

Exceptions without approval

Some systems, such as kiosks, lab equipment or shared workstations, cannot easily run a standard lock. Teams often disable the setting informally and never record it. An assessor who finds a device with no lock and no exception record will treat the requirement as not met. Each exception needs a documented business reason, a named approver, compensating controls such as physical restriction, and a review date. Keep the approval with the system security plan.

Draft or undated evidence

Assessors accept evidence only in final form. A policy marked draft, a screenshot without a date or hostname, or a configuration export from a test machine will not establish that production systems were configured as described. Capture the setting from the systems in scope, record the date and the device name, and store the policy version that was in force. Where a tool reports status across endpoints, export the report at the assessment date so it can be matched to the systems it covers.

Session lock questions buyers ask before hiring help

How much effort does session lock for AC.L2-3.1.10 usually take?

The effort depends mostly on how many endpoint types and identity systems the lock setting must cover, not on the requirement itself. A single managed fleet with one directory and one desktop image is a small configuration task. Mixed estates with Windows, macOS, Linux servers, kiosks and shared workstations take longer because each platform needs its own verified setting. Effort also grows with the number of times the setting must be re-proven: a configuration baseline, a sample of devices, and the logs or reports that show the lock works after an idle period. Ask any partner to break its quote into discovery, configuration, testing and evidence packaging so you can see where the hours go.

Can we set up session lock for AC.L2-3.1.10 in-house?

Yes, most organizations with an existing endpoint management tool and an IT team can configure the inactivity period and the pattern-hiding display themselves. The harder part is evidence. Your team must define the inactivity period in a documented policy, apply it consistently through group policy, MDM or equivalent, and show that the setting is enforced on every in-scope device. Internal teams often underestimate the drift problem: new images, new laptops and exceptions for specific roles can quietly break the baseline. If your staff already run configuration management and can produce a dated, final-form record, the in-house route is realistic. If not, an implementation partner can build the policy, baseline and checks while you keep control of the decisions.

How long does session lock setup typically take?

The setup duration depends on the number of endpoints in scope, how many operating system types must be configured, how many identity and management systems enforce the setting, and whether the environment is already managed centrally. A small, uniformly managed fleet can be configured quickly, while a distributed estate with legacy systems or specialized assets needs more discovery and testing. Ask for a written schedule that ties each phase to a named deliverable, and confirm whether the timeline includes time for evidence collection, which often runs in parallel with the final configuration checks.

What does the work need from our team for session lock?

Three client inputs usually decide whether the work moves smoothly. First, a named policy owner who can approve the inactivity period and the exceptions, such as kiosks or systems where a lock would interfere with safety or operations. Second, administrative access to the endpoint management, directory and logging platforms, plus a sample of representative devices for testing. Third, formal approvals: change tickets for configuration changes, sign-off on the policy document, and agreement on how exceptions are recorded. Confirm with the partner which of these they expect you to supply and which they will prepare, and agree on who approves each change before work begins.

Does session lock affect the 1-point score or POA&M eligibility?

AC.L2-3.1.10 is worth 1 point under 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21, so it may be placed on a plan of action and milestones if the overall score is at least 88 of 110 (0.8), with closeout due within 180 days. A single point is small, but an unmet requirement still counts against your score and must be tracked. Whether a POA&M is a sound choice depends on your contract status and the program's current requirements. Check the present rule text and any current DoD guidance, since the CMMC phase schedule has changed recently, before deciding how to handle this requirement.

Can a partner sign the session lock assessment for us?

No. A partner can prepare your configurations, policies, test records and evidence, but only an independent assessor can assess the requirement and issue a result. For Level 2 certification, that assessor is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are performed and affirmed by your organization. Be wary of any proposal that promises a passing outcome or offers to certify the control itself. A useful partner will make your evidence easy for the assessor to test independently.

How DeployOpen prepares session lock evidence

DeployOpen works on AC.L2-3.1.10 Session lock as a fixed-scope implementation project inside your own environment. We set up the inactivity lock, the pattern-hiding display and the configuration records, then hand over evidence that your organization and an independent assessor can review.

How we scope

The written scope names the systems, endpoints and operating platforms where session lock must apply.
We agree with you in writing who defines the inactivity period and how that decision is recorded.
Engagements are fixed-scope, and ongoing support can be added as a retainer once the scope is settled.

How we build

We configure automatic session lock with a pattern-hiding display on the in-scope endpoints and servers.
We align lock settings with the inactivity period your organization defines, rather than a value we choose for you.
We test that the lock engages after idle time and that previously visible content is concealed on screen.

How we hand over

We deliver configuration exports, policy files and screenshots showing each setting in effect on in-scope assets.
We document the test steps and results so an assessor can repeat the check on the same systems.
We hand over procedures for changing the inactivity period, including how changes are approved and logged.

How we support

We can monitor lock configuration drift with open-source tooling such as Wazuh or Fleet, if those tools fit your environment.
We can re-test session lock after system upgrades, new images or changes to the inactivity period.
Certification or assessment decisions remain with your organization and the independent assessor, not with DeployOpen.