AC-11 — Device Lock
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.
Read the official statement, discussion, parameters, enhancements, and assessment methods →
NIST CSF 2.0 informative references
These CSF Subcategories list this base control or one of its enhancements in the imported NIST informative reference.
NIST SP 800-171 and SP 800-172
SP 800-171 requirements sourcing this control
SP 800-172 enhanced requirements sourcing this control
MITRE D3FEND techniques
MITRE ATT&CK relationships
Curated mitigation mappings
Inferred behavior relationships
Experimental: These relationships are inferred through D3FEND and must be validated against architecture, telemetry, and threat context.
Use the map without overclaiming.
A CSF informative reference is not an equivalence statement. A source-control relationship is not proof of implementation. A D3FEND semantic relationship is not a product claim. An inferred ATT&CK link is a hypothesis for engineering analysis.
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST or MITRE. Informative references and cross-framework relationships support navigation and analysis; they do not establish compliance, applicability, equivalence, control inheritance, or guaranteed mitigation effectiveness.