- Enforce the lock timeout and a pattern-hiding lock screen through central policy on every managed endpoint.
- Decide and document the exceptions (production displays, monitoring consoles) with compensating physical measures rather than silent exclusion.
- Include mobile devices and VDI sessions; idle-lock policy tends to stop at the desktop fleet.
03.01.10OFFICIAL TITLEPENDING NIST SME REVIEW
03.01.10 — Device Lock
03.01 Access Control · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires preventing access to the system by initiating a device lock after an organization-defined period of inactivity or requiring users to lock the device before leaving it unattended; retaining the lock until the user re-authenticates; and concealing previously visible information with a pattern-hiding display (aligned to SP 800-53 AC-11 with the pattern-hiding enhancement).
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Walk-away screens lock themselves after a defined idle period, hide what was on the display, and require re-authentication to resume. Set it centrally, keep the timeout short enough to matter, and deal honestly with the machines people want exempted — conference-room PCs and shared terminals are where unlocked sessions live.
Across revisions
Rev. 2's session lock becomes device lock, with user-initiated locking recognized alongside the inactivity timer; the pattern-hiding display expectation carries forward.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Policy exports for lock timeout and lock-screen behavior
- The documented exception list with compensating measures
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |