Session termination is straightforward in concept but frequently overlooked in practice. If someone walks away from their unlocked laptop in your office with a CUI application open, that unattended session is a vulnerability. AC.L2-3.1.11 requires you to automatically lock or terminate that session after a defined period of inactivity. This is a relatively quick control to implement and demonstrate, which makes it one of the easier access control practices to satisfy. It pairs with AC.L2-3.1.10 (session lock) and IA.L2-3.5.1 (user identification) to protect against unattended access.
What the assessor is actually evaluating
The assessor wants to confirm three things. First, that you’ve thought about unattended sessions as a risk and defined an inactivity timeout that you believe is appropriate for your environment. Second, that you’ve actually configured that timeout on the systems and endpoints that handle CUI. Third, that you can show the configuration live and explain why you chose that specific timeout.
Most small contractors configure this once and forget about it, which is fine. The assessor isn’t looking for deep sophistication here. They’re checking that the control exists, it’s been deliberately set rather than relying on defaults, and you can articulate the rationale.
If you have workstations, laptops, and remote access systems all touching CUI, the timeout should be consistent across all of them. If different timeout values are needed for different systems (a shared lab machine vs. an engineer’s laptop), that’s defensible as long as it’s documented and intentional.
What a realistic SSP definition looks like
[Organization Name] configures automatic session termination on all systems and endpoints within the CUI boundary. Interactive user sessions are locked after 15 minutes of inactivity on workstations and 30 minutes on remote access solutions. All systems are configured to log out the user completely after 8 hours of continuous activity, regardless of inactivity, to prevent privilege creep from session persistence.
Session timeout settings are enforced via Group Policy (for on-premises endpoints) and Intune Compliance Policies (for cloud-managed devices). The CIO reviews timeout configurations semiannually as part of the system baseline audit to ensure they have not been modified or disabled.
Notice the specific numbers in that SSP. “15 minutes on workstations” and “30 minutes on remote access” is much more credible than “sessions are terminated after an appropriate inactivity period.” The assessor wants to see you’ve thought through the actual duration.
Also notice the reference to Group Policy and Intune. Naming your actual enforcement mechanism shows concrete implementation. You’ve actually deployed the control in your environment with specific tools, not just defined it in theory.
The semiannual review language matters too. It shows that timeout settings aren’t a set-and-forget configuration. Someone is actually verifying they’re still in place.
How to present your evidence
- Group Policy screenshot showing session timeout settings (for on-premises Windows)
- Intune Compliance Policy or device configuration profile showing inactivity timeout
- Remote access solution settings showing idle timeout (VPN, bastion host, RDP gateway)
- Evidence of regular review (e.g., quarterly or semiannual audit of baseline configs)
- If applicable, exception documentation for any systems with different timeouts and justification
Have these ready for the assessment:
Group Policy or Intune config screenshots. If you manage Windows endpoints via Group Policy, pull up the policy showing the session timeout. Screenshot it showing the exact setting. The same goes for Intune: pull up the Device Configuration profile or Compliance Policy that sets the inactivity timeout.
Live demo capability. Be prepared to lock a test account and let the timeout trigger on a live system. This is optional but impressive. If you can trigger a session lock after the configured timeout expires, the assessor will be satisfied immediately.
Your remote access timeout. If you have a VPN, RDP gateway, bastion host, or any other remote access solution, it should have an idle timeout configured. Have screenshots of that configuration ready.
Review evidence. If you conduct periodic reviews of baseline configurations (which is smart), include a recent review record showing that session timeout settings were checked and confirmed to be in place.
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
"We use Windows defaults." Windows defaults vary by OS version and can be overridden by users. The assessor wants to see deliberate configuration, not reliance on defaults. Even if your default is fine, configure it explicitly and document it.
Inconsistent timeouts across systems. If workstations have 15-minute timeouts but your file server and web server have 4-hour timeouts, that's inconsistent. Consistency matters. If you need different values for different system types, document the exceptions and the reasoning.
No evidence of review or verification. You configured it once and haven't touched it since. The assessor will ask how you know it's still in place, especially in a multi-system environment. Periodic verification (quarterly or semiannual) matters.
Timeout configured but users can disable it. If the policy is configured but users have local admin rights and can change it, it's not controlled. Either remove local admin from standard users, or use enforcement that prevents modification.
Explicit timeout values in your SSP. Screenshots showing the actual configuration in your identity and endpoint management tools. A brief, sensible explanation for why you chose those timeouts. If you can show a live test or a recent audit confirming settings are still in place, that's the checkbox closure. This is a straightforward practice and doesn't require elaborate evidence.
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 or MSSP likely manages endpoint configuration, including session timeout settings. Here’s how this typically divides:
What’s on you (the contractor):
- Defining the inactivity timeout duration in your SSP
- Approving the timeout values before they’re implemented
- Confirming that the timeout is appropriate for your business
What’s on the MSP:
- Configuring the timeout in Group Policy, Intune, or other endpoint management tools
- Verifying that the configuration applies to all in-scope endpoints
- Conducting periodic reviews to ensure the setting hasn’t been modified
If the assessor asks about this, you should be able to explain the timeout duration and why you chose it. Your MSP should be able to pull up the actual configuration.
Assessors will ask what your inactivity timeout is and expect you to know the exact number. Have it documented in your SSP and have the configuration ready to show. This practice is quick to verify if everything is in place and aligned. Misalignment between SSP and configuration is the main failure mode here.
Make sure your MSP knows this is being assessed. Send them your SSP language and ask them to confirm it's actually configured. If there's a gap (you said 15 minutes but they configured 30), that creates friction during the assessment. A quick 15-minute call before the assessment room eliminates that risk. The best MSPs proactively confirm this stuff before the assessment starts.
This page covers AC.L2-3.1.11 from NIST SP 800-171 Rev 2 (3.1.11). 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.