CMMC Level 2 Practice 3.13.9: Terminate network connections associated with communications sessions at the end of the

CMMC Level 2 Practice 3.13.9 requires you to automatically terminate network connections tied to user or device communication sessions when the session ends (for example, after logout or timeout) so stale sessions cannot be hijacked. Operationalize it by defining session-ending events, enforcing timeouts across remote access, web apps, and admin protocols, and retaining proof that disconnects occur as designed. (NIST SP 800-171 Rev. 2)

Key takeaways:

• Define what “session end” means for each access path (VPN, RDP/SSH, web apps, SaaS admin, privileged tools) and enforce termination consistently.
• Configure technical controls (timeouts, idle disconnects, token expiration, forced re-auth) and validate with logs and test results.
• Treat evidence as part of the control: settings exports, baselines, and sampled logs that show sessions closing as expected. (DoD CMMC Program Guidance)

“Terminate network connections associated with communications sessions at the end of the session” sounds simple until you enumerate how many sessions exist in a CUI environment: VPN tunnels, VDI sessions, bastion/privileged access sessions, SSH/RDP connections, web application sessions, API sessions, and even wireless re-auth behaviors. CMMC assessments tend to expose gaps where one channel is hardened (for example, VPN has an idle timeout) while another is left open (for example, RDP stays connected indefinitely on jump hosts).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this practice as a control design problem with measurable outcomes: (1) session termination rules are defined by system type and risk, (2) configurations enforce those rules, (3) monitoring shows sessions actually terminate, and (4) exceptions are explicitly approved with compensating controls. The requirement is mapped to NIST SP 800-171 Rev. 2 control 3.13.9 under CMMC Level 2, so you should document implementation in your SSP and be ready to demonstrate it during assessment. (NIST SP 800-171 Rev. 2) (DoD CMMC Program Guidance)

Regulatory text

Provided excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.9 (Terminate network connections associated with communications sessions at the end of the).” (NIST SP 800-171 Rev. 2) (DoD CMMC Program Guidance)

Operator interpretation of the excerpt: You must ensure that when a communications session ends, the underlying network connection does not remain open in a way that allows reuse, hijacking, or continued access. In practice, this means you define session end conditions (logout, idle timeout, absolute timeout, token expiration, disconnect events) and enforce technical settings so the session cannot persist silently. (NIST SP 800-171 Rev. 2)

Plain-English interpretation (what “good” looks like)

You meet cmmc level 2 practice 3.13.9: terminate network connections associated with communications sessions at the end of the requirement when:

• Users can’t keep “ghost sessions” alive after logout, closing a laptop lid, or walking away from a terminal.
• Remote access channels (VPN/VDI/bastion) drop idle sessions and require re-authentication.
• Web and administrative interfaces end sessions by expiring tokens/cookies and closing server-side sessions.
• You can prove it with configuration evidence and logs that show session teardown events. (NIST SP 800-171 Rev. 2)

Who it applies to

Entities: Defense contractors and other federal contractors handling CUI in scope for CMMC Level 2. (32 CFR Part 170)

Operational scope: Any system, service, or enclave that stores, processes, or transmits CUI, plus the infrastructure that grants access to that environment (identity providers, VPN, bastions, management planes). If a third party operates any of these components (for example, managed firewall/VPN, managed VDI, outsourced SOC), their service still has to support your session termination requirements, and you need evidence from them.

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

1) Build an in-scope session inventory (by access path)

Create a short register that answers: “What sessions exist that could access CUI?” Include:

• User remote access: VPN, ZTNA, VDI
• Admin access: bastion hosts, PAM tools, hypervisor consoles, network device management
• Application sessions: internal web apps, portals, ticketing systems that contain CUI, file sharing
• Protocol sessions: SSH, RDP, SMB sessions where applicable
• Cloud/SaaS admin sessions for services hosting CUI (if any)

Deliverable: “Session Inventory for CUI Environment” mapped to system owners. (NIST SP 800-171 Rev. 2)

2) Define “end of session” events and required behavior

Write a control standard that is unambiguous per session type:

• User-initiated end: logout / disconnect must terminate the session and underlying connection.
• Idle timeout: inactivity triggers disconnect and re-auth on reconnect.
• Absolute timeout: session ends after a maximum duration even if active.
• Auth lifecycle end: access tokens expire; refresh rules prevent indefinite extension.
• Network change / sleep / lock: define expected behavior for VPN/VDI reconnection.

Keep it crisp: a one-page “Session Termination Standard” is enough if it’s specific. Tie it to your SSP control narrative for 3.13.9. (NIST SP 800-171 Rev. 2)

3) Configure technical enforcement per system category

This is where assessments are won or lost. For each category, set and record the relevant controls:

Remote access (VPN/ZTNA/VDI)

• Enforce idle disconnect.
• Enforce maximum session duration.
• Force re-authentication after disconnect; avoid “silent reconnect” that restores the prior session context.
• If split tunneling exists (often it should not for CUI enclaves), document how session end is still enforced.

Administrative access (bastion/PAM/privileged consoles)

• Require session timeouts at the bastion layer, not only on downstream systems.
• Ensure RDP/SSH sessions close when the user exits; prevent “detached” sessions from persisting.
• If you record privileged sessions, ensure the recording system doesn’t keep sessions active after user exit.

Web applications

• Server-side session invalidation on logout (not only deleting a cookie).
• Token/cookie expiration and rotation.
• Idle timeout enforced both client-side and server-side.
• If SSO is used, define how IdP session duration and application session duration interact.

Endpoints

• Screen lock is related but not sufficient on its own. Confirm whether endpoint lock triggers disconnect for VPN/VDI where required, or document your design choice and compensating controls.

Deliverable: a configuration baseline (screenshots/exports) per system showing session timeout and termination settings. (NIST SP 800-171 Rev. 2)

4) Validate with testing that an assessor will accept

Run simple, repeatable tests:

• Start a VPN session, authenticate, then log out. Confirm the tunnel drops and cannot pass traffic.
• Leave a privileged RDP session idle. Confirm disconnect occurs and a new login is required.
• Log out of a CUI web portal. Attempt to reuse the prior browser session token; confirm access is denied.

Capture evidence: test scripts, timestamps, and resulting logs. Assessors favor tests tied to specific systems in your SSP boundary. (DoD CMMC Program Guidance)

5) Implement monitoring and recurring evidence capture

CMMC readiness often fails on “we configured it once” with no operational proof. Set up:

• Log collection for session start/stop events from VPN, bastion, IdP, and key applications.
• A lightweight monthly or quarterly evidence pull: configuration export plus a sampled log set that shows session teardown events.

If you use Daydream to run control operations, treat 3.13.9 as a recurring evidence workflow: request config exports from system owners and attach a log sample demonstrating session termination for each access path. (DoD CMMC Program Guidance)

6) Document exceptions and compensating controls

Some systems cannot enforce clean termination (legacy OT, specialized appliances). Handle it explicitly:

• Approved exception with scope, justification, and expiration date.
• Compensating controls: network segmentation, jump host only access, stronger monitoring, shorter credential lifetimes, or removal of direct interactive access.

Deliverable: exception register entries mapped back to 3.13.9. (NIST SP 800-171 Rev. 2)

Required evidence and artifacts to retain

Use this checklist to stay assessment-ready:

• SSP control narrative for 3.13.9: what systems are in scope and how session termination is enforced. (NIST SP 800-171 Rev. 2)
• Session Termination Standard (policy/standard): definitions of session end, timeout types, and responsibilities.
• System configuration evidence: screenshots or exports from VPN, IdP, PAM/bastion, key apps, and management interfaces showing timeout/termination settings.
• Test results: step-by-step validation records with dates, tester, system, and outcome.
• Logs: sampled session start/stop (connect/disconnect) records that corroborate settings.
• Exception register: documented exceptions with compensating controls and review cadence.
• Third party evidence (as applicable): attestation or configuration proof from managed service providers supporting session termination requirements.

Common exam/audit questions and hangups

Assessors and auditors repeatedly focus on:

• “Show me where sessions end for VPN and for admin access.” Expect them to separate user remote access from privileged pathways. (DoD CMMC Program Guidance)
• “What’s your definition of ‘end of session’?” If you can’t define it, you’ll struggle to prove it. (NIST SP 800-171 Rev. 2)
• “Is logout actually invalidating server-side sessions?” Web apps often fail here.
• “How do you know it keeps working?” They will ask for logs and evidence over time, not only a screenshot.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Relying only on workstation screen lock	Locking the screen may not drop VPN/VDI or terminate remote shells	Enforce disconnect at the remote access layer and confirm with logs
Only setting idle timeout, no absolute timeout	Long-lived active sessions can remain open indefinitely	Add maximum session duration where supported and document rationale where not
Web logout deletes cookies but keeps server session valid	Session reuse becomes possible	Implement server-side invalidation and verify with a token reuse test
No evidence beyond “we configured it”	CMMC requires demonstrable implementation	Schedule recurring evidence pulls and retain connect/disconnect logs (DoD CMMC Program Guidance)
Ignoring third party-managed access paths	Your boundary still depends on their controls	Add contract/security requirements and collect provider evidence

Risk implications (why operators care)

Session persistence creates a practical attack path: hijacked tokens, unattended terminals, and “stale tunnels” that allow lateral movement into CUI environments. The compliance risk is also straightforward: if you cannot demonstrate session termination across the boundary, you invite a finding under 3.13.9 and create knock-on scrutiny of related access control and audit logging practices. (NIST SP 800-171 Rev. 2) (DoD CMMC Program Guidance)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and standards)

• Build your in-scope session inventory for the CUI boundary.
• Publish a Session Termination Standard with definitions and owners.
• Identify “high-risk always-on” sessions (VPN, bastion, privileged admin consoles) for priority remediation. (NIST SP 800-171 Rev. 2)

Days 31–60 (configure and validate)

• Implement timeouts and termination settings on VPN/ZTNA, bastion/PAM, IdP, and top CUI applications.
• Run validation tests and capture logs for each access path.
• Open exception records for systems that cannot comply immediately, with compensating controls. (DoD CMMC Program Guidance)

Days 61–90 (operationalize evidence)

• Add recurring evidence capture: configuration exports plus sampled disconnect logs.
• Add monitoring alerts where feasible (for example, unusually long sessions or sessions without a clean teardown event).
• Update SSP language so system mapping, settings, and evidence align for assessors. (NIST SP 800-171 Rev. 2)

Frequently Asked Questions

Does this require a specific timeout value (for example, 15 minutes)?

The requirement does not provide a specific timeout value in the cited text. Set timeouts based on risk and system function, document the rationale, and apply them consistently across the CUI boundary. (NIST SP 800-171 Rev. 2)

If users close a browser tab without logging out, do we still need to terminate the session?

Yes, you should address non-logout endings through idle timeouts and token expiration so the session cannot persist indefinitely. Prove behavior with configuration evidence and a simple test. (NIST SP 800-171 Rev. 2)

Are VPN disconnects enough to satisfy 3.13.9?

VPN is usually only one access path. You also need session termination for admin protocols (RDP/SSH), bastion/PAM workflows, and web/application sessions that access CUI. (NIST SP 800-171 Rev. 2)

How do we handle shared admin accounts that keep sessions open on jump hosts?

Avoid shared accounts where possible and enforce session timeouts at the jump host or PAM layer so sessions terminate when the user is done. If a legacy constraint exists, document an exception with compensating controls and monitoring. (NIST SP 800-171 Rev. 2)

What evidence is most persuasive in a CMMC assessment?

A combination of (1) configuration exports/screenshots from the enforcing systems, (2) logs showing session start/stop events, and (3) a short test record showing the disconnect happens in practice. Map each artifact to your SSP narrative for 3.13.9. (DoD CMMC Program Guidance)

Our third party MSP manages the firewall/VPN. Can we inherit their controls?

You can rely on a third party’s operated control, but you still need evidence that their configuration meets your session termination requirements and that it applies to your CUI environment. Make it a contractual deliverable and collect it as recurring evidence. (32 CFR Part 170)