Quality, Expert-Derived Cybersecurity Documentation To Keep Organizations Secure, Compliant & Resilient  |  Got Questions? +1-307-241-8740
ComplianceForge

How Do I Implement NIST 800-171 R3 03.01.10 Device Lock?

NIST 800-171 R3 03.01.10 Device Lock at a Glance

  • Family: 03.01 Access Control (AC)
  • Requirement ID: 03.01.10 Device Lock
  • Assessment Objectives (AOs): Five (5) total, including the two (2) Organization-Defined Parameters (ODPs) below and three (3) determination statements
  • Organization-Defined Parameters (ODPs): One (1), specified by the Department of Defense (DoD) for the Defense Industrial Base (DIB)
  • Source NIST 800-53 R5 Controls: AC-11, AC-11(01)
  • NIST 800-171 R3 Kill Chain Phase: Phase 12, Secure Baseline Configurations (SBC)

Device Lock is the requirement behind the screen that locks itself and hides what was on it. It prevents access to a system when a user steps away without logging out, holds that lock until the user re-authenticates, and hides whatever was on the display behind a publicly viewable image. In R2 this was called "session lock." R3 renamed it to Device Lock and, importantly, added a new obligation: the lock has to be retained until the user reestablishes access using identification and authentication procedures. It sits alongside Session Termination (03.01.11), but the two are different. A device lock is a temporary hold for a user who intends to return, while session termination ends the session entirely.

A common difficulty with this requirement is treating it as a single screen-saver setting. It is three separate obligations: the trigger that engages the lock, the requirement that the lock stays until re-authentication, and the concealment of on-screen information. A screen saver that dims the display but does not require re-authentication, or that does not hide the previous content, fails part of the requirement even though something is happening after inactivity.

Where things stand for companies facing the transition from NIST 800-171 R2 to R3:

  • The National Institute of Standards and Technology (NIST) withdrew R2 on May 14, 2024, the same day R3 was published. The withdrawal notice states that R2 "has been withdrawn (archived), and is provided solely for historical purposes," so it will never receive another correction or clarification from NIST.
  • R2 remains the contractual standard for the Department of Defense (DoD) and the Defense Industrial Base (DIB). Cybersecurity Maturity Model Certification (CMMC) assessments reference it directly: per Title 32 of the Code of Federal Regulations (CFR), section 170.14(c)(3), "the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2."
  • The rulemaking points the other direction. The proposed Controlled Unclassified Information (CUI) rule for the Federal Acquisition Regulation (FAR), published June 23, 2026 as part of the Revolutionary FAR Overhaul, would apply CUI safeguarding requirements government wide rather than only to DoD contracts, and it sets the baseline at R3. That rule is not final, and DoD has separately signaled an interim rule to move CMMC to R3.

What Does NIST 800-171 R3 03.01.10 Actually Require?

The following is reproduced verbatim from NIST 800-171 R3, requirement 03.01.10 Device Lock. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts:

  • a. Prevent access to the system by [Selection (one or more): initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended].
  • b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.
  • c. Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

The source controls are AC-11 and AC-11(01) from NIST 800-53. Part a is a Selection, so you choose automatic inactivity locking, user-initiated locking, or both. Per the NIST discussion, device locks are temporary actions taken when a user departs the immediate vicinity but does not want to log out, and they are not an acceptable substitute for logging out when policy requires it. Publicly viewable images can include a screen saver pattern, a solid color, a photo, a clock, a battery indicator, or a blank screen, as long as Controlled Unclassified Information (CUI) is not displayed. You can read the requirement directly at NIST 800-171 R3, 03.01.10 (p. 13).

What Are the Organization-Defined Parameters (ODPs) Associated with NIST 800-171 R3 03.01.10?

One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.

The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.

  • ODP[01] (DoD memo identifier 03.01.10.a). one or more of the following PARAMETER VALUES are selected: {a device lock is initiated after <A.03.01.10.ODP[02]: time period> of inactivity; the user is required to initiate a device lock before leaving the system unattended}. DoD Position: initiating a device lock after “at most 15 minutes” of inactivity and requiring the user to initiate a device lock before leaving the system unattended.
  • ODP[02] (DoD memo identifier 03.01.10.a). the time period of inactivity after which a device lock is initiated is defined (if selected). DoD Position: initiating a device lock after “at most 15 minutes” of inactivity and requiring the user to initiate a device lock before leaving the system unattended.

