03.01.10 Device lock: requirements and evidence

What NIST SP 800-171 device lock requires and why assessors look for it

If you need evidence for 03.01.10 before an assessment, start with the core obligation: the system must prevent access to a device through a device lock that starts after a defined period of inactivity or when the user locks it before leaving the system unattended. The lock must stay in place until the user re-establishes access through identification and authentication, and any information that was on screen must be concealed behind a publicly viewable image. The risk this addresses is simple and common: a CUI-bearing screen left visible in a corridor, a shared office or a kiosk lobby. Assessors ask for proof that the setting exists, that it is enforced on each device type, and that users know to lock manually.

Two organization-defined parameters (ODPs) decide what the requirement looks like in your environment. The first selects how the lock starts: after inactivity, by user action, or both. The second sets the inactivity period, if the inactivity option is chosen. NIST does not assign these values, so your organization must set them and document the choice in the system security plan. Confirm with your assessor whether they expect a specific value or only a documented rationale, because that changes what you need to retain. The requirement is hard to prove on mixed fleets because laptops, workstations and shared kiosks often receive lock settings through different mechanisms, and a single policy document does not show that each device actually enforces them.

NIST lists AC-11 and AC-11(1) from SP 800-53 Rev. 5 as the source controls for this requirement. Rev. 2 to Rev. 3 change analysis traces the requirement to Rev. 2 requirement 3.1.10 and classifies the change as minor, so existing Rev. 2 device lock evidence generally carries over. The CMMC Level 2 practice, AC.L2-3.1.10, still uses the Rev. 2 wording and is worth 1 point in the scoring methodology. Pull the NIST change analysis spreadsheet to confirm the mapping for your own documentation, and check whether your contract currently references Rev. 2 or Rev. 3 before you collect evidence.

Which devices, accounts and teams fall under the device lock requirement

Device lock scope follows the CUI boundary, not the whole fleet. The decisions below determine which endpoints, shared machines, virtual sessions and mobile devices must enforce the lock, and who must own the settings that prove it.

Endpoints that store or access CUI

Any workstation, laptop or thin client that stores, processes or displays CUI is in scope for 03.01.10 Device lock. Start from the system security plan's boundary diagram and the list of users who open CUI repositories, then match that list against device inventory. Check that each in-scope device has the lock configured, not just the user group that normally uses it. A device that a CUI user can reach but that sits outside the documented boundary is a scoping question to resolve with the system owner before the assessment, not after.

Shared and kiosk workstations

Shared workstations, such as those at a nurse station, lab bench or contractor pool, are where a lock is most often skipped because several people sign in to one machine. Each shared device still needs the lock, and the trigger must work for whoever is logged in at that moment. Confirm that a lock applied to one shared session does not leave the next user's session unprotected, and document how the inactivity period applies to shared use.

Servers and virtual desktops with interactive sessions

Servers and virtual desktop sessions count when an administrator or user can view CUI through an interactive console. Headless servers that only run services usually have no screen to conceal, so the assessor will focus on administrative consoles and remote desktop sessions. Check the hypervisor, VDI broker and jump host settings, because a lock on the client device does not always lock the remote session behind it.

Mobile devices used with CUI

Phones and tablets that receive email, chat or files containing CUI fall under the lock requirement when they connect to the system. Mobile device management policies can enforce a passcode and idle lock, but the organization must confirm which settings apply to managed and unmanaged devices. Document whether personal devices are allowed at all, since an unmanaged device generally cannot be shown to meet the lock setting.

Two ODPs that belong in the system security plan

The lock trigger, either an inactivity period, a user action before leaving the system, or both, and the inactivity period itself are organization-defined parameters. NIST does not set their values, so the organization must choose and record them. Write both values in the system security plan and tie them to the access control policy, so an assessor can compare the documented setting with the configured one on each device.

Who owns the lock configuration

Three roles usually share this control. The system owner sets the parameter values and accepts the risk, IT or endpoint engineering builds and deploys the configuration through group policy, MDM or configuration management, and the security team reviews evidence that the setting is in place. Name the owner of each step in the plan. Ask a managed service provider or implementation partner to show which of these roles it covers and which remain with your staff.

How an assessor tests device lock under SP 800-171A Rev. 3

This table maps each part of the 03.01.10 assessment to the method, the objects an assessor examines, interviews or tests, and the evidence to prepare. Read it as a checklist for the assessment, then use the common findings column to find the gaps most likely to appear before the assessor arrives.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Determination statement 1: lock start trigger	The system starts a device lock after the defined inactivity period or when the user initiates it before leaving the system unattended	Session lock configuration settings, screenshots of the lock settings, and a test log showing a lock occurring at the configured trigger	Lock configured for inactivity only when the organization selected both triggers
Determination statement 2: lock persistence	The lock stays in place until the user re-establishes access through identification and authentication	Test record showing the screen stays locked until valid credentials are entered, including after a failed attempt	Lock dismissed by a keypress or timeout without re-authentication
Determination statement 3: information concealment	Previously visible content is hidden behind a publicly viewable image when the lock is active	Screen capture of the locked display, the configured lock image, and the configuration key that sets it	Lock screen shows open application windows or notifications behind a thin overlay
ODP check: trigger method	The organization defined how the lock starts: inactivity, user-initiated, or both	Written access control procedure or system security plan entry that names the selected trigger	Trigger method never documented, so the assessor cannot tell which option applies
ODP check: inactivity period	If inactivity is selected, a specific inactivity period is defined and applied	Configured period in the policy and in the system configuration, with matching values	Policy states one period while the endpoint or domain policy enforces another
Examine method	Access control policy, session lock procedures, system design documentation and system configuration settings, plus the display with session lock active	Current policy, procedure, design document, exported configuration, and labeled screenshots dated for the assessment	Procedures describe lock behavior that the configuration does not enforce
Interview method	Personnel with information security responsibilities, system developers and system administrators explain how the lock works and is maintained	Named owners for the lock settings, short notes on how changes are approved, and staff who can demonstrate the lock	Administrators cannot explain which setting controls the lock or where it is enforced
Test method	Session lock mechanisms work as documented across the systems in scope	Test scripts or steps, timestamped results for each endpoint type, and remediation records for failed tests	Tests run on a single test device, leaving managed laptops, servers or mobile devices untested

How to implement device lock in a sequence that produces evidence

This sequence sets the two organization-defined parameters first, then configures, verifies and documents device lock so that an assessor can trace each part of 03.01.10 to a setting, a test result and an owner. Each step closes with an artifact the assessor can examine.

Set and document the two ODP values
Decide how the device lock starts, choosing after a set period of inactivity, by the user before leaving the system unattended, or both. If an inactivity period applies, set its length. Record both values in the system security plan with the rationale and the approving owner, because 03.01.10 cannot be completed until these parameters are defined. Confirm with the federal agency or contracting officer whether it has already specified values, since NIST does not assign them and the nonfederal organization must assign them if no one else does. Output: a signed SSP entry that names both parameter values and their approver.
Map the in-scope device types
List every device type that processes, stores or transmits CUI or connects to the system, including workstations, laptops, servers with interactive consoles, mobile devices and any kiosks or shared terminals. Note the operating system and how each device is managed. Keep this inventory aligned with the component inventory used for 03.04 so the assessor can match devices to settings. Output: a device-type inventory that lists each type, its platform and its management method.
Configure the lock policy on each device type
Using the endpoint management tool or the operating system policy mechanism your organization already runs, apply the inactivity or user-initiated lock to every in-scope device type with the ODP values from step one. Export or capture the configuration settings for each platform. Open-source endpoint tools such as Fleet can help confirm which devices have the policy applied, since Fleet policies are yes or no osquery checks that report which devices pass or fail. Confirm the setting is enforced, not only available to users. Output: exported configuration settings per device type.
Confirm the lock holds until re-authentication
Verify that once the lock starts, the session stays locked until the user reestablishes access through identification and authentication. Test that the lock cannot be dismissed without credentials and that the authentication method matches the requirements for 03.05. Record the test steps, the account used and the result for each device type. Output: a dated test record showing the lock persists and requires identification and authentication.
Configure the publicly viewable concealment image
Set a publicly viewable image, such as a neutral screen or organizational banner containing no CUI, to display when the device locks, so that previously visible content is hidden. Confirm that the image replaces the desktop, open documents and application windows, and that it appears on every device type in the inventory. Save a screenshot of the locked screen for each platform as evidence that the concealment image is active. Output: locked-screen captures per device type and the image file or setting used.
Test the lock on a sample of each device type
Select a sample of devices from each device type, including at least one device under each management method, and run a test for both trigger conditions. Wait for the inactivity period, then trigger a manual lock, and check the result against the ODP values and the concealment image. Record device identifiers, dates, the tester and the outcome. Tests of this kind mirror the test method that SP 800-171A Rev. 3 uses for 03.01.10. Output: a test log with pass or fail results per sampled device.
Document exceptions with owners and dates
For any device that cannot meet the lock configuration, such as a legacy system, a kiosk or a device that cannot run the management agent, record the device, the reason, the compensating measure, the accountable owner and the date the exception was reviewed or will be retired. Store the exception record with the SSP and the test log so the assessor can see that gaps are known and governed. Output: an exception register that links each device to an owner, a compensating measure and a review date.

