AC-11(1): Pattern-hiding Displays

AC-11(1) requires that when a device locks, the screen must stop showing whatever was previously visible and instead display a publicly viewable image (for example, a generic lock screen). Operationally, you meet this by enforcing lock-screen policies across endpoints so sensitive content is never exposed to shoulder-surfing after idle timeout or manual lock. ¹

Key takeaways:

• Configure device lock behavior to replace prior on-screen content with a generic lock-screen image. ¹
• Prove enforcement with configuration baselines, MDM/GPO profiles, and verification evidence (screenshots, compliance reports, and test results).
• Scope matters: cover laptops/desktops, mobile, VDI/thin clients, and any shared or public-facing workstations where display exposure is plausible.

The ac-11(1): pattern-hiding displays requirement is about a simple failure mode: a user steps away, the device locks, but the screen still reveals sensitive content that was open moments before. AC-11(1) tightens the broader “session lock” concept by focusing on what remains visible on the display after locking. The control enhancement is explicit: the lock must conceal previously visible information by replacing it with a publicly viewable image. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing AC-11(1) is to treat it as an endpoint configuration and verification problem, not a policy-writing exercise. You need three things that auditors can quickly connect: (1) a clear standard that defines required lock-screen behavior, (2) centralized technical enforcement across device types, and (3) repeatable evidence that the setting remains in place over time.

This page gives requirement-level implementation guidance you can hand to IT and security operations, then use to collect evidence and answer assessor questions with minimal back-and-forth.

Regulatory text

Requirement (excerpt): “Conceal, via the device lock, information previously visible on the display with a publicly viewable image.” ¹

Operator interpretation: When a device transitions to a locked state (manual lock, idle timeout lock, or enforced session lock), the display must not show the last open application, document, chat window, dashboard, or any sensitive UI state. Instead, the lock screen must show a generic image or standard lock UI that is safe to view in public or shared spaces. ¹

What this is not: AC-11(1) does not require a specific lock timeout value in the excerpt you provided. It also does not, by itself, define authentication strength. Those topics are usually handled by the base AC-11 control and other access controls; here the focus is the display behavior after lock. ¹

Plain-English interpretation (what “pattern-hiding” means in practice)

“Pattern-hiding” is about preventing visual inference. Even if the user is locked out, an exposed screen can reveal:

• Customer data on a CRM page
• Case notes in a ticketing system
• Financials on an internal dashboard
• PII in an HR system
• Federal data on a contractor system

Your job is to ensure that once the lock engages, the screen shows a non-sensitive image (or a neutral lock screen) that does not preserve or reveal the prior content layout.

Who it applies to

AC-11(1) is typically assessed where NIST SP 800-53 is the governing control set, including:

• Federal information systems. ¹
• Contractor systems handling federal data (common in federal contracting environments). ¹

Operationally, scope it to any endpoint or user-facing compute surface where a locked display could be observed:

• Corporate laptops and desktops (Windows, macOS, Linux)
• Mobile devices (iOS/iPadOS, Android)
• VDI sessions and shared kiosk workstations
• Thin clients used in regulated operations
• Conference room PCs and shared admin terminals

If a third party operates endpoints on your behalf (managed IT, call center BPO, field services), incorporate the requirement into third-party security requirements and verify through attestations plus spot checks where contractually allowed.

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

Step 1: Define the requirement as a measurable endpoint standard

Write a short control standard (one page is enough) that states:

• The device must lock and upon lock must conceal previously visible information by showing a publicly viewable image. ¹
• The standard applies to in-scope endpoints (list types and ownership models: corporate-owned, BYOD if allowed, shared workstations).
• The enforcement mechanism (MDM, endpoint management, domain policy, configuration management) is mandatory for managed assets.
• Exception criteria (see Step 6).

Keep it measurable: “After lock, the prior application screen is not visible.”

Step 2: Choose enforcement points per platform

Map each platform to a control mechanism your operators already use:

• Windows: Group Policy / MDM configuration service provider (CSP) policies that enforce a lock screen and prevent interactive session content from persisting visually.
• macOS: MDM profiles (screen saver/lock settings, lock screen configuration) and configuration profiles that prevent information from remaining visible after lock.
• iOS/Android: MDM device restrictions and lock-screen settings; restrict lock-screen notification content where that could re-expose sensitive information (align this to your data classification).
• VDI: VDI broker/session policies plus endpoint policy for the physical client. AC-11(1) is failed if the thin client locks but still displays the last frame of the VDI session.

You do not need to document every vendor setting name in the compliance narrative. You do need an implementation procedure that IT can execute and an assessor can trace to evidence.

Step 3: Implement a “generic lock screen” baseline

Technical objective: on lock, show a neutral lock screen image or lock UI that contains no sensitive information. ¹

Concrete decisions to make:

• What image is “publicly viewable” for your organization (company logo is usually fine; avoid names, locations, project codes, customer names).
• Whether to allow lock-screen widgets (weather/calendar can leak location or meeting names).
• Whether to show notifications on lock screen (can leak message previews, ticket subjects, or customer identifiers).

Document these decisions in the standard and enforce them via configuration.

Step 4: Validate with a repeatable test procedure

Create a simple test script that a tech or auditor can follow:

1. Open a document or app page that contains representative sensitive content.
2. Trigger lock (manual lock and idle lock, if applicable).
3. Observe the display from a normal viewing distance.
4. Confirm the prior content is not visible; only the generic lock screen appears. ¹

Run this test across:

• One device per standard build image
• One device per major OS version
• One VDI endpoint type
• Any high-risk areas (reception desks, call floors, shared workstations)