Note the asymmetry: NIST 800-171A R3 decomposes this requirement into two (2) Organization-Defined Parameters, while the DoD memorandum addresses them with one (1) entry, because a single bracketed assignment in the requirement text covers more than one parameter under assessment. Each ODP still needs its own answer in the System Security Plan (SSP).

The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.

What Are the Assessment Objectives (AOs) For NIST 800-171 R3 03.01.10?

NIST 800-171A R3 breaks 03.01.10 into five (5) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and three (3) determination statements. These AOs are:

  • A.03.01.10.ODP[01]: one or more of the following PARAMETER VALUES are selected: {a device lock is initiated after <A.03.01.10.ODP[02]: time period> of inactivity; the user is required to initiate a device lock before leaving the system unattended}.
  • A.03.01.10.ODP[02]: the time period of inactivity after which a device lock is initiated is defined (if selected).
  • A.03.01.10.a: access to the system is prevented by <A.03.01.10.ODP[01]: SELECTED PARAMETER VALUES>.
  • A.03.01.10.b: the device lock is retained until the user reestablishes access using established identification and authentication procedures.
  • A.03.01.10.c: information previously visible on the display is concealed via device lock with a publicly viewable image.

The two (2) ODPs cover the selection of the locking method and the inactivity timeout. If you are a DoD contractor, they are not open questions. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the timeout is set to initiating a device lock after at most fifteen (15) minutes of inactivity and requiring the user to initiate a device lock before leaving the system unattended, which selects both parameter values. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.10 (p. 15).

Assessment Methods and Objects for NIST 800-171 R3 03.01.10

Examine: access control policy and procedures; procedures for session lock and identification and authentication; system design documentation; system configuration settings; display screen with session lock activated; system security plan.

Interview: personnel with information security responsibilities; system developers; system administrators.

Test: mechanisms for implementing the access control policy for session lock; session lock mechanisms.

How Does NIST 800-171 R3 03.01.10 Map From NIST 800-171 R2?

03.01.10 maps from NIST 800-171 R2 requirement 3.1.10 (use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity):

  • A.03.01.10.ODP[01] and A.03.01.10.a map directly to R2 3.1.10[b] (access and viewing of data is prevented by initiating a session lock).
  • A.03.01.10.ODP[02] maps directly to R2 3.1.10[a] (the period of inactivity after which a lock initiates is defined).
  • A.03.01.10.c maps directly to R2 3.1.10[c] (previously visible information is concealed).
  • A.03.01.10.b is net new for R3.

Mapped against the five (5) AOs, four (4) are direct (minimal effort) and one (1) is net new (significant effort), with none indirect and none with no mapping. The renamed control carries forward cleanly except for the new re-authentication objective. R2 required the lock and the pattern-hiding display but did not separately assess that the lock is retained until the user reestablishes access. A.03.01.10.b makes that explicit, so a lock that clears on any keypress rather than requiring re-authentication is now a gap.

How Does NIST 800-171 R3 03.01.10 Map to NIST 800-53 R5 and the SCF?

Source Controls in NIST 800-53 R5:

  • AC-11
  • AC-11(01)

Secure Controls Framework (SCF) Crosswalk

Organizations running a single control set across multiple frameworks can satisfy 03.01.10 through the following SCF controls:

  • CFG-04 Secure Baseline Configurations
  • CFG-04.3 Session Lock
  • CFG-04.4 Pattern-Hiding Displays

The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.

Common Pitfalls with NIST 800-171 R3 03.01.10

