SC-10: Network Disconnect

To meet the sc-10: network disconnect requirement, you must configure systems to terminate the network connection tied to a communications session either when the session ends or after a defined period of inactivity ¹. Operationalize it by setting timeouts, forcing session teardown, and retaining configuration and test evidence that proves disconnect behavior across key protocols and remote access paths.

Key takeaways:

• Define an inactivity timeout value (the SC-10 organization-defined parameter) and implement it consistently across session-based services.
• Enforce both “end-of-session” disconnects and “idle timeout” disconnects for remote access, admin interfaces, and high-risk applications.
• Retain config baselines, change records, and test results that demonstrate connections terminate as required.

SC-10 is deceptively simple: shut down network connections when a session is over or when the user stops interacting. In practice, many environments fail SC-10 because “session end” is ambiguous across protocols, and idle timeouts vary across VPNs, load balancers, reverse proxies, identity providers, application frameworks, and database clients. Assessors also expect you to define the inactivity threshold explicitly, apply it consistently, and prove it with evidence.

This requirement matters most where long-lived sessions create a real attack surface: remote administrative access, privileged web consoles, virtual desktops, bastion hosts, API management planes, and business applications that carry federal or other regulated data. A lingering authenticated session can enable unauthorized use after a user walks away, a laptop sleeps and reconnects, or a token is replayed.

This page translates SC-10 into an operator-ready implementation checklist: scope what “communications sessions” means in your environment, pick and document an inactivity threshold, enforce disconnect behavior across layers, and collect the artifacts auditors ask for. If you manage third parties that operate parts of your environment, you also need contractual and technical verification that their session handling meets your SC-10 parameters.

Regulatory text

Requirement (verbatim): “Terminate the network connection associated with a communications session at the end of the session or after {{ insert: param, sc-10_odp }} of inactivity.” ¹

What the operator must do

1. Define the organization-defined parameter (ODP) for inactivity (the sc-10_odp value). SC-10 is incomplete until you pick and approve a timeout value.
2. Implement technical controls that terminate the network connection associated with the session:
   • At end of session (logout, session close, disconnect event).
   • After inactivity (idle timeout, no keyboard/mouse, no requests, no keep-alives that mask inactivity).
3. Prove it works with configuration evidence and testing results for the systems in scope.

Plain-English interpretation of the requirement

SC-10 means: authenticated or otherwise session-based connections should not hang around indefinitely. If the session ends, the underlying connection should close. If the user stops using the session, your systems should time it out and drop the connection after your defined idle period. ¹

Two practical clarifications you should document up front:

• “Session” is broader than a website login. It includes VPN tunnels, SSH sessions, VDI/RDP sessions, admin consoles, and other persistent communications contexts.
• “Network connection” points to real teardown, not just an app message. Auditors often look for actual disconnect behavior (e.g., tunnel drops, socket closes, re-auth required).

Who it applies to (entity and operational context)

SC-10 is a NIST SP 800-53 control used in federal information systems and contractor systems handling federal data ². Practically, it applies wherever you are implementing or mapping to NIST 800-53 (including in programs that inherit it through customer requirements).

Apply SC-10 to these operational contexts first (typical assessment focus):

• Remote access paths: VPN, ZTNA, VDI, bastion/jump hosts.
• Privileged access: admin portals, cloud consoles, hypervisors, network device management, CI/CD admin.
• Session-based applications handling regulated data: web apps, internal tools, thick clients that keep connections open.
• APIs and service-to-service sessions: long-lived tokens and connections where “idle” can be masked by automated retries or keep-alives.

If a third party hosts or operates any of the above for you, treat their session timeout behavior as in-scope. Your compliance posture depends on their configuration and evidence, not only their policy statements.

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

Step 1: Set your SC-10 parameter (the inactivity threshold)

• Pick an inactivity threshold that matches your risk tolerance and operational needs. Document it as the official sc-10_odp value and get it approved through your control governance process. ¹
• Define “inactivity” per session type:
  • Web: no HTTP requests from the client.
  • VPN/VDI: no user activity (and decide how to treat background keep-alives).
  • SSH: no input/output activity.
