CMMC Level 2 Practice 3.1.10: Use session lock with pattern-hiding displays to prevent access and viewing of data after a

To meet cmmc level 2 practice 3.1.10: use session lock with pattern-hiding displays to prevent access and viewing of data after a requirement, you must enforce automatic session locking on in-scope systems and ensure the lock screen hides any sensitive content until the user re-authenticates. Operationalize it by setting enterprise lock timers, requiring re-auth, disabling lock-screen previews, and proving coverage with configuration evidence and testing.

Key takeaways:

• Enforce automatic session lock + re-auth on endpoints, servers, and VDI that process/store/transmit CUI.
• Configure pattern-hiding so the lock screen reveals no CUI (no notifications, previews, or open-window content).
• Keep assessor-ready evidence: baseline configs, MDM/GPO settings, exceptions, and validation test results.

CMMC Level 2 aligns closely to NIST SP 800-171 Rev. 2, and Practice 3.1.10 is one of the fastest controls to implement well, and one of the easiest to fail on evidence. The intent is simple: if a workstation, laptop, VDI session, or terminal is left unattended, an unauthorized person should not be able to view data or continue an active session. The “pattern-hiding display” phrase trips teams up because it’s more than “set a screen saver.” You need a lock state that blocks access and prevents shoulder-surfing from lock-screen previews or visible application content.

For a Compliance Officer, CCO, or GRC lead, the quickest path is to treat 3.1.10 as a configuration control with measurable coverage: define the in-scope asset population (CUI boundary), set standard lock and re-auth settings through centralized management, and retain screenshots/exports that prove the settings apply and remain enforced. You also need a clean exceptions process for specialized systems (lab gear, kiosks, manufacturing HMIs) so exceptions are controlled rather than informal.

Sources for this requirement’s mapping and expectations come from CMMC program materials and the mapped NIST control language. (DoD CMMC Program Guidance; 32 CFR Part 170; NIST SP 800-171 Rev. 2)

Regulatory text

Excerpt / mapping: CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.10: “Use session lock with pattern-hiding displays to prevent access and viewing of data after a …” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator interpretation (what you must do):

1. Trigger session lock after a defined period of inactivity (or when users manually lock).
2. Require re-authentication to regain access (not just moving the mouse).
3. Hide sensitive content while locked: no lock-screen notification previews, no snippets of emails/chats, no document thumbnails, and no visible session state that exposes CUI.
4. Apply to all in-scope systems within your CUI environment, including remote/virtual sessions where users can walk away from an unlocked console.

Plain-English interpretation

If someone steps away from a device that can access CUI, the device must lock on its own, and the lock screen must not show anything sensitive. The only way back in is to authenticate again. Your job is to make that true across the environment, not just “most laptops.”

Who it applies to (entity and operational context)

Applies to:

• Defense contractors and federal contractors handling CUI in a CMMC Level 2 scope. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational context (typical in-scope assets):

• User endpoints: Windows/macOS laptops and desktops used to access CUI.
• Privileged/admin workstations used to manage CUI systems.
• VDI and remote desktop sessions used for CUI work.
• Jump boxes/bastions used to administer CUI workloads.
• Shared workstations in controlled spaces (with special attention to exceptions and compensating controls).

Key scoping decision you must document:

• Which assets are in the CUI boundary and therefore must enforce session lock and pattern-hiding. Tie this to your system boundary narrative and asset inventory, so assessors see consistency with your CMMC scope statement. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

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

Step 1: Define the control “runbook” (owner, standard, exceptions)

Create a one-page control card for 3.1.10:

• Owner: IT (endpoint/identity) with GRC oversight.
• Standard: “Sessions auto-lock after inactivity; re-auth required; lock screen hides content.”
• In-scope populations: endpoint groups, VDI pools, server consoles, privileged devices.
• Exception criteria: operational necessity, alternate compensating safeguards, approval authority, review cadence.

This is basic governance, but it prevents the common audit failure: no one can explain how the control is run or proven.

Step 2: Set enterprise session lock timers and enforce re-auth

Implement centrally, not per-user:

• Windows: Group Policy or MDM configuration profiles to enforce inactivity lock and password-on-wake.
• macOS: Configuration profiles (MDM) for screen lock and password requirement.
• VDI/RDS: Session timeouts, disconnect/lock behaviors, and re-auth prompts where supported.
• Linux: Desktop environment policies where applicable, or session manager controls for managed workstations.

Your standard must be consistent across the CUI environment. If you have different timers by risk tier (for example, privileged workstations), document the rationale and ensure enforcement is technically locked down (not user-configurable).

Step 3: Implement “pattern-hiding displays” on the lock screen

This is where teams often miss the mark. Configure systems so that when locked, the screen does not reveal CUI through UI features:

• Disable lock-screen notification content and message previews (email, chat, collaboration tools).
• Disable document previews and “recent items” exposure on the lock screen.
• For mobile endpoints that access CUI, ensure lock-screen notifications don’t show message bodies (if mobile is in scope).

Also address physical display risk:

• Set screen to lock, not just dim.
• For shared spaces, consider privacy filters or workstation placement as a supplemental safeguard. Do not treat physical safeguards as a replacement for session lock; treat them as layered defense.

Step 4: Validate with tests that mirror assessor behavior

Build a simple validation script your team can repeat:

• Pick a sample from each in-scope device class (endpoint, VDI, jump box).
• Confirm inactivity triggers lock.
• Confirm re-auth is required.
• Confirm lock screen shows no message content, previews, or thumbnails related to CUI apps.
• Capture evidence (screenshots/video where allowed, plus configuration exports).

Assessors will often ask you to demonstrate this live on at least one device. Be ready.

Step 5: Control exceptions without losing the requirement

Some systems can’t behave like normal endpoints (manufacturing terminals, lab instruments, kiosk-like systems). For each exception:

• Record the asset, business justification, and why standard locking can’t be enforced.
• Implement compensating controls (controlled room, restricted access, locked cabinets, dedicated attendants, technical kiosk mode with restricted apps, etc.).
• Get formal approval and a review trigger (role change, relocation, software upgrade).

The goal is to show you manage risk deliberately, not that the environment is “special.”

Step 6: Keep the control healthy (ongoing monitoring)

Minimum operational checks:

• Confirm device compliance via MDM/GPO reporting.
• Track drift (users changing settings, local admin overrides, new device classes).
• Re-test after OS upgrades, MDM profile changes, or VDI image updates.

If you use Daydream to manage CMMC control operations, make 3.1.10 a recurring control with an evidence checklist (config exports + spot-check results) so you can answer assessors with a consistent evidence bundle every time.

Required evidence and artifacts to retain

Store evidence in an assessor-ready folder mapped to 3.1.10. Typical artifacts:

• Policy/standard excerpt: access control or session management standard covering auto-lock, re-auth, pattern-hiding.
• Configuration proof (central enforcement):
  • GPO/MDM profile screenshots or exports showing lock timer + password-on-wake.
  • VDI/RDS/session manager settings exports.
• Coverage proof:
  • Device compliance report from MDM/UEM showing the profile applied to in-scope assets.
  • Asset inventory segment showing in-scope population.
• Validation results:
  • Spot-check checklist with date, tester, device identifier, and pass/fail notes.
  • Screenshots that show lock screen with hidden notification content (avoid including real CUI in evidence).
• Exception register:
  • Approved exceptions, compensating controls, and review notes.
• Change records:
  • Tickets/changes for baseline deployment and subsequent modifications.

Common exam/audit questions and hangups

Expect these and prepare short, evidenced answers:

1. “Show me the settings are enforced, not user-configurable.”
   Provide GPO/MDM profile details and a compliance report.

2. “Demonstrate on a real device.”
   Have a test device available with CUI apps installed (no real CUI needed). Show inactivity lock and hidden previews.

