AC-11: Device Lock

What this control requires

AC-11 requires organizations to lock devices after a defined inactivity period and force re-authentication before the session resumes. The control addresses one of the most overlooked gaps in access management, the window between when a user walks away from a workstation and when that session becomes an attacker’s opportunity.

In practice, meeting AC-11 means you need two capabilities working together. First, a policy-driven inactivity timeout that triggers a device lock after a defined period of no keyboard or mouse activity. Second, a mechanism that forces re-authentication before the session resumes.

Specifically, the NIST SP 800-53 framework treats these two requirements as complementary. A lock without re-authentication is cosmetic, and re-authentication without an automatic trigger depends entirely on user behavior.

Where the control breaks down is the distinction between device lock and logout. AC-11 covers temporary locks, not session termination. Users who step away for a meeting don’t need to close every application and start over.

But organizations that rely solely on device locks as a substitute for logging out at the end of the workday are misapplying the control. Proximity-based locking, such as Bluetooth-paired dongles that trigger a lock when a user moves out of range, satisfies the intent and removes human inconsistency from the equation.

Why it matters

Most organizations treat device lock policies as a checkbox within the broader Access Control family, configured once during initial deployment and never revisited. That assumption ignores a class of attacks that specifically targets the gap between session inactivity and session termination. These attacks turn an unlocked or disconnected session into a lateral movement vector.

RDP session hijacking via tscon

In enterprise Windows environments, administrators frequently connect to servers via Remote Desktop Protocol (RDP) and disconnect without logging out. Windows retains these disconnected sessions in memory, preserving the authenticated identity, running applications, open network connections, and cached credentials. An attacker who has gained SYSTEM-level access on that server, often through an unpatched service or a web shell, can use the built-in tscon utility to reassign a disconnected session to their own connection without supplying any credentials (MITRE ATT&CK techniques T1563.002 and T1021.001).

The result is full identity inheritance. The attacker operates as the original user, with access to every resource that session had open. No login event is generated because no new authentication occurs, making detection significantly harder for security operations teams.

Specifically, when organizations enforce short inactivity timeouts and mandatory session locks, they reduce the window during which a disconnected session remains hijackable. A local privilege escalation that would otherwise grant access to every administrator who connected to that server gets contained to the single host where it occurred. The prerequisite of SYSTEM access sounds limiting in isolation, but in layered attacks it is routine.

In practice, initial access through one vulnerability provides the foothold, and lateral movement through abandoned sessions follows. Weak or absent device lock controls expose four specific attack vectors.

• Disconnected RDP sessions retained in memory on shared servers, accessible to any process running as SYSTEM
• Unlocked workstations in shared or open office environments, where physical access translates directly to authenticated access
• Long or absent inactivity timeouts that leave sessions usable for hours after a user walks away
• Mobile devices without automatic lock that expose corporate email, VPN credentials, and authentication tokens when lost or stolen

How to implement

The core challenge with AC-11 isn’t defining a timeout value. It’s enforcing consistent behavior across operating systems, remote access tools, mobile devices, and applications that each handle session locking differently.

For your organization

In practice, start by defining your inactivity timeout threshold in your access control policy. NIST does not prescribe a specific value, but most compliance baselines expect 15 minutes or fewer for moderate-impact systems and shorter intervals for high-impact systems or privileged accounts. Document this threshold and the rationale behind it.

Specifically, when configuring operating system policies, use centralized management tools. Group Policy Objects (GPOs) enforce screen lock timeouts on Windows endpoints, and configuration profiles handle the same function on macOS and iOS. Mobile device management (MDM) platforms push lock policies to Android and iOS devices.

The result is a single source of truth that prevents individual users or local administrators from overriding the timeout.

But in most environments, operating system lock policies alone leave gaps. Remote desktop sessions, virtual desktop infrastructure (VDI), and web-based applications each have their own session management. RDP session timeouts must be configured separately through Remote Desktop Session Host settings to disconnect or lock idle sessions.

Where the gap widens further is web applications. They should enforce server-side session expiration independent of the browser.

