03.01.10: Device Lock

To meet the 03.01.10: device lock requirement, you must configure all in-scope endpoints to automatically lock the device (screen/session) after a defined period of inactivity and require re-authentication to regain access. Operationalize it by standardizing lock settings in MDM/GPO, covering exceptions, and keeping evidence that the settings apply to every system that can access or store CUI (NIST SP 800-171 Rev. 3).

Key takeaways:

• Enforce automatic device locking and re-authentication across all CUI-handling endpoints, including remote access scenarios (NIST SP 800-171 Rev. 3).
• Standardize settings through centralized configuration (MDM/GPO), and document any exceptions with compensating controls (NIST SP 800-171 Rev. 3).
• Keep assessor-ready artifacts: configuration baselines, device compliance reports, and test evidence tied to your SSP and POA&M (NIST SP 800-171 Rev. 3).

03.01.10: Device Lock sounds simple, but assessors fail teams on it for predictable reasons: inconsistent settings across device types, unclear scope (which endpoints are “in”), and weak evidence that the lock actually operates in production. For NIST SP 800-171 programs, “device lock” is not a policy statement. It is a technical configuration requirement you must enforce on every endpoint that can access, process, or store CUI, including laptops, desktops, mobile devices, and virtual/remote sessions where the endpoint is effectively the access path to CUI (NIST SP 800-171 Rev. 3).

A workable implementation has three parts. First, define the lock trigger and the re-authentication behavior in a standard. Second, enforce it centrally (so you can prove it) and manage exceptions intentionally. Third, retain evidence that maps directly to your System Security Plan (SSP) control statement and shows the control operating over time, not just on audit day (NIST SP 800-171 Rev. 3). This page gives you requirement-level steps you can assign to endpoint engineering and IT operations immediately, plus the artifacts a CCO/GRC lead needs for an assessment.

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.01.10 (Device Lock).” (NIST SP 800-171 Rev. 3)

Operator interpretation: Implement technical settings that automatically lock end-user devices after inactivity and prevent access to CUI until the user re-authenticates. Treat this as an endpoint configuration control with measurable, testable criteria and continuous enforcement, not a training-only or “users should lock their screen” policy (NIST SP 800-171 Rev. 3).

What an assessor expects to see: a defined lock standard, centralized enforcement (or equivalent), and objective evidence that the setting applies to the device population in scope for CUI (NIST SP 800-171 Rev. 3).

Plain-English interpretation (what the requirement means)

Device lock reduces opportunistic access when a user steps away, loses a device, or leaves a session open in a shared workspace. For compliance purposes, your job is to make “walk-up access” difficult by forcing an automatic lock and requiring the user to prove identity again before anything CUI-related can be accessed.

This requirement usually fails in two scenarios:

• Configuration drift: devices gradually deviate from the baseline (different OS versions, local admin changes, broken MDM enrollment).
• Scope gaps: VDI clients, jump hosts, shared workstations, kiosks, lab machines, or contractor laptops access CUI but don’t inherit your standard endpoint controls.

Who it applies to (entity + operational context)

Entities: Any nonfederal organization implementing NIST SP 800-171 for Controlled Unclassified Information (CUI), including defense and federal contractors and subcontractors (NIST SP 800-171 Rev. 3).

Operational scope (what systems):

• End-user compute devices that store, process, or access CUI (directly or through remote access to a CUI environment).
• Corporate-owned and BYOD devices if they are permitted to access CUI (for BYOD, you typically need containerization or managed profiles to make enforcement and evidence feasible).
• Shared devices and privileged access workstations if they can touch CUI.

Third-party angle: If third parties (MSPs, consultants, staffing firms) use their own endpoints to access your CUI, device lock becomes a contract + technical enforcement issue. You either require managed endpoints, enforce via VDI with strong session controls, or prohibit access.

What you actually need to do (step-by-step)

1) Define the “device lock standard” you will enforce

Create a short standard (one page is enough) that specifies:

• Which device types are covered (Windows, macOS, Linux, iOS/iPadOS, Android, thin clients, VDI sessions).
• What “lock” means in your environment (screen lock/session lock) and that re-authentication is required after lock.
• Where configuration is enforced (GPO, Intune/MDM, Jamf, endpoint management, VDI policy).
• How exceptions work (documented approval, compensating controls, expiration).

