AC-11: Device Lock

To meet the ac-11: device lock requirement, you must configure systems to automatically lock and prevent further access after a defined trigger (typically inactivity) and require re-authentication to resume use. Operationalize AC-11 by setting enterprise lock standards, enforcing them via endpoint/MDM and OS policies, and retaining evidence that settings are deployed and effective. ¹

Key takeaways:

• AC-11 is a technical control: configure device/session locking so an unattended device cannot be used without re-authentication. ¹
• Auditors expect policy + enforced configuration + proof of operation (screenshots/reports, device compliance results, and exceptions). ²
• The fastest path is to assign a control owner, define lock parameters, deploy via central management, and run recurring compliance checks. ²

AC-11 (Device Lock) is one of those controls that looks simple but routinely fails in audits because teams treat it as an “IT setting” rather than a requirement with scope, parameters, exceptions, and evidence. The control’s purpose is straightforward: if a user walks away from a workstation, kiosk, laptop, virtual desktop, or other access device, the system must transition into a locked state that blocks further access until the user re-authenticates. ¹

For a CCO, Compliance Officer, or GRC lead, the goal is to translate AC-11 into (1) a clear standard that engineering can implement, (2) technical enforcement through endpoint management, and (3) audit-ready proof that the settings are applied across the in-scope fleet, including remote workers and privileged administrators. You also need a clean approach for exceptions (for example, certain operational technology or shared-device scenarios) that does not undermine the baseline.

This page gives requirement-level implementation guidance you can hand to IT and assessors: what AC-11 means in plain English, who and what it applies to, how to implement it step-by-step, and what evidence to retain so you can pass an assessment without scrambling.

Regulatory text

NIST SP 800-53 Rev. 5 AC-11 excerpt: “Prevent further access to the system by {{ insert: param, ac-11_odp.01 }} ; and” ¹

What the operator must do with this text

AC-11 is written with an organization-defined parameter (the placeholder). Your job is to define the trigger and lock behavior (the parameter) and then enforce it on in-scope systems so the lock reliably prevents further access. In practice, most organizations express the parameter as a lock condition such as inactivity time, device state, or session state, then require re-authentication to regain access. Document the parameter, implement it centrally, and retain evidence that it is operating as designed. ²

Plain-English interpretation (what AC-11 means)

• Your systems must lock the user interface/session under defined conditions.
• After the lock, an attacker (or curious passerby) must not be able to continue the session or access data without re-authenticating.
• The “requirement” is not satisfied by a policy statement alone; assessors will look for enforced configuration and proof that endpoints comply. ²

Who it applies to (entity + operational context)

AC-11 generally applies to:

• Federal information systems and environments aligned to NIST SP 800-53 control baselines. ²
• Contractor systems handling federal data (including cloud and on-prem environments used to process, store, or transmit federal information). ²

Operationally, assume AC-11 applies wherever a human can leave an authenticated session unattended:

• Corporate endpoints (Windows/macOS/Linux workstations and laptops)
• Mobile devices (phones/tablets) managed by MDM
• Virtual desktops and jump boxes
• Admin consoles used for privileged access
• Shared devices (front-desk systems, call centers, labs), with special attention to how re-authentication works for multiple users ²

What you actually need to do (step-by-step)

1) Assign ownership and define scope

1. Name a control owner (typically Endpoint Engineering, IAM, or SecOps) and a GRC owner accountable for requirements and evidence.
2. Define “in-scope devices/sessions” by category: managed endpoints, BYOD (if allowed), VDI, servers with interactive logons, shared kiosks.
3. Decide how you treat service accounts and non-interactive sessions so you do not misapply locking in a way that breaks operations. ²

Deliverable: AC-11 control record with owner, scope statement, and enforcement mechanism.

2) Set your organization-defined device lock parameter

AC-11 requires you to fill in the parameter. Create a written standard that answers:

• What triggers the lock (inactivity, lid close, screen saver start, session disconnect)?
• How quickly the lock must occur (express this as a formal configuration value in your standard, even if different groups have different baselines).
• What is required to unlock (password, MFA re-prompt, smart card, biometric, SSO re-auth)?
• What exceptions are allowed and how they are approved, time-bound, and reviewed. ²

Deliverable: “Device/Session Lock Standard” referenced by your access control policy.

3) Implement technical enforcement by platform

Map each platform to a primary enforcement point:

• Windows/macOS/Linux endpoints: OS configuration profiles via endpoint management; ensure lock and authentication on resume.
• Mobile (iOS/Android): MDM passcode + auto-lock requirements; require authentication after idle/lock.
• VDI / remote sessions: session lock policies and timeouts; ensure reconnect requires auth.
• Privileged access paths: hardened admin workstations, jump hosts, and privileged consoles should follow the strictest baseline you define. ²

Deliverable: Configuration baselines and deployment rings (pilot, broad rollout), with documented settings.

4) Build an exceptions workflow that auditors can accept

Exceptions are common. What fails audits is informal exceptions (“this team can’t support it”) without documentation. Your exceptions process should include:

• Business justification and risk acceptance
• Compensating controls (for example, restricted physical access, auto-logoff, or session monitoring)
• Expiration date and periodic review
• Named approvers (security + business owner) ²

Deliverable: Exception register entries tied back to AC-11.

5) Test and prove operation (not just configuration)

Before you claim compliance:

• Sample each device class and confirm the lock triggers under the defined condition.
• Validate that the lock prevents further access and requires re-authentication, including after remote disconnect/reconnect scenarios that often bypass expectations.
• Confirm the setting survives updates and does not drift. ²

