In Episode 11 of my NIST SP 800-53 Rev 5 Access Control series, I break down AC-11 (Device Lock) and simplify what the control is really asking you to do. Device lock is that temporary action that kicks in when a user stops work and steps away—either the user initiates it, or the system automatically locks after an organization-defined period of inactivity (for example, 15 minutes). The key point is that the session can stay running in the background, but the system must prevent further access until the user re-authenticates. I walk you through the actual control language: (A) initiate a device lock after a defined idle time and/or require the user to lock before leaving the system unattended, and (B) keep the device locked until access is re-established using your standard identification and authentication process. I also call out important discussion notes—device lock can be OS-level or application-level, proximity locks can be used (like Bluetooth/dongles), and device lock is not a substitute for logging out when your policy requires logout at end of day. For assessing/testing AC-11 during an SCA or self-assessment, I show my practical approach: review the Access Control policy/procedures and the SSP to confirm the required idle timeout, then validate configuration via screenshots and/or a live test (leave the system idle for the stated minutes plus one). Finally, verify re-authentication is required—because a blank screen that reveals the prior session without login is a problem. And yes, since this is a technical control pushed via AD/LDAP/domain settings, one solid sample is typically sufficient.