1Overview
AC.L2-3.1.11 requires that a user session end automatically after a condition the organization defines. It is often confused with session lock, but it is a different and stronger action: where the lock from 3.1.10 suspends a session and keeps it in memory behind a reauthentication prompt, termination ends the session entirely, closing it out rather than pausing it.
The distinction matters because a locked session is still a live session. Its processes continue, its network connections may persist, and its resources remain claimed under the user's identity, so a locked session left indefinitely is an open door that merely has a curtain drawn across it. Termination removes that standing exposure by ending the session after a defined condition, most commonly a period of inactivity longer than the lock threshold, or the end of a scheduled window. The condition is the organization's to set, and the control is satisfied when a condition is defined and the system actually ends the session when it is met.
Terminate (automatically) a user session after a defined condition.
The requirement leaves the condition open, because the appropriate trigger depends on the environment. It may be extended inactivity, a maximum session length, a time-of-day boundary, or a specific event. What the requirement fixes is that the session ends rather than merely locks, and that the ending is automatic rather than dependent on the user remembering to log off. The distinction from session lock is the single most important thing to understand about this control.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.11 into two objectives: define the condition that triggers termination, and automatically terminate the session when the condition occurs.
Conditions requiring a user session to terminate are defined. The organization has set the condition or conditions under which a session will be automatically ended.
A user session is automatically terminated after any of the defined conditions occur. The system ends the session when the condition is met, without relying on the user to act.
The two objectives are a definition and an enforced action. The frequent shortfall is treating this control as satisfied by session lock: a machine that locks but never ends the session meets 3.1.10 and not 3.1.11, and the assessor looks specifically for the session ending, not merely pausing.
3Failure Patterns
The failures center on the confusion with session lock and on the remote and application sessions where termination matters most and is configured least.
Session lock treated as termination
The most common failure is assuming that because machines lock, the session-termination requirement is met. Lock and termination are separate controls with separate objectives, and a locked session is still active. Satisfying 3.1.11 requires that the session actually ends under the defined condition, which the lock configuration does not do on its own.
Remote sessions that never disconnect
Remote desktop and VPN sessions left idle are a primary target of this control, because an abandoned remote session is a live foothold into the environment. Where idle-disconnect and maximum-session settings are not configured, these sessions persist far beyond their use, and the control fails on exactly the connections that most warrant ending.
Application and cloud sessions with no timeout
Sessions to CUI-bearing applications and cloud services often remain valid long after the user has stopped working, because the application or identity provider was never set to expire them. Objective [b] extends to these sessions, and a browser tab that stays authenticated for days is the same standing exposure in a different form.
The condition defined but not enforced
A policy may state that sessions terminate after a period while no system setting actually enforces it, satisfying objective [a] on paper and failing objective [b] in practice. As with the other configuration controls, the written condition and the enforced behavior have to match.
4Ownership
This is an IT-owned technical control, and its main demand is covering the several places sessions exist: interactive, remote, and application, rather than only the desktop.
| Role | Responsibility for this control |
|---|---|
| IT lead or system administrator | Defines the termination conditions and configures automatic session ending across interactive, remote, and application sessions. Owns the configuration evidence. |
| Security or compliance lead | Confirms the defined conditions are meaningful and that termination, not merely locking, is enforced on the sessions that reach CUI. |
| Application and cloud administrators | Set session-expiration and idle-timeout policies in the CUI-bearing applications and cloud services, which are outside the operating-system session settings. |
| Program lead | Includes session-termination coverage in periodic review, particularly for new remote access paths and applications, and retains the record. |
5Tooling
The control is configured across the operating system, the remote access services, and the applications, each of which manages its own sessions. The work is covering all three rather than only the desktop.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [b] interactive | Group Policy idle and logoff settings, scheduled logoff scripts | Ending interactive sessions after inactivity or at a defined time, beyond the lock that only suspends them. |
| [b] remote | Remote Desktop session time limits, VPN idle-session and maximum-session settings | Disconnecting and ending idle and long-running remote sessions, closing the abandoned-foothold path. |
| [b] cloud and application | Entra ID sign-in frequency and session controls, application session timeouts | Expiring cloud and application sessions so authentication does not persist indefinitely on CUI-bearing services. |
| Verification | Session and sign-in logs | Records showing sessions ending under the defined conditions, distinguishing termination from a lock event. |
The caveat is scope across session types. The operating-system settings alone leave the remote and application sessions untouched, and those are frequently the more exposed. The assessor tests objective [b] by letting a session meet the defined condition and observing whether it ends, on remote and application sessions as well as interactive ones, so the configuration has to reach each place a session lives.
6Evidence
The satisfied version of 3.1.11 shows the defined conditions and demonstrates sessions actually ending across the session types.
| Evidence | What it demonstrates |
|---|---|
| Session-termination policy | Objective [a]. The defined conditions under which sessions are automatically ended. |
| Interactive session configuration | Objective [b]. Idle logoff or scheduled termination settings on workstations. |
| Remote session configuration | Objective [b]. Remote desktop and VPN idle-disconnect and maximum-session settings. |
| Cloud and application session settings | Objective [b]. Sign-in frequency and application timeout policies on CUI-bearing services. |
| Session logs showing termination | Objective [b]. Records of sessions ending under the defined conditions, distinct from lock events. |
The evidence should distinguish termination from locking, because that difference is the essence of the control, and it should span the interactive, remote, and application sessions rather than only the desktop. Logs that show a session actually ending under a defined condition are the clearest demonstration, particularly for the remote and cloud sessions where the standing exposure is greatest.
The remote and cloud sessions are where it matters
Ending interactive sessions is routine; the exposure that this control really addresses lives in the remote desktop left connected and the cloud application still authenticated days later. Configuring automatic termination across every place a session lives, and confirming it ends rather than merely locks, is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.11. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.11[a] and 3.1.11[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov