Session lock is one of those practices that every organization thinks they have covered until the assessor asks to see the actual configuration. Your workstations lock after 15 minutes, sure. But what about the cloud portal session? The remote desktop session? The VPN session? This practice works alongside AC.L2-3.1.11 (session termination) and IA.L2-3.5.1 (user identification), and supports the broader access control posture established in AC.L2-3.1.1.
What the assessor is actually evaluating
The assessor is checking two things: that sessions lock after inactivity, and that the lock screen hides the data.
Inactivity lock. After a defined period of no user input, the session locks automatically. The user has to re-authenticate (password, PIN, biometric) to get back in. The assessor will ask what the timeout period is and then verify it’s configured where you say it is.
Pattern-hiding display. When the session locks, whatever was on the screen is replaced with a lock screen, screensaver, or blank display. This is about preventing someone from reading CUI off an unattended screen. A standard Windows lock screen that shows the time and the user’s name is fine. The point is that the CUI data is gone from view.
The assessor will think about this practice from a physical security angle. Imagine an employee steps away from their desk to get coffee. Their screen is showing a spreadsheet with CUI. If the session doesn’t lock, anyone walking by can see that data. If the session locks after 15 minutes but someone walks by at minute 5, they can still see it. The assessor understands you can’t set the timeout to 30 seconds (people would revolt), but they want to see a reasonable threshold that’s actually enforced.
The assessor will also think about this across all session types. Workstation screen lock is the obvious one. But what about an admin who has a remote desktop session open to a server? Or a cloud portal session in a browser? If those sessions don’t have their own inactivity controls, the workstation screen lock is the only protection, and it needs to cover them all.
What a realistic SSP definition looks like
[Organization Name] implements session lock with pattern-hiding displays on all systems within the CUI boundary. Sessions lock automatically after [timeout period, e.g., 15 minutes] of inactivity, requiring re-authentication to resume.
Workstation screen lock is enforced via [Group Policy / endpoint management] with a maximum inactivity timeout of [timeout period]. The lock screen replaces all displayed content with the standard operating system lock screen. Users may also manually lock their workstation at any time (e.g., keyboard shortcut).
Cloud application sessions are configured with idle session timeouts through [identity provider conditional access / application settings]. Remote access sessions (VPN, remote desktop) have inactivity timeouts configured at [timeout period] or disconnect after [timeout period] of inactivity.
Users are trained to manually lock their workstations when stepping away from their desks, with automatic lock serving as a safety net.
Notable elements:
Specific timeout period. “15 minutes” or whatever your chosen value is. Not “a reasonable time” or “a short period.” The assessor will compare this number to your configuration.
Multiple session types covered. Workstations, cloud applications, remote access. Each has its own timeout mechanism. The SSP shows you’ve thought about all of them.
Manual lock mentioned. Training users to lock their workstations when stepping away is a complementary control. The automatic timeout is the safety net, not the primary mechanism.
How to present your evidence
- Group Policy or endpoint management configuration showing screen lock timeout
- Screensaver/lock screen policy showing pattern-hiding is enabled
- Cloud identity provider session timeout or conditional access policy
- VPN or remote access session timeout configuration
- SSP section with the specific timeout value
The assessor will want to see the configuration firsthand. Pull up the Group Policy or endpoint management policy that sets the inactivity timeout. Show the screen lock settings: timeout period, whether a password is required to resume, and that a screensaver or lock screen activates.
For cloud sessions, show the conditional access policy or identity provider setting that controls session lifetime and idle timeout. If you’ve configured sign-in frequency or persistent browser session controls, show those.
For remote access, show the VPN session timeout and any remote desktop idle disconnect settings.
Be ready for the assessor to test it. They may ask you to leave a workstation idle and wait for it to lock. More likely, they’ll just ask to see the policy and trust the configuration, but have a workstation ready just in case.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Timeout not enforced via policy. The screen lock is configured on individual machines but not deployed through a central policy. New machines don't get the setting. Users can change their own timeout. The assessor will ask how you ensure consistency, and "we set it up on each machine" isn't a scalable answer.
Cloud sessions don't time out. Workstations lock after 15 minutes, but the user's browser session in the cloud portal stays active indefinitely. If someone accesses that browser on the locked workstation (say, through a different method), the cloud session is still live.
Timeout value doesn't match the SSP. SSP says 15 minutes, configuration shows 30. Or the SSP doesn't specify a value at all. The assessor will compare the two. Make sure they match.
No pattern-hiding display. The session "locks" but the last application is still visible behind a transparent overlay, or the screensaver is disabled and the display just stays on with data showing. The lock needs to replace the display content entirely.
A defined timeout period that's consistent across workstations, cloud sessions, and remote access. Central policy enforcement, not per-machine configuration. A lock screen that fully replaces displayed content. Configuration screenshots that match the SSP. This practice is quick to pass when everything is aligned. The assessor checks the configuration, confirms it matches the documentation, and moves on.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
Your MSP probably configured the screen lock policy and session timeout settings. The assessor may ask them to walk through the configuration and explain how it’s enforced across all managed devices.
The MSP should know where every timeout setting lives: the endpoint management policy for workstations, the conditional access policy for cloud sessions, and the VPN configuration for remote access. They should be able to pull up each one and show the assessor the specific values.
One thing worth verifying: the MSP’s own remote management sessions. When the MSP connects to a machine in your environment via their remote management tool, does that session have an inactivity timeout? If the MSP leaves a remote session open and walks away from their own desk, is there a lock mechanism? This is an edge case, but a thorough assessor may ask.
Assessors test session lock by walking through your environment. They'll check workstation locks, cloud console sessions, VPN sessions, and remote access. Every session type needs timeout and pattern-hiding. If workstations lock after 15 minutes but cloud sessions don't have a timeout, that's a gap. Know your timeout values and be able to pull up the policy for every session type. Consistency across all entry points is what matters.
Ask your MSP to inventory every session type in your environment and confirm timeout settings for each one. Workstation, cloud portal, VPN, remote desktop, and their own management tool sessions. A 15-minute check before the assessment to verify all settings match the SSP can save you a finding. The best MSSPs I've worked alongside include session timeout verification in their pre-assessment review.
This page covers AC.L2-3.1.10 from NIST SP 800-171 Rev 2 (3.1.10). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.