Step 5: Operationalize continuous compliance (don’t rely on one-time configuration)

Auditors frequently find drift: an image baseline is set, then overwritten by user personalization or a later OS update.

Minimum operating rhythm:

• Monitor endpoint compliance via your MDM/UEM reporting (policy compliance status, configuration profile installed).
• Add a configuration drift check to endpoint engineering change management.
• Re-test after major OS upgrades or changes to lock screen/notification features.

If you use Daydream to manage control ownership and recurring evidence, map AC-11(1) to a control owner, a documented procedure, and a recurring evidence set (for example, monthly MDM compliance exports plus quarterly spot-check tests). ¹

Step 6: Manage exceptions without breaking the control

Some systems have constraints (manufacturing HMIs, lab devices, legacy terminals). Handle this with an exception process:

• Require a business justification and compensating controls (physical barriers, restricted areas, privacy screens, supervised areas).
• Define an expiration date and a plan to remediate or replace.
• Keep an exception register that is easy to hand to assessors.

Required evidence and artifacts to retain

Keep evidence that proves design, implementation, and ongoing operation:

Design artifacts

• AC-11(1) control standard / endpoint configuration standard referencing the requirement language. ¹
• Applicability statement and scoped asset categories (what is covered, what is excluded, and why).

Implementation artifacts

• MDM/UEM profiles, GPO objects, configuration baselines, or hardening scripts (exported configurations).
• Screenshots or recordings showing: before lock (sensitive content visible), after lock (generic lock screen visible).
• VDI/thin client policy exports if applicable.

Operational artifacts

• Periodic compliance reports from device management showing the profile is installed and compliant.
• Change tickets for lock-screen policy updates.
• Exception register with approvals and compensating controls.

Common exam/audit questions and hangups

Expect these questions from assessors working against NIST SP 800-53:

• “Show me that after the lock engages, the last open screen is not visible.” Bring a short demonstration plus screenshots. ¹
• “How do you enforce this across macOS and mobile?” Have a platform-by-platform matrix of enforcement mechanisms.
• “How do you prevent user overrides?” Show configuration settings that restrict personalization where needed and your drift monitoring.
• “What about shared workstations and conference rooms?” Those are high-observation zones; be ready with scoped inventories and validation results.
• “How do you handle exceptions?” Show the register and compensating controls.

Frequent implementation mistakes (and how to avoid them)

1. Assuming “password required” equals compliance. Authentication on wake does not prove the display is concealed. You must show the publicly viewable image replaces prior content. ¹

2. Ignoring lock-screen notifications. Message previews can reintroduce sensitive content to a locked display. Decide what is allowed by data classification, then enforce it.

3. Missing VDI/thin client behavior. Some clients “freeze” the last frame when locked. Test the physical display, not only the virtual session.

4. No evidence of ongoing operation. A one-time screenshot proves point-in-time configuration. Add periodic compliance exports and documented spot checks.

5. Letting branding become sensitive. A lock screen can leak internal project names, building locations, or customer logos. Keep it generic.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement examples.

From a risk standpoint, AC-11(1) is a straightforward control that prevents passive disclosure. It reduces the chance of unauthorized viewing in open offices, public spaces, and shared environments, and it strengthens your audit posture because assessors can validate it quickly by observation plus configuration evidence. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign a control owner (endpoint engineering or security engineering) and a compliance owner (GRC).
• Publish the AC-11(1) endpoint standard with a clear pass/fail test.
• Inventory in-scope endpoint types and identify high-observation locations (shared workstations, reception, call floors).
• Build initial configuration profiles/GPOs for the most common platform.

Days 31–60 (Near-term)

• Roll out enforcement to managed endpoints by platform, starting with highest-risk user groups.
• Validate with hands-on tests across OS versions and VDI endpoints.
• Stand up recurring evidence collection: MDM compliance export procedure, evidence repository, naming conventions.

Days 61–90 (Operationalize)

• Expand coverage to edge cases: kiosks, labs, contractor-operated endpoints where contractually possible.
• Formalize the exception register and approval workflow.
• Add drift monitoring to endpoint change management and OS upgrade playbooks.
• In Daydream, map AC-11(1) to the owner, procedure, and recurring evidence artifacts so audits do not become a screenshot scavenger hunt. ¹

Frequently Asked Questions

Does AC-11(1) require a specific lock timeout?

The excerpt provided focuses on concealing display information “via the device lock” and does not specify a timeout value. Set timeouts in your broader session-lock standard, then treat AC-11(1) as the “what appears after lock” requirement. ¹

Are lock-screen notifications allowed?

AC-11(1) requires a publicly viewable image that conceals previously visible information. If notifications can display sensitive content, restrict previews or disable them on the lock screen for in-scope devices.

How do we prove compliance quickly during an audit?

Provide (1) the policy/standard, (2) exported MDM/GPO configuration, and (3) a short test record with screenshots showing sensitive content before lock and a generic lock screen after lock. ¹

What about VDI environments where the endpoint locks but the last frame stays visible?

Treat that as a fail condition for AC-11(1) until corrected. Fix by configuring the endpoint lock screen behavior and, if needed, adjusting the VDI client settings so the display switches to a generic lock screen.

Do privacy screens satisfy AC-11(1) as a compensating control?

Privacy screens reduce visual exposure but do not implement “conceal, via the device lock” on their own. Use them as a compensating control only under a documented exception with additional physical safeguards. ¹

How should third parties be handled (managed service providers, BPOs)?

Flow down the requirement in third-party security requirements and contracts, require endpoint policy evidence (MDM compliance exports or equivalent), and perform spot checks or audits where your agreement allows.

Footnotes

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