Write the standard as measurable criteria so IT can implement without interpretation. In your SSP, phrase it as an enforceable control statement tied to specific systems and owners (NIST SP 800-171 Rev. 3).

2) Inventory in-scope endpoints (and close the “unknown device” gap)

You need a list of endpoints that can access CUI. Minimum fields:

• Owner (employee/contractor/third party)
• Platform/OS
• Management state (enrolled in MDM, domain-joined, etc.)
• Access path to CUI (VPN, VDI, browser/SaaS, local app)
• Exception status (yes/no, with ticket link)

If you can’t enumerate the population, you can’t credibly claim coverage. This is where tools like Daydream help: map the requirement to system components and accountable owners, then track gaps as discrete POA&M items with closure validation (NIST SP 800-171 Rev. 3).

3) Implement centralized enforcement (don’t rely on local settings)

Configure device lock centrally so settings are consistent and reportable:

• Windows: Group Policy or MDM policies that control inactivity timeout and password-required-on-wake.
• macOS: MDM configuration profiles enforcing screen lock and password on wake.
• Mobile: MDM enforcing auto-lock and passcode/biometric to unlock; prevent users from weakening settings.
• VDI / remote sessions: session timeout/lock policies at the broker level, plus endpoint lock if endpoints are still in scope.

Operational rule: if a device cannot be managed, it should not be allowed to access CUI without an alternative control path you can prove (for example, controlled VDI with strong session governance).

4) Handle exceptions with compensating controls and expiration

Common exceptions: lab equipment, specialized engineering workstations, manufacturing floor devices, shared terminals. For each exception:

• Document business justification and risk acceptance authority.
• Add compensating controls (physical controls, supervised access, restricted network segmentation, dedicated rooms, no CUI local storage).
• Set an expiration and re-approval workflow.
• Put the exception into the POA&M until resolved or formally accepted (NIST SP 800-171 Rev. 3).

5) Validate control operation with repeatable tests

Run a practical validation that a non-technical assessor can understand:

• Pick a sample of devices across each platform.
• Show the policy applied (MDM profile/GPO results) and demonstrate the lock behavior.
• Confirm re-authentication is required after lock.
• Capture screenshots/exports and store them with date, device identifier, and tester.

6) Keep it operational: monitoring + drift remediation

Build a lightweight operating rhythm:

• Review endpoint compliance reports for “device lock policy applied” and “noncompliant devices.”
• Investigate root causes (unenrolled devices, policy conflicts, local admin changes).
• Track remediation through tickets, and close only after re-test evidence is captured.
• Update SSP and POA&M when scope changes (new device type, new access method) (NIST SP 800-171 Rev. 3).

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design (what you intended)

• Device Lock Standard (configuration requirements + scope)
• SSP control statement mapping 03.01.10 to systems, components, and control owners (NIST SP 800-171 Rev. 3)

Implementation (what you set)

• GPO/MDM configuration screenshots or exported policy settings
• Baseline configuration documentation for each platform

Operation (proof it’s working)

• Endpoint compliance reports showing policy deployment status
• Samples of device policy application output (e.g., “policy installed” evidence)
• Test scripts/checklists and test results (screenshots/logs)
• Exception register with approvals, compensating controls, and expiration
• POA&M entries for gaps, with closure validation artifacts (NIST SP 800-171 Rev. 3)

Common exam/audit questions and hangups

Assessors and auditors tend to ask:

• “Show me the configuration that enforces device lock on Windows/macOS/mobile.”
• “How do you know every CUI endpoint is covered? What’s your device population?”
• “What happens for contractors or third parties accessing CUI?”
• “How do you handle shared workstations or lab devices?”
• “Prove this is operating over time, not set once.”

Hangups that slow assessments:

• Policies exist, but no evidence of enforcement.
• Evidence exists, but it’s not tied to the SSP narrative and system boundary.
• Exceptions are informal (“we allow this one system”) with no approvals or compensating controls (NIST SP 800-171 Rev. 3).

Frequent implementation mistakes (and how to avoid them)