3. “What is your inactivity period?”
   State the configured standard and where it’s documented. If different by tier, show the tiering logic and technical enforcement.

4. “Do VDI sessions lock the same way?”
   Show VDI image settings plus broker/session policies.

5. “How do you handle shared workstations?”
   Show a documented approach: named accounts vs shared accounts policy, rapid lock, physical controls, and exception handling if needed.

Frequent implementation mistakes and how to avoid them

• Mistake: screen saver enabled but no re-auth.
  Fix: require password on wake/unlock and confirm it’s enforced centrally.

• Mistake: lock screen shows email/chat previews.
  Fix: disable notification previews at OS level and in key apps where needed.

• Mistake: only laptops covered; VDI/jump boxes ignored.
  Fix: define device classes in scope and prove each class meets the requirement.

• Mistake: relying on “users are trained to lock their screen.”
  Fix: training supports the control; it does not substitute for automatic lock and enforced settings.

• Mistake: exceptions handled informally.
  Fix: maintain an exception register with approvals and compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so treat risk through the CMMC assessment lens. Failing 3.1.10 is a practical exposure: it creates an easy path for unauthorized viewing of CUI through unattended sessions, especially in shared offices, conference rooms, and production floors. In CMMC terms, weak session locking often signals broader endpoint configuration gaps, and assessors may sample adjacent access control practices more aggressively when they see configuration drift. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

A practical 30/60/90-day execution plan

First 30 days (get to enforced baseline)

• Confirm CUI boundary and in-scope asset groups (endpoints, VDI, admin workstations).
• Publish the 3.1.10 control card: owner, standard, exception path.
• Deploy lock + re-auth settings via GPO/MDM to a pilot group.
• Configure lock-screen pattern-hiding (notification previews off) in the same pilot.
• Create the evidence folder structure and the spot-check template.

By 60 days (expand coverage + prove it works)

• Roll out configurations to all in-scope endpoint groups.
• Implement equivalent settings in VDI images and session broker policies.
• Run spot checks across each device class and record results.
• Build the exception register and route any true exceptions for approval with compensating controls.
• Generate a compliance report from your management platform and archive it as evidence.

By 90 days (stabilize operations)

• Add a recurring control health check (configuration drift, new devices, image updates).
• Integrate checks into change management for OS upgrades and VDI image releases.
• Conduct an internal “assessor-style” walkthrough: pick a random device and demonstrate lock + pattern-hiding live, then show supporting evidence.
• If you run Daydream for control operations, automate evidence requests and attach recurring reports and spot-check outputs to the 3.1.10 control record for fast retrieval.

Frequently Asked Questions

Does “pattern-hiding display” mean I need special privacy screens on monitors?

No. The requirement is satisfied by a lock mechanism that hides on-screen content while locked, such as disabling lock-screen previews and requiring re-auth. Privacy screens can help in high-traffic areas, but they are supplemental.

Are screen lock and screen saver the same for CMMC 3.1.10?

A screen saver alone is not enough if it does not lock the session and require re-authentication. Your evidence should show an enforced lock state and the authentication requirement.

How do we handle conference room PCs or shared shop-floor workstations?

Put them in scope if they can access CUI, then enforce quick locking and pattern-hiding. If the device cannot technically comply due to operational constraints, document an approved exception with compensating physical and technical controls.

Do remote desktop and VDI sessions need this control too?

Yes, if the remote session provides access to CUI. Configure both the endpoint behavior and the remote session policies so an unattended session locks and does not reveal content.

What evidence is most persuasive to an assessor for 3.1.10?

Central configuration outputs (GPO/MDM profile settings), a coverage/compliance report for in-scope devices, and a documented spot-check with screenshots showing no lock-screen previews.

Can we satisfy this requirement with user training alone?

No. Training supports expected behavior, but assessors will look for technical enforcement and proof that it is operating across the CUI environment.