The consequence for your evidence package is clear. Include screenshots or exports of GPO settings, MDM configuration profiles, RDP session host policies, and application-level session timeout configurations. Auditors want to see that the policy exists, that technical controls enforce it, and that exceptions are documented and approved.

Where implementation falls short is the details. Common mistakes include setting the timeout but not requiring re-authentication after unlock, configuring workstation lock policies while ignoring server RDP sessions, and relying on user-initiated locking without an automatic fallback. Test your controls by verifying that a locked session genuinely requires credentials before resuming, not just a keypress.

Specifically, pay attention to privileged accounts. Accounts with administrative access should have shorter inactivity thresholds than standard user accounts, and any exception to the lock policy should go through a documented approval process with a defined expiration date.

For your vendors

When assessing a vendor’s AC-11 compliance, your questionnaire should address three areas directly. What is the configured inactivity timeout for systems that process your data? How is the timeout enforced, through operating system policy, application configuration, or both?

Take exceptions as a specific example. You need to ask how exceptions to the timeout policy are documented and approved.

The consequence is that you should request specific evidence rather than accepting a statement that “device lock is enabled.” Useful artifacts include screenshots of GPO or MDM configurations showing timeout values, RDP session host configuration exports, and the access control policy section that defines the inactivity threshold. A vendor’s security plan should reference AC-11 explicitly, with documented implementation details.

But red flags to watch for include vendors who cite a generic “security policy” without specific timeout values, configurations that show inactivity timeouts exceeding 30 minutes, and environments where server sessions are excluded from the lock policy. If a vendor cannot demonstrate that disconnected RDP sessions are subject to timeout or termination, the control gap is material. Third-party risk requirements under NIST SP 800-53 call for the same rigor you apply internally.

Specifically, verification beyond self-attestation involves requesting evidence of periodic testing. Ask whether the vendor conducts internal audits or penetration tests that validate session lock enforcement. A SOC 2 Type II report that references logical access controls may cover device lock, but you should confirm that the specific control objective maps to inactivity timeout and re-authentication, not just general access management.

In practice, you should also assess coverage across different system tiers. A vendor may enforce device lock on standard workstations but exempt database servers, jump boxes, or cloud management consoles. Ask for a complete inventory of systems in scope and whether each system type has a documented lock policy with matching technical enforcement.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 — Account Management: governs the lifecycle of user accounts that device lock protects during active sessions
• AC-07 — Unsuccessful Logon Attempts: limits authentication retries after a device lock triggers re-authentication
• IA-11 — Re-authentication: defines the authentication procedures that must be satisfied to unlock a locked device
• PL-04 — Rules of Behavior: establishes the user conduct expectations, including the responsibility to lock devices before leaving them unattended

Frequently asked questions

What is NIST SP 800-53 AC-11?

AC-11 is the Access Control family control that requires organizations to lock devices after a defined inactivity timeout and retain the lock until the user re-authenticates. The control applies to any system handling federal information at the MODERATE or HIGH baseline. It covers both automatic inactivity-triggered locks and user-initiated locks before leaving a device unattended.

What happens if AC-11 is not implemented?

Without AC-11, unattended devices and disconnected sessions remain authenticated and accessible to anyone with physical or network access. An attacker who gains access to a server with open RDP sessions can hijack those sessions without triggering a new login event. Failed implementation also creates audit findings during federal security assessments and may disqualify an authorization to operate for moderate and high-impact systems.

How do you audit AC-11?

Auditing AC-11 starts with verifying that the access control policy defines a specific inactivity timeout threshold and that system configurations enforce it. Assessors review GPO exports, MDM profiles, and RDP session host settings to confirm the documented timeout matches what endpoints actually enforce. They also test re-authentication by triggering a device lock and confirming that established identification and authentication procedures, not just a keypress, are required to resume the session.

What is the difference between device lock and session timeout?

A device lock preserves the user’s session in memory and requires re-authentication to resume, while a session timeout terminates the session entirely and requires a full login to start a new one. AC-11 specifically addresses device lock as a temporary measure for short absences. Proximity locks, such as Bluetooth-paired devices that trigger a lock when the user moves away, are a form of device lock rather than session termination. Understanding NIST SP 800-53 helps clarify how device lock fits within the broader access control family.