1. Relying on user behavior. Training users to lock screens is fine, but 03.01.10 needs technical enforcement. Fix: enforce via MDM/GPO and keep compliance reporting.

2. Ignoring remote access paths. Teams lock corporate laptops but forget VDI/jump hosts. Fix: include session lock policies in the standard and test VDI sessions explicitly.

3. No scope control for unmanaged endpoints. If BYOD or third-party laptops can access CUI via a browser, you may have no enforceable lock baseline. Fix: restrict access to managed devices or controlled VDI, and document the decision in the SSP (NIST SP 800-171 Rev. 3).

4. Exception sprawl. Exceptions become permanent. Fix: expiration dates, compensating controls, and POA&M tracking until closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases.

Risk-wise, device lock is commonly tied to real incidents: unattended devices, walk-up access in shared spaces, and lost/stolen endpoints that remained accessible due to weak lock behavior. For NIST SP 800-171 programs, failure often shows up as an assessment finding because it’s easy to test live and easy to demonstrate inconsistent coverage.

Practical execution plan (30/60/90-day)

Your plan needs to be fast, but defensible. Use phases instead of date promises.

First 30 days (Immediate: define + prove coverage directionally)

• Assign control owner (endpoint engineering) and accountable exec (IT/security leader).
• Publish the Device Lock Standard and update SSP mapping for 03.01.10 (NIST SP 800-171 Rev. 3).
• Build the initial inventory of in-scope endpoints and identify unmanaged access paths to CUI.
• Implement baseline policies in MDM/GPO for main platforms and validate on a small sample.
• Open POA&M items for missing platform coverage and unmanaged devices (NIST SP 800-171 Rev. 3).

Days 31–60 (Near-term: enforce broadly + handle exceptions)

• Expand enforcement to all platforms in scope, including VDI/jump hosts.
• Establish an exception workflow with compensating controls and expirations.
• Configure reporting dashboards/exports for compliance status.
• Run a larger validation sample and store evidence with device identifiers.

Days 61–90 (Operationalize: monitoring, drift, assessor-ready package)

• Set a recurring review cadence for endpoint compliance and exceptions.
• Perform a control self-assessment walkthrough: SSP narrative, configuration proof, operating evidence, POA&M status (NIST SP 800-171 Rev. 3).
• Package artifacts so an assessor can follow the chain from requirement → SSP statement → configuration → device compliance evidence.
• If you use Daydream, connect the SSP control statement to owned system components and keep POA&M closure validation attached to each gap item (NIST SP 800-171 Rev. 3).

Frequently Asked Questions

Does 03.01.10 require a specific inactivity timeout value?

The provided excerpt in the source pack does not specify a numeric timeout (NIST SP 800-171 Rev. 3). Define a value in your internal standard, enforce it centrally, and be consistent across in-scope endpoints.

Do mobile phones and tablets count for the 03.01.10: device lock requirement?

If they can access, process, or store CUI, treat them as in scope and enforce auto-lock plus re-authentication via MDM (NIST SP 800-171 Rev. 3). If you cannot enforce settings, restrict CUI access from those devices.

How do we handle shared workstations on a manufacturing floor?

Put them into your endpoint inventory and decide whether they are permitted to access CUI (NIST SP 800-171 Rev. 3). If yes, enforce lock policies and add compensating controls for the shared environment, then document the exception details and approvals.

What evidence is strongest for assessors: screenshots or system reports?

Reports/exports from your management plane (MDM/GPO/VDI) usually carry more weight because they show fleet-wide application, and screenshots help for spot validation. Tie both back to your SSP control statement for 03.01.10 (NIST SP 800-171 Rev. 3).

Do we need to document device lock in the SSP and POA&M?

Yes. Map the requirement to SSP control statements, responsible components, and control owners, and track gaps in the POA&M until validated closed (NIST SP 800-171 Rev. 3).

What if a third party uses their own laptop to access our CUI?

Treat that endpoint as part of the access path to CUI and require managed-device controls or a controlled access method you can enforce and evidence (NIST SP 800-171 Rev. 3). Put the requirement into third-party contract terms and access controls, and document any exceptions with risk acceptance.