Deliverable: Test plan + test results (screenshots, recordings where permitted, or standardized verification checklists).

6) Establish recurring monitoring and evidence collection

AC-11 becomes an audit headache when teams cannot show it stays enforced. Set a cadence where endpoint compliance reports are exported, reviewed, and retained. Also monitor:

• Devices not checking in
• Users with local admin overrides
• Policy conflicts between tools
• Newly enrolled endpoints that missed baseline policies ²

Deliverable: Recurring compliance report and review sign-off.

Required evidence and artifacts to retain (audit-ready)

Keep evidence that covers design, implementation, and operation:

Governance artifacts

• Access Control Policy section referencing device lock and your defined parameter ²
• Device/Session Lock Standard (the parameter definition) ¹
• Control ownership and RACI (who implements, who monitors, who approves exceptions)

Technical artifacts

• Configuration baseline export(s) or policy configuration screenshots from endpoint/MDM/VDI tooling
• A device compliance report showing applied settings across the in-scope population
• Exception register with approvals and compensating controls ²

Operational artifacts

• Test results demonstrating lock and re-authentication behavior on representative systems
• Periodic review notes or tickets showing follow-up on noncompliant devices
• Change management records for baseline updates

Common exam/audit questions and hangups

Expect these questions and have crisp answers:

1. “What is your organization-defined AC-11 parameter?” Provide the standard and show where it is enforced. ¹
2. “How do you know devices comply today?” Provide current compliance reporting, not only screenshots from initial setup.
3. “How do you handle shared devices and kiosks?” Show your kiosk design (restricted apps, re-authentication per user, and physical controls if relevant). ²
4. “What about remote access sessions and VDI?” Show session lock behavior for disconnects and idle.
5. “Do privileged admin endpoints follow the same or stricter rules?” Be explicit; inconsistencies here get attention.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Policy-only compliance (“we require screen locks”)	Auditors test devices and request evidence of enforcement	Implement via central management and keep compliance exports 2
Undefined parameter	AC-11 explicitly expects you to define the placeholder value	Write the standard; link it to the enforced setting 1
Exceptions by email/Slack	No traceability, no review cycle	Use a ticketed workflow, time-bound approvals, and an exception register
Treating VDI/jump hosts as out of scope	They are high-risk interactive sessions	Include them explicitly in scope and verify lock/re-auth
No drift management	Settings regress after tool changes or device re-enrollment	Add recurring compliance checks and remediation workflows

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-11, so you should frame risk in operational terms rather than citing case law. A weak device lock posture increases exposure to:

• Walk-up access in offices, labs, call centers, and shared spaces
• Credential/session hijacking on unattended endpoints
• Lateral movement opportunities if an unlocked admin session exists ²

For regulated programs and federal-aligned assessments, AC-11 gaps often surface as “basic hygiene” findings because assessors can validate them quickly through observation and sampling. Treat AC-11 as an always-on baseline and make the evidence easy to retrieve.

A practical 30/60/90-day execution plan

Use this as an execution sequence (phases, not promises about elapsed time).

First 30 days (stabilize requirements and ownership)

• Assign control owner and GRC owner; document scope boundaries (managed endpoints, VDI, kiosks, admin paths). ²
• Draft the organization-defined AC-11 lock parameter and exception criteria; get security + IT sign-off. ¹
• Inventory enforcement points (MDM, endpoint manager, IdP/SSO, VDI tooling) and identify gaps where you cannot centrally enforce.

Days 31–60 (deploy enforcement and start evidence)

• Implement baselines by platform; start with highest-risk populations (privileged admin endpoints and shared devices).
• Run a compliance report; open remediation tickets for noncompliant devices and missing check-ins.
• Stand up the exception workflow and backfill any existing informal exceptions into the register. ²

Days 61–90 (operationalize monitoring and audit readiness)

• Add recurring reporting and review routines (export, review, remediate, retain).
• Perform a mini-assessment: sample devices, validate lock behavior, validate re-authentication, and confirm drift controls.
• Package artifacts into an “AC-11 evidence bundle” so audits do not become a fire drill. A tool like Daydream can help you map AC-11 to a control owner, implementation procedure, and recurring evidence artifacts, then track refresh cycles so evidence stays current. ²

Frequently Asked Questions

What counts as “device lock” for AC-11?

A lock state that prevents further access to the system until the user re-authenticates. Your organization defines the specific trigger/parameter, then enforces it consistently. ¹

Do screen savers count as AC-11 compliance?

Only if the screen saver results in a locked session that blocks access and requires re-authentication. A visual screen saver without authentication on resume will usually fail testing. ²

How should we handle shared workstations or kiosks?

Treat them as in scope and define a kiosk pattern: short lock triggers, clear re-authentication for each user, and an exceptions process if the workflow cannot support standard settings. Document compensating controls for any exceptions. ²

Is AC-11 only an endpoint control, or does it apply to VDI and remote admin sessions too?

Apply it to any interactive session where a user can step away, including VDI, jump hosts, and privileged consoles. Assessors often sample these because they concentrate risk. ²

What evidence is usually enough for an assessor?

Provide (1) the written lock parameter standard, (2) configuration baselines from your management tools, and (3) compliance reporting plus a small set of test results demonstrating lock and re-authentication. ²

We have a few devices that cannot lock due to operational constraints. Are we automatically noncompliant?

Not automatically, but you need documented exceptions with approval, compensating controls, and periodic review. Keep the exception list small and time-bound so the baseline remains meaningful. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5