Control statement
- a.Prevent further access to the system by [Organization-defined: ac-11_odp.01] ; and
- b.Retain the device lock until the user reestablishes access using established identification and authentication procedures.
Discussion
Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks can be implemented at the operating system level or at the application level. A proximity lock may be used to initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). User-initiated device locking is behavior or policy-based and, as such, requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of systems, such as when organizations require users to log out at the end of workdays.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Device Lock as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to identity, authorization, least privilege, session boundaries, and access lifecycle governance.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- access approvals and entitlement records
- role and group configuration exports
- periodic access review results
- authentication and authorization logs
Common failure patterns
- standing privileges that outlive business need
- shared or orphaned accounts
- access rules implemented differently across systems
- approvals that cannot be traced to actual permissions
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- AC-11a.further access to the system is prevented by [Organization-defined: ac-11_odp.01];
- AC-11b.device lock is retained until the user re-establishes access using established identification and authentication procedures.
Examine
- Access control policy
- procedures addressing session lock
- procedures addressing identification and authentication
- system design documentation
- system configuration settings and associated documentation
- security plan
- system security plan
- other relevant documents or records
Interview
- System/network administrators
- organizational personnel with information security responsibilities
- system developers
Test
- Mechanisms implementing access control policy for session lock
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Related NIST SP 800-171 requirements
These Rev. 3 requirements cite this base control or one of its enhancements as a source. The relationship does not by itself determine contractual applicability or complete implementation.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
AC-11(1) — Pattern-hiding Displays
Conceal, via the device lock, information previously visible on the display with a publicly viewable image.
Official discussion
The pattern-hiding display can include static or dynamic images, such as patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen with the caveat that controlled unclassified information is not displayed.
Assessment objectives and methods
information previously visible on the display is concealed, via device lock, with a publicly viewable image.
Examine
- Access control policy
- procedures addressing session lock
- display screen with session lock activated
- system design documentation
- system configuration settings and associated documentation
- system security plan
- other relevant documents or records
Interview
- System/network administrators
- organizational personnel with information security responsibilities
- system developers
Test
- System session lock mechanisms
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.