Which evidence shows device lock is working and stays current

An assessor testing 03.01.10 looks for a written rule, a configured setting, a defined parameter value, and proof that the lock behaves as the rule says. Each artifact below answers one of those questions, and each goes stale unless it is re-exported or re-tested after configuration changes.

Access control policy and session lock procedures

The written policy and procedures should state that devices lock after inactivity or on user command, that the lock holds until the user re-authenticates, and that previously visible content is hidden behind a publicly viewable image. Assessors examine these documents first, so the session lock section should name the roles that own it. Check that the section matches the settings actually deployed, not the settings planned at the time of drafting. Record the review date and approver so the document shows it is maintained.

Lock setting exports by device group

Export the effective lock configuration from each device group, such as managed workstations, laptops, kiosks and servers with consoles, rather than relying on a single template. Confirm the inactivity timeout, the lock-on-command behavior and the image setting appear in each export. Schedule re-exports on a fixed cadence and after every change to a group policy or image. Store the exports with timestamps so an assessor can compare them with the change records.

Documented ODP values for device lock

Device lock has two organization-defined parameters: how the lock starts (after inactivity, by the user before leaving the system, or both) and, where inactivity applies, the inactivity period. Record the values you chose, the reason for them, and the approver, because NIST does not set them and the organization must assign them. Two determination statements check that these values are defined, so a blank or ambiguous value fails even if the lock works. Update the record whenever a value changes and tie the change to a ticket.

Test records for lock triggers

Keep dated test records showing that the lock starts after the defined inactivity period and when a user locks the device manually, and that the lock holds until identification and authentication succeeds. Test on a sample from each device group and include the tester, the device, and the result. Repeat the tests after operating system updates, policy changes or new device images, since those are the events most likely to alter lock behavior. Failed tests should carry a remediation ticket and a retest result.

Lock screen captures with the public image

Capture the lock screen on each device type to show that the publicly viewable image replaces previously visible content. The image itself should contain no CUI, system names or internal network details. Note which image file is in use and where it is stored, then recapture when the image or the lock configuration changes. Ask the assessor early whether they expect a capture per device group, since that choice determines how many captures you need to keep current.

Recurring compliance scan results

A configuration assessment tool can check lock settings continuously and report deviations from the expected values. Wazuh's Security Configuration Assessment checks files, registry keys and running processes against YAML policies, and custom policies can encode your own lock settings. Fleet policies are yes or no osquery questions that show which devices pass or fail each policy. Keep the scan history, review failing devices on a set cadence, and link each exception to a documented decision.

What meeting device lock costs in money and effort

This table compares the cost components of implementing and evidencing device lock under 03.01.10, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since most of the spend comes from internal and partner engineering time rather than new software licenses. No price figures are given because none are supplied for this topic.