• Record any exceptions (for example, machine-to-machine sessions where disconnect breaks availability). Keep exceptions narrow and justified.

Step 2: Inventory session-based entry points and owners

Build a scoped list that ties each session type to a technical owner and a control owner:

• VPN/remote access platform
• IdP/SSO session settings
• Reverse proxy / WAF / load balancer session persistence
• Application session management (framework and config)
• Admin consoles (cloud provider consoles, SaaS admin portals)
• Bastion hosts and privileged access tooling

A fast way to do this is to start from your system boundary diagrams and enumerate “interactive sessions” and “persistent tunnels.”

Step 3: Implement disconnect controls at the right layer(s)

You often need controls in multiple layers because a timeout in the app may not drop the underlying connection, and a network-layer drop may not invalidate an app session.

Use this implementation matrix to avoid gaps:

Session type	Enforce “end of session”	Enforce idle timeout	Where to configure	What to verify
VPN / ZTNA	Tunnel disconnect on logout/disconnect	Idle tunnel timeout	VPN/ZTNA policy	Tunnel drops; re-auth required
Web apps	Server-side session invalidation	Server session timeout + token expiry	App + IdP	Session cookie/token rejected after idle
Admin consoles	Logout terminates session	Inactivity logout	SaaS/IaaS settings	Admin UI forces re-login
SSH / bastion	Session close	Idle timeout / keepalive limits	SSHD + bastion policy	Connection closes after idle
VDI/RDP	User disconnect ends session	Idle disconnect	VDI broker policy	Session terminates; reconnection requires auth

Step 4: Align identity/session settings with SC-10

If your IdP issues tokens or sessions that outlive the application timeout, users may still be “silently” re-authenticated. Map SC-10 to:

• IdP session lifetime / idle timeout
• Refresh token policies
• Step-up authentication rules for privileged apps

Document how IdP behavior supports connection termination expectations, or where compensating controls exist.

Step 5: Validate with repeatable tests

Create a small, repeatable test script per session type:

• Start session.
• Authenticate.
• Stop activity.
• Observe timeout behavior.
• Confirm the connection is terminated and re-authentication is required.

Capture evidence (screenshots, logs, command output) and store it with the control record.

Step 6: Operationalize (change control + monitoring)

• Add SC-10 checks to build/release standards for apps (session timeout and logout behavior as required settings).
• Monitor for drift:
  • Config changes to VPN/IdP/app session parameters.
  • New apps exposed externally without approved session settings.
• Tie recurring evidence to a calendar and to system changes. The most common SC-10 failure is “we set it once,” then it drifts.

Step 7: Map the requirement to an owner and recurring artifacts

Make SC-10 assessable by design: assign a control owner, list systems in scope, and define what evidence appears every cycle. This aligns with the practical control recommendation to map SC-10 to an owner, procedure, and recurring evidence artifacts ¹. Daydream can track this mapping and evidence cadence so the control stays audit-ready without rebuilding spreadsheets every assessment.

Required evidence and artifacts to retain

Auditors usually want proof in three categories: governance, configuration, and operation.

Governance

• Approved SC-10 parameter for inactivity (sc-10_odp) and rationale ¹
• SC-10 control narrative: scope, session types covered, exceptions and compensating controls
• Control owner assignment and operating procedure

Configuration

• VPN/ZTNA policy exports showing idle timeout and disconnect behavior
• IdP session policy configuration exports
• App config snippets (server session timeout, token/session settings)
• Bastion/SSH configuration demonstrating idle disconnect settings
• Change tickets or config management records for the above

Operational/test evidence

• Test cases and results showing disconnect after inactivity and at end-of-session
• Logs showing session timeout events (where available)
• Evidence of periodic review (for example, config attestation or drift detection outputs)

Common exam/audit questions and hangups

Use these as your pre-audit checklist:

1. “What is your defined inactivity threshold?” If you cannot state it clearly and show approval, you will struggle on SC-10. ¹
2. “Show me where it’s configured for remote access and admin access.” Assessors often start with VPN and privileged pathways.
3. “Does logout really terminate the connection?” Many apps invalidate a session but keep sockets alive via intermediaries. Be ready to demonstrate.
4. “How do you prevent drift?” A one-time screenshot is weak evidence. Show change control and periodic verification.
5. “What about third parties?” Expect questions on outsourced SOC tools, managed VDI, managed VPN, SaaS admin consoles, and hosted apps.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating SC-10 as “screen lock.” Screen lock helps but does not terminate network sessions. Keep SC-10 focused on session disconnect behavior. ¹
• Mistake: Only setting an application timeout. If the IdP refreshes tokens automatically, users may remain effectively authenticated. Align IdP and app policies.
• Mistake: Counting keep-alives as “activity.” Some platforms treat any packet as activity. Define inactivity in a way that reflects user or application behavior, then configure accordingly.
• Mistake: Ignoring privileged tools. Cloud consoles, hypervisor UIs, and network device management sessions are frequent blind spots.
• Mistake: No evidence standard. Decide upfront what constitutes acceptable proof (config export + test result) and collect it consistently.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement examples.

From a risk perspective, weak session termination increases the chance that an unauthorized person or process can reuse an existing session, especially on shared devices, remote endpoints, or where tokens persist. SC-10 reduces exposure from unattended sessions and stale connections by forcing re-authentication and dropping lingering connections. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and parameters)

• Define and approve the sc-10_odp inactivity threshold and the definition of “inactivity” by session type. ¹
• Inventory in-scope session types and systems; identify owners.
• Select evidence standards (what screenshots/logs/exports are acceptable).
• Implement quick wins on highest-risk paths: VPN/ZTNA and bastion/jump hosts.

Days 31–60 (implement consistently and document)

• Roll out standardized session settings across IdP, remote access, and privileged consoles.
• Update app engineering standards for session management (timeouts, logout behavior).
• Write the SC-10 procedure: how settings are approved, changed, and verified.
• Run and record validation tests for each major session type.

Days 61–90 (make it durable)

• Add drift checks: alerts or periodic attestations for key timeout settings.
• Integrate SC-10 evidence collection into your assessment calendar and change management.
• Extend to remaining applications and third-party operated components; require configuration evidence from third parties where applicable.
• Centralize control mapping, evidence requests, and periodic reminders in a system of record (Daydream fits well here) to keep SC-10 continuously assessable.

Frequently Asked Questions

What counts as a “communications session” for SC-10?

Treat it as any interactive or authenticated connection that stays established over time, including VPN, SSH, VDI/RDP, web app sessions, and admin portals. Document your scoped interpretation and apply it consistently across the system boundary ².

Do I have to disconnect immediately at the end of a session?

You must terminate the network connection associated with the session when the session ends, such as on logout or disconnect action ¹. If your architecture keeps connections alive after logout, add controls to close them or justify a compensating control and test it.

How do I pick the inactivity timeout value (sc-10_odp)?

SC-10 requires an organization-defined inactivity period, so pick a value that matches your risk tolerance and operational constraints, then approve and document it ¹. Auditors care less about the specific number than about consistency, rationale, and proof of enforcement.

If my IdP has a session timeout, is that enough for SC-10?

Often no. IdP timeouts help, but the control is about terminating the network connection associated with the session after inactivity or session end ¹. You typically need app-layer timeouts and remote access platform timeouts aligned with IdP settings.

How should we handle third parties that run parts of our environment?

Treat third-party hosted or managed session services as in-scope and require configuration evidence and test results that show disconnect behavior meets your sc-10_odp parameter ². Contract language alone is weak without technical verification.

What evidence is most persuasive in an audit?

A combination of approved parameter documentation, exported configuration showing timeout/disconnect settings, and a repeatable test record that demonstrates the connection drops after inactivity or logout ¹. Evidence tied to change records strengthens “operating effectiveness.”

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5