The following are issues teams may encounter rather than certainties. They are about the new objective and the three-part structure, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:

  • Re-authentication is the net-new objective. A.03.01.10.b requires the lock to stay until the user reestablishes access through identification and authentication. A lock that dismisses without re-authentication does not satisfy R3.
  • Concealment is separate from locking. A.03.01.10.c requires hiding previously visible information with a publicly viewable image. Locking input without hiding the screen content leaves CUI visible and misses part c.
  • The trigger is a selection. A.03.01.10.a is satisfied by the method or methods you selected in ODP[01]. For DoD work that means both an inactivity timeout and user-initiated locking, so document and configure both.
  • A device lock is not a logout. Per the NIST discussion, device locks are not an acceptable substitute for logging out when policy requires it, so do not use this control to satisfy session termination or forced logout obligations.

What Is Reasonable Evidence For NIST 800-171 R3 03.01.10?

Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.01.10 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.01.10 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.

  • E-AST-12 Secure Baseline Configurations Reviews. A review process to ensure secure baseline configurations (sbc) are current and applicable (e.g., system configuration settings and associated documentation).
  • E-AST-13 Secure Baseline Configurations - Cloud-Based Services. Secure baseline configurations for all deployed types of cloud-based services or applications.
  • E-AST-14 Secure Baseline Configurations - Databases. Secure baseline configurations for all deployed types of databases.
  • E-AST-15 Secure Baseline Configurations - Embedded Technologies. Secure baseline configurations for all deployed types of embedded technologies.
  • E-AST-16 Secure Baseline Configurations - Major Applications. Secure baseline configurations for all deployed types of major applications.
  • E-AST-17 Secure Baseline Configurations - Minor Applications. Secure baseline configurations for all deployed types of minor applications.
  • E-AST-18 Secure Baseline Configurations - Mobile Devices. Secure baseline configurations for all deployed types of mobile devices.
  • E-AST-19 Secure Baseline Configurations - Network Devices. Secure baseline configurations for all deployed types of network devices.
  • E-AST-20 Secure Baseline Configurations - Server Class Systems. Secure baseline configurations for all deployed types of server-class operating systems.
  • E-AST-21 Secure Baseline Configurations - Workstation Class Systems. Secure baseline configurations for all deployed types of workstation-class operating systems.

Alongside these, keep the System Security Plan (SSP) narrative for 03.01.10 recording the ODP values you adopted.

Timeline Considerations for NIST 800-171 R3 03.01.10

With four (4) AOs mapping directly and one net new, 03.01.10 is a light lift with a single new obligation to close. A realistic sequence:

  1. Select the locking method and set the timeout (ODP[01] and ODP[02]). For DoD contracts, adopt at most fifteen (15) minutes of inactivity and also require user-initiated locking. For non-DoD scopes, define and document your own.
  2. Configure automatic and user-initiated device lock so access is prevented (A.03.01.10.a).
  3. Confirm the lock requires re-authentication before it releases (A.03.01.10.b), the net-new objective.
  4. Confirm the lock conceals on-screen information with a publicly viewable image (A.03.01.10.c).
  5. Collect evidence for all five (5) AOs, including configuration screen shots of the timeout, the re-authentication prompt, and the concealment image.

Frequently Asked Questions About NIST 800-171 R3 03.01.10

What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.01.10? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.01.10.a: initiating a device lock after “at most 15 minutes” of inactivity and requiring the user to initiate a device lock before leaving the system unattended.

How many assessment objectives does NIST 800-171 R3 03.01.10 have? NIST 800-171A R3 breaks 03.01.10 into five (5) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and three (3) determination statements. An assessor works through each one separately, so each needs its own evidence.

Which NIST 800-53 R5 controls does NIST 800-171 R3 03.01.10 come from? AC-11, AC-11(01).

Where does NIST 800-171 R3 03.01.10 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.

Bottom Line on NIST 800-171 R3 03.01.10

03.01.10 Device Lock prevents access after inactivity or on demand, holds the lock until the user re-authenticates, and hides what was on the screen. It maps from R2 3.1.10 (session lock) with four (4) assessment objectives transitioning directly and one net new, the requirement that the lock be retained until re-authentication. The recurring problem is treating it as a single screen-saver setting. Set the timeout and method, require re-authentication to clear the lock, conceal the display, and keep screen shots as evidence.

Authoritative sources:

Authoritative sources:

This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.