Cost component	One-time or recurring, and who is paid	What drives it up	What drives it down
Endpoint management or OS policy configuration	Mostly recurring if licensed; often already paid through existing endpoint tools. Confirm license scope with the vendor.	Many device types, unmanaged devices, separate tools per operating system	One management platform covering all endpoints, existing licenses reused
Engineering time to set ODPs and build the baseline	One-time for initial setup, then periodic review. Paid to internal staff or a partner under a written scope.	Undefined inactivity period, unresolved choice of lock trigger, many policy exceptions	Decisions on lock trigger and inactivity period recorded early, a single standard image
Testing across device types	One-time per device type, repeated after major OS or policy changes. Internal or partner effort.	Laptops, desktops, shared kiosks, tablets and mixed operating systems	Limited set of supported device types, test scripts reused across builds
Evidence upkeep	Recurring. Internal staff keep screenshots, configuration exports and policy records current.	Manual screenshot collection, multiple systems holding settings	Exported configuration and policy results generated on a schedule
Configuration drift monitoring	Recurring. Internal staff or a managed monitoring service, plus any open-source tool hosting costs.	Devices outside management, frequent local setting changes	Continuous compliance checks that flag devices failing the lock settings
External review or testing, if purchased	One-time or periodic. Paid to an outside firm under a fixed-scope agreement.	Large estate, multiple sites, need for independent configuration testing	Scope limited to lock settings on sampled device groups
Auditor sampling time	Recurring at each assessment. Paid to the independent assessor, not to the implementation partner.	Many device groups to sample, missing evidence for a sample, unclear ODP records	Clear ODP documentation and per-device evidence readily available
Open-source tooling to reduce license spend	Mostly recurring hosting and staff time. Wazuh (GPL-2.0-only) and Fleet (MIT) are candidates; confirm fit for each device type.	Need for new hosting, agent rollout, and staff to maintain rules	Reusing existing monitoring infrastructure and agents already deployed

How Wazuh and Fleet produce device lock evidence

Device lock compliance depends on showing that each endpoint enforces the lock settings the organization chose for its ODP values. Two open-source tools can collect that configuration state, but neither one decides whether the requirement is met.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports misconfigurations with remediation advice. The built-in policies may not match the inactivity period or lock trigger the organization selected, so a custom policy is often needed to check the lock settings directly. Before relying on any check, confirm that its logic matches the ODP values written in the system security plan, and keep the policy version with the scan results.

Custom policies for lock settings

A custom Wazuh policy can check files, directories, registry keys and running processes that hold the screen lock configuration. On Windows, that means the registry values that control inactivity locking; on Linux, the desktop or session settings that enforce the timeout. Test each rule on a device set to a known state, first with a compliant value and then with a deliberately wrong one, so the record shows that the check can fail as well as pass.

Fleet policies as yes or no questions

Fleet policies are yes or no questions asked of each device through osquery, and the policies page shows which devices in each fleet pass or fail. A policy can ask whether the screen lock is enabled and whether the timeout matches the chosen ODP value, which gives a per-device answer that is easy to review. Confirm the query returns the expected result on a test device before depending on it, since a query that returns nothing can look like a pass.

Exporting results as evidence

Pass and fail results from both tools can be exported and stored with the rest of the assessment package. Record the date of each scan, the policy or query text, the device identifier and the ODP values in force at the time. An assessor will look for a repeatable record across the device population, not a single screenshot, so schedule the checks and keep each export.

What the tools cannot decide

Both tools show configuration state, not the assessor's conclusion. Neither one can confirm that the lock also hides previously visible content behind a publicly viewable image unless the check is written for that setting, and neither can judge whether the chosen inactivity period is appropriate. The organization owns that decision, and an independent assessor reaches the finding after reviewing the policy, the ODP choices and the test results together.

Who owns device lock: your team, an implementation partner, and the auditor

Your organization owns 03.01.10 Device lock. The requirement has two organization-defined parameters: how the device lock starts (after a period of inactivity, by the user before leaving the system unattended, or both) and, if inactivity is selected, the inactivity period. NIST does not assign these values, and if the contracting federal agency has not specified them, you must set them. Those choices belong to people who understand the CUI, the users and the operating environment.

ODP decisions: Choose the lock trigger and the inactivity period, record the rationale, and approve any difference between device types.
Policy and procedures: Keep the access control policy and the session lock procedure current, and make sure they match the system security plan.
Exception sign-off: Decide which devices, kiosks or shared systems may depart from the standard, and who accepts that risk in writing.
Operational ownership: Assign who responds when a lock setting fails monitoring and who reviews the results.
Interviews: Be ready for the assessor to interview personnel with information security responsibilities, system administrators and system developers about how the lock works.

Confirm that the people who sign these decisions are named in the system security plan before an assessor arrives.

Where device lock programs usually fall short and how to close the gap

Device lock looks simple on paper, which is why it often fails quietly. The gaps below share one root cause: the setting exists, but nobody can show which devices it covers, which values were chosen, or that it still works after a change.

ODP values never documented

03.01.10 has two organization-defined parameters: how the lock starts (after inactivity, by user command, or both) and the inactivity period if the first option applies. NIST does not assign these values for you. Many programs set a timeout in a group policy and never record the choice in the system security plan, so an assessor cannot confirm the parameters are defined. Write down both values, the reason for them, and who approved them.

Lock applied to some device types only

Laptops joined to the directory often inherit the lock policy, while macOS hosts, Linux workstations, thin clients and personal devices used for CUI may not. Check every device type that can reach a system with CUI, not only the corporate image. Use an endpoint inventory as the denominator, then compare it against devices where the lock setting is actually enforced.

Lock clears without re-authentication

Some screen savers or session managers let anyone press a key and return to the desktop with the session still open. The requirement calls for the lock to hold until the user re-establishes access through identification and authentication. Test the behavior after a lock, including after a sleep or resume, and confirm the password or authenticator prompt appears every time.

No evidence of lock testing

A setting in a configuration file does not prove the lock works on each device. The 800-171A procedure includes test activities against the session lock mechanism and examination of a display with the lock active. Keep dated screenshots or test records for a sample of device types, and rerun the test after OS upgrades. Ask the assessor which sample size they expect before testing starts.

Shared kiosks and lab machines unmanaged

Shared workstations, lab machines and conference room displays often sit outside the standard build and have no inactivity lock, or they rely on a shared login that never locks. Put each one in the asset inventory, assign an owner, and either apply the same lock configuration or document a compensating control that the assessor agrees covers the requirement.

Policy changes not tracked

Someone shortens the timeout during a usability complaint, or an image update resets the value, and nothing records the change. Track the lock configuration in version control or your configuration management baseline, and require a change record when the inactivity period or lock trigger changes. Compliance fails quietly when the setting drifts between audits.

Questions buyers ask about device lock, cost and effort

How much effort does device lock take to implement?

Device lock itself is a configuration task, but the effort depends on how many endpoints and systems must enforce it and how many of them are already managed centrally. The requirement asks for two decisions: whether the lock starts after a defined period of inactivity, on user command, or both, and, if inactivity is used, how long that period is. Once those values are set, the work is applying them consistently across operating systems, applications and any shared kiosks or terminals, then showing that the settings took effect. Effort rises with device diversity, the number of unmanaged or legacy machines, and the number of people who must agree on the values. Ask any provider to break the effort down by device group in the written scope.

Can we implement device lock without an implementation partner?

Yes, in most environments an internal team can implement device lock, because it is a common operating system and endpoint management setting. The harder part is the evidence. An assessor will look for an access control policy and procedures that state the chosen parameter values, configuration settings that show the lock is active, a screen with the session lock in effect, and interviews with the people who run the system. Whether to outsource depends on whether your team has the time to document decisions, test each device class and keep the record current. The organization always owns the control and the decision on its values. A partner can prepare systems and evidence, but cannot issue an assessment result.

What does device lock need from our IT team?

