Session lock and session termination are related but different. 3.1.10 protects an unattended active session after inactivity; 3.1.11 ends sessions automatically after defined conditions.
For a small defense contractor, the useful test is whether the organization can show how the requirement applies inside the defined FCI/CUI boundary, who operates it, and what current evidence proves it is working.
The rule in plain English
For 3.1.10, evidence is usually endpoint, VDI, application, or policy configuration showing the inactivity lock and pattern-hiding display. For 3.1.11, the contractor should define the conditions under which sessions terminate.
The two controls can live at different layers: a workstation may lock after inactivity while a VPN or web session has a separate lifetime or disconnect rule.
How to implement it without overbuilding
Document which platforms enforce each control and where the setting is centralized. Cover exceptions such as shop-floor terminals, kiosks, jump boxes, or machines that cannot use the standard endpoint policy.
Choose termination conditions that fit actual operations and can be demonstrated. Avoid inventing a universal timeout NIST did not prescribe.
What evidence to keep
Keep configuration exports, policy screenshots, device-compliance reports, VPN/application session settings, exception records, and test results.
Testing one representative endpoint or remote session can make the evidence much stronger than policy text alone.
Where teams get into trouble
Teams often show a Windows screen-lock policy and assume it proves every session rule. Another mistake is leaving excluded devices undocumented.
Small-contractor walkthrough
A workstation locks after inactivity, but the VPN remains connected for many hours and a browser session persists overnight. The contractor should document which layer implements session lock and which layers terminate sessions under defined conditions.
- List session types in scope.
- Define lock settings.
- Define termination conditions.
- Document exceptions.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: list session types in scope; define lock settings; define termination conditions; and document exceptions. Assign an owner and an evidence location to each decision.
Manual deep review: test lock and termination across more than the desktop
3.1.10 protects an active session when a user is temporarily away. The organization defines an inactivity period, the system initiates a lock after that period, and the lock conceals previously visible information with a pattern-hiding display. A decorative screensaver that does not require reauthentication is not the same control. 3.1.11 instead ends a user session automatically after a defined condition. The termination condition can differ from the inactivity threshold used for locking.
Do not stop at Windows Group Policy. CUI-bearing sessions can persist in workstations, VDI, VPN, RDP gateways, web applications, cloud services, privileged-access systems, engineering applications, and administrative consoles. Build a session matrix showing which platform implements lock, which implements termination, the controlling setting, and any exception. A workstation can lock correctly while the VPN tunnel or cloud session remains alive for many hours.
For 3.1.10, open representative non-sensitive test content, allow the inactivity period to expire, confirm the lock occurs, confirm the prior display is concealed, and verify reauthentication is required. For 3.1.11, allow a representative remote or application session to meet the defined termination condition and confirm it actually ends rather than merely locks.
Shop-floor terminals, kiosks, test stands, or monitoring consoles that cannot use the standard policy need an explicit architecture decision. Document why the normal setting is unsuitable, what information can be exposed, who can physically reach the system, and what alternate safeguards reduce the risk. An undocumented permanent exception is not a substitute for implementing the outcome.
- Defined inactivity period and lock configuration.
- Pattern-hiding evidence.
- Defined termination conditions.
- VPN/VDI/application session settings.
- Exception and test records.
Manual assessment cross-check
Test one endpoint session and one remote or cloud session so both lock and termination are observed outside a desktop-only example.
Use CMMC Session Lock and Session Termination: What Counts as Evidence (3.1.10–3.1.11) as an operating guide, not as a substitute for the controlling source. Before publication or assessment use, re-open the current NIST SP 800-171 Rev. 2 requirement, the corresponding NIST SP 800-171A assessment objectives, and the DoD CMMC Level 2 Assessment Guide. Confirm that every mandatory statement on the page maps to those sources or to a clearly labeled organizational implementation choice.
Additional objective-level implementation notes
Do not invent a universal 15-minute lock or termination value. The organization defines the inactivity period for session lock and the conditions for automatic termination, then implements those values. Record them by session class because workstation inactivity, VPN idle time, VDI duration, privileged sessions, and cloud application sign-in frequency may be controlled by different technologies.
During testing, distinguish a locked session from a terminated one. A lock preserves the session but hides content and requires reauthentication; termination ends the session under the defined condition. Capture the configured value and the observed result for at least one interactive session and one remote or application session so the evidence does not stop at the easiest desktop example.
Final manual spot check
For a final spot check, test two session types with a stopwatch or timestamped observation: one interactive endpoint session and one remote, VDI, VPN, or cloud session. Record the configured lock or termination condition and the observed result. If the remote session remains active after the local workstation locks, document which separate control ends that session. This prevents a correct desktop policy from hiding a persistent authenticated session elsewhere in the CUI workflow.
One more edge case to verify
Where specialized terminals need different behavior, record the system class, approved exception, alternate safeguard, and review owner instead of silently leaving the standard policy unenforced.
A short working check
- ✓List session types in scope.
- ✓Define lock settings.
- ✓Define termination conditions.
- ✓Document exceptions.
- ✓Export centralized policies.
- ✓Test representative sessions.
Common questions
Is a 15-minute lock mandatory?
3.1.10 requires session lock after inactivity but does not state one universal 15-minute value.
Is locking the same as logging out?
No. A lock protects an active session; termination ends it.
Do VPN sessions count?
Remote and network sessions can be relevant, especially for termination conditions.
Can an assessor ask to see it work?
Yes. Assessment methods can include testing, so be ready to demonstrate representative settings.
Can lock and termination have different conditions?
Yes. They are different outcomes. Define the inactivity period for lock and the conditions for automatic termination, then implement and evidence each.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
