SC-10: Network Disconnect

Quick-reference card

What this control requires

SC-10 requires organizations to terminate network connections at the end of a communications session or after a defined period of inactivity. This control addresses a foundational gap in how systems manage persistent connections, ensuring that idle or abandoned sessions don’t become entry points for unauthorized access.

In practice, this means de-allocating TCP/IP address or port pairs at the operating system level and releasing networking assignments at the application level when multiple application sessions share a single OS-level connection. Organizations must define specific inactivity timeouts, and those timeouts can vary by the type of network access or by specific network connections. The goal is to prevent stale sessions from lingering in a state where they could be hijacked or exploited.

Without enforced disconnection policies, sessions that remain open after a user walks away or finishes work create an unnecessary attack surface. This control applies to both internal and external networks, covering remote access connections, VPN tunnels, and application-layer sessions alike. You can explore the full System and Communications Protection family for additional controls that work alongside SC-10 to protect network integrity.

Why it matters

Organizations that fail to enforce automatic network disconnection face direct compliance risk during federal audits and third-party assessments. Auditors specifically look for documented inactivity timeout policies and evidence that those policies are enforced at both the operating system and application layers.

The compliance exposure goes beyond a single audit finding. Systems without automatic session termination can trigger cascading deficiencies across related controls, particularly AC-12 session termination requirements. You can review the full NIST SP 800-53 framework to understand how session management controls interrelate. A gap in SC-10 often signals broader weaknesses in session management that auditors flag as systemic.

Idle sessions also represent a persistent operational risk. When connections remain active after a user has finished work, those sessions sit open for anyone with physical or network access to the endpoint. This risk multiplies in environments with shared workstations, remote access infrastructure, or high-turnover personnel.

For organizations pursuing or maintaining FedRAMP authorization, SC-10 is required at both the MODERATE and HIGH baselines within the System and Communications Protection family. Failing to demonstrate enforced network disconnection policies can delay authorization timelines and trigger remediation requirements in Plans of Action and Milestones (POA&Ms).

What attackers exploit

• Idle VPN or remote access sessions that remain authenticated after a user disconnects from the network physically but not logically
• Application-layer sessions where TCP/IP port pairs aren’t de-allocated, allowing session tokens to be reused
• Shared workstation environments where a previous user’s session persists after they walk away
• Long-lived database or administrative console sessions that lack inactivity timeouts
• Network connections that survive sleep or hibernate states on endpoints without proper session termination hooks

How to implement

The biggest implementation challenge with SC-10 isn’t defining timeout values. It’s ensuring consistent enforcement across every network connection type in your environment, from operating system-level TCP/IP sessions to application-layer persistent connections.

For your organization

Start by inventorying every connection type in your environment that requires a disconnection policy. This inventory should cover VPN tunnels, remote desktop sessions, SSH connections, database connections, web application sessions, and API connections with persistent authentication.

Define inactivity timeout values for each connection type based on risk. High-privilege administrative sessions should have shorter timeouts (15 minutes or less), while general user sessions can tolerate slightly longer periods. Document these values in your system and communications protection policy with justification for each threshold.

Configure operating system-level session timeouts to de-allocate TCP/IP address and port pairs after the defined inactivity period. On Windows systems, this involves Group Policy settings for idle session limits. On Linux systems, configure TMOUT variables and SSH ClientAliveInterval/ClientAliveCountMax parameters. These settings should be enforced through configuration management tools rather than left to individual system administrators.

At the application layer, configure session timeout settings independently. Many applications maintain their own session state even after the OS-level connection terminates. Web applications should implement both idle timeouts and absolute session timeouts. Database connections should use connection pooling with maximum idle time settings.

Implement device lock controls (AC-11) alongside network disconnection to create layered session protection. Device lock handles the local access vector, while SC-10 handles the network access vector. Together, they close both paths an attacker could use to hijack an abandoned session.

Test your configurations by validating that sessions terminate after the defined inactivity period. Automated testing should verify that TCP/IP port pairs are released, application sessions are invalidated, and re-authentication is required after timeout. Document test results as evidence for your next audit.

For your vendors

When assessing vendor compliance with SC-10, focus your questionnaire on specifics rather than generic policy questions. Ask vendors to provide their documented inactivity timeout values for each connection type they support, along with evidence that those timeouts are enforced through technical controls rather than just written policy.

Request system configuration documentation showing how network disconnection is implemented at both the operating system and application layers. Vendors should be able to demonstrate that TCP/IP address and port pair de-allocation occurs automatically, not just that sessions display a timeout warning.

Review vendor audit records for evidence that session termination events are logged and monitored. The logs should capture when a session was terminated due to inactivity, what connection type was involved, and whether the termination was successful. Gaps in session termination logging are a red flag.

Ask whether the vendor’s inactivity timeout values vary by connection type and risk level. A vendor that applies a single blanket timeout across all connection types may not be managing this control with sufficient granularity. Administrative and privileged sessions should have demonstrably shorter timeout periods.

Verify that the vendor’s NIST SP 800-53 compliance program addresses SC-10 as part of a broader session management strategy that includes related controls like AC-12 and SC-23. Isolated implementation of SC-10 without integration into the vendor’s overall session management architecture suggests a checkbox approach rather than genuine security maturity.

Evidence examples

Cross-framework mapping

Related controls

• AC-17 — Remote Access: SC-10 enforces session termination for the network connections that AC-17 governs. Remote access connections are among the highest-risk connection types requiring enforced inactivity timeouts because they extend network sessions beyond the physical security boundary.
• SC-23 — Session Authenticity: SC-23 protects session integrity during active communications, while SC-10 ensures those sessions are terminated when they become idle. Together, these controls prevent both session hijacking during use and session exploitation after abandonment.

Frequently asked questions

What is NIST SP 800-53 SC-10?

SC-10 is a System and Communications Protection control that requires organizations to terminate network connections at the end of a session or after a defined inactivity timeout. It applies at both MODERATE and HIGH baselines and covers the de-allocation of TCP/IP address and port pairs at the operating system level. Organizations must define specific inactivity periods that can vary by connection type or network access category.

What happens if SC-10 is not implemented?

Without SC-10, idle network connections remain active indefinitely, creating opportunities for unauthorized access through abandoned sessions. Auditors treat missing network disconnection controls as a compliance gap that can cascade into findings against related controls like AC-12 and SC-23. Organizations pursuing FedRAMP authorization at the MODERATE or HIGH baseline will face remediation requirements and potential delays in their authorization timeline. Review the broader System and Communications Protection controls for context on how SC-10 fits into the overall protection strategy.

How do you audit SC-10?

Auditing SC-10 starts with reviewing the system and communications protection policy for documented inactivity timeout values and verifying that those values are enforced through system configuration settings. Auditors examine system audit records to confirm that session termination events are logged, including the connection type and whether termination occurred due to inactivity timeout. Testing typically involves validating that TCP/IP port pairs are released and application-layer sessions are invalidated after the defined inactivity period.

What is the difference between SC-10 and AC-12?

SC-10 focuses on terminating the underlying network connection, including de-allocating TCP/IP address and port pairs at the operating system level, while AC-12 addresses session termination at the application and user session level. SC-10 operates on the network transport layer to ensure connections don’t persist after inactivity, whereas AC-12 manages user-facing session behaviors like displaying logout messages and requiring re-authentication. Both controls work together to provide layered session management across network and application layers.