Device lock needs people who can own the parameter decisions and people who can apply and verify them. In practice that means a named owner for the access control policy, administrators who can push settings to every endpoint class, and a security lead who can confirm the values match what the system security plan states. The 03.01.10 requirement has two organization-defined parameters, so someone must document how the lock starts and the inactivity period. Interviews in the assessment method reach personnel with information security responsibilities, system developers and system administrators, so those people should be able to explain the setting and why it was chosen. Plan for time from both administration and security roles, not only from the desktop team.

How long does it take to get device lock evidence ready?

The duration depends on fleet size, the number of device types and how many of them are centrally managed, and it must be confirmed in the written scope before work starts. A small set of managed laptops can be configured and documented quickly, while a mixed fleet with kiosks, shared terminals and older systems takes longer to inventory and test. Evidence work also has a fixed shape: documented parameter values, configuration exports, screenshots or test records showing the screen lock, and the policy and procedure text. Ask the provider to state the number of endpoint groups in scope, the evidence each group produces and the review points before the schedule is agreed.

Do existing endpoint tools already cover device lock?

Many endpoint management and operating system tools can enforce a screen lock after inactivity, so existing tools may cover part of the requirement. What you still need to confirm is whether the tool enforces both the inactivity trigger and the user-initiated lock, whether the lock stays in place until the user re-authenticates, and whether the previously visible content is hidden behind a publicly viewable image. Compliance checks can also be tested with open-source tools. For example, Wazuh (GPL-2.0-only) Security Configuration Assessment checks endpoints against YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies, which can verify the configured values. Fleet (MIT) policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices pass or fail, which helps show ongoing coverage. Confirm each tool's exact capability against your environment before relying on it.

Does DeployOpen issue a certificate or report for device lock?

No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can plan, implement and document device lock settings inside your own infrastructure, prepare the configuration evidence, and support internal staff through the assessment. The compliance result comes from an independent assessor or certification body, selected by the organization or the contracting agency as the requirement dictates. For NIST SP 800-171 work, the federal agency that holds the contract is responsible for how the requirements are applied and for any compliance issues, so confirm with that agency which assessment route applies to your contract.

What should we put in a quote request for device lock?

A useful quote request names the scope precisely so that the price follows from the work. Include the number and types of endpoints and shared devices, the operating systems and management tools in use, the parameter values you have chosen or need help choosing, the systems that hold or process CUI, and whether you need evidence packaged for an assessor. Ask for deliverables, including the documented parameter decisions, configuration records, verification steps and the handover of evidence, plus the timeline and the points where your team must provide input. Ask which costs are one-time, such as setup and documentation, and which recur, such as periodic verification or retained support. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes and prepares device lock evidence

DeployOpen plans, implements and documents device lock settings on self-hosted open-source platforms inside the client's own infrastructure. The organization owns its controls and its system security plan, while an independent assessor decides whether the requirement is met.

How we scope

Engagements are fixed-scope, with the systems, endpoints and operating systems in scope agreed in writing before work starts.
The written scope records whether the inactivity trigger, the user-initiated lock or both apply, and the inactivity period selected.
Scope also names where the lock policy is enforced, such as endpoint management, directory policy or the platform itself.

How we build

We configure lock timeouts and user-initiated lock mechanisms on the endpoints and systems named in the agreed scope.
We set the screen content concealment behavior so previously visible information is replaced by a publicly viewable image on lock.
We deploy monitoring checks, such as osquery-based policies in Fleet or Wazuh configuration assessment policies, to show which devices pass or fail.

How we hand over

We document the lock settings, the ODP values chosen and the reasons for them, so the organization can assign and defend them.
We provide configuration evidence and pass or fail reports that map to the examine and test objects in SP 800-171A Rev. 3.
We deliver a handover package for the organization's staff, with runbooks for exceptions and for re-establishing access after a lock.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which keeps lock settings verified after changes.
We can re-run the device lock checks after operating system upgrades, fleet enrollments or policy changes.
Independent auditors and certification bodies, not DeployOpen, decide whether the 03.01.10 evidence meets the requirement.