3.13.9 — Kill Idle Network Connections

The One-Liner

An idle network connection is a session waiting to be hijacked. If nobody’s using it, kill it.

What It Says

Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.

What It Actually Means

Network connections don’t stay open forever. Define timeout periods and enforce them:

• VPN sessions — 1 hour of inactivity (common standard)
• SSH connections — 15-30 minutes idle
• Database connections — 15 minutes idle
• Web application sessions — defined by the application (see also 3.1.11)
• Firewall session table — timeout configured per protocol

This is the network layer complement to session termination (3.1.11). Where 3.1.11 handles application-level session termination, this handles the underlying network connection.

The assessor will check: after a VPN user goes idle, does the connection eventually drop? Or does it stay open for days?

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are conditions for terminating network connections defined?	Documented timeout values for VPN, SSH, database, and other connection types
2	Are network connections terminated after the defined conditions?	Connections actually drop after idle timeout — demonstrated live

---

What to Have Ready on Assessment Day

Documents they’ll review: System and communications protection policy; system security plan; system configuration settings showing session timeouts; network device configurations

People they’ll talk to: System or network administrators; personnel with information security responsibilities

Live demos they’ll ask for: Network session timeout mechanisms; attempt to maintain idle connection beyond timeout

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What are your defined session timeouts for VPN, SSH, and other connections?”
• “Show me the VPN server configuration for idle timeout.”
• “Leave a session idle — show me it disconnects after the timeout.”
• “Are database connection timeouts configured?”
• “How do you handle users who complain about being disconnected?”

Real-World Example

A contractor configures: VPN idle timeout at 60 minutes (Always On VPN policy), SSH timeout at 15 minutes (sshd_config: ClientAliveInterval 900, ClientAliveCountMax 0), RDP timeout at 30 minutes (GPO). The firewall session table has protocol-specific timeouts: TCP established 3600s, TCP half-open 60s, UDP 30s. The assessor tests by establishing a VPN connection, leaving it idle, and confirming it disconnects after 60 minutes.

---

Where Companies Trip Up

No timeouts. Connections stay open until the user manually disconnects. Some never do.

VPN timeout too long. 8-hour timeout means an abandoned connection stays open all day. 1 hour is reasonable.

Application timeouts only. The web app session expires but the underlying VPN/network connection stays open. Both layers need timeouts.

Users bypass timeouts. Keep-alive scripts prevent idle disconnect. Block or detect these.

---

How to Talk About This

To a CEO or Board

Network connections timeout automatically after inactivity. No sessions linger unused.

To an Engineering Team

VPN idle: 60 min. SSH: 15 min. RDP: 30 min via GPO. Firewall session table: TCP 3600s, UDP 30s. All timeouts enforced server-side — users can’t override.

---

Connected Requirements

Requirement	Why it matters here
3.1.11 — End the Session	Application-level session termination that complements network timeouts
3.1.12 — Eyes on Remote Access	Remote sessions that need timeout enforcement

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: SC.L2-3.13.9 | SPRS Weight: 1 point | POA&M Eligible: Yes