What SC-10 network disconnect requires and why assessors still test it
SC-10 requires the system to terminate the network connection for a communications session at the end of the session or after a defined period of inactivity. It is a base control in the System and Communications Protection family, and SP 800-53B assigns it to the moderate and high baselines. Your assessor or contract is probably asking for it because an abandoned network session is a standing opening: a connection left open on a shared workstation, a jump host or an administrative console can be reused by someone who never authenticated. The control is about the network connection itself, so the system must actually close the underlying session, not merely show a screen.
SC-10 is easy to confuse with the AC family. AC session lock and session termination act on the user: a locked screen or an ended logon session that requires re-authentication. SC-10 acts on the communications path between endpoints, so a session can be locked at the user level while its network connection stays open, which is the gap the control closes. Keep the two apart in your system security plan and in your evidence, or an assessor will ask which control your evidence is actually answering. The control's related items in the Release 5.2.0 catalog are AC-17 and SC-23, which is a useful check when you map ownership.
The main difficulty is the organization-defined parameter. SC-10 has one parameter, and it is the inactivity period (and the conditions for ending a session) that you must define. Assessors will not accept the control as met until that value is written down, approved and applied consistently across the components that carry the session. Confirm the value with your authorizing official or policy owner, then check the configuration of each relevant component: the firewall or proxy idle timeouts, the load balancer, the VPN concentrator, the SSH server and the application server. Set these to match your defined value, and retain the configuration files and change records as the examine evidence that SP 800-53A expects.
Which systems, connections and teams fall under SC-10 scope
SC-10 applies wherever a network connection stays open between a user, service or device and a system. The sessions that matter most are the ones that outlive the user's attention, and the timeout for each one is often owned by a different team at a different layer.
Web application sessions
Browser sessions to customer portals, internal dashboards and back-office tools keep TCP or TLS connections open while idle. Check whether the application, the reverse proxy and the load balancer each enforce an idle limit, and whether the shortest one actually closes the network connection rather than only expiring a cookie. Assessors will look for the defined period in the system security documentation and the matching setting in configuration.
Remote administration channels
SSH, RDP and console sessions to servers and network devices are the sessions most often left open by administrators. Confirm which team sets the idle timeout on jump hosts, bastions and the target systems, and whether a disconnect is logged in the system audit records that an assessor can examine. Privileged sessions usually need a shorter defined period than general user traffic.
API and service-to-service connections
Long-lived API connections, message brokers and gateway keep-alives can hold sessions open for days if no one sets a limit. Ask the platform team which connections are persistent by design and which should terminate after inactivity. Document exceptions for batch or streaming workloads, because an unexplained exception is one of the first things an assessor will question.
Database connection pools
Application connection pools and direct database sessions for administrators can remain open after the user has gone. Check the pool's idle timeout, the database server's session limit and any firewall state timeout, since these three settings can disagree. The team that owns the database usually owns the server side, while the application team owns the pool.
VPN and virtual desktop sessions
Remote access tunnels and virtual desktop sessions are a common gap because the endpoint, the gateway and the desktop broker each keep their own session state. Decide which layer is the authoritative point for terminating the network connection, and confirm that a disconnect at one layer tears down the session at the others. Ask the remote access owner for the configured value and test it on a real disconnect.
Layer where the control is enforced
The enforcement point changes the work. Application timeouts are easiest to explain but may leave the transport open, load balancers and firewalls can close idle state without notifying the application, and endpoint policies cover only managed devices. Choose the layer or layers deliberately, record the choice in the system security plan, and confirm that the baseline selection and any FedRAMP class you operate under set the expected level of evidence.
How an assessor tests SC-10 under SP 800-53A
This table breaks down the single SP 800-53A determination statement for SC-10 by assessment method, the objects an assessor examines, and the evidence to prepare. Read it as a checklist: each row names what the assessor looks for and where timeout settings most often fail to match the documented requirement.
| Assessment element | What the assessor does | Evidence to prepare | Where it usually fails |
|---|---|---|---|
| Determination statement | Confirms the organization defined the inactivity period and the conditions that end a session, and that the system terminates the network connection when they occur | Organization-defined inactivity value, documented session end conditions, and the approved SC-10 implementation statement in the security plan | Parameter is never defined, or the plan describes a user-level timeout and no network connection termination |
| Examine: system design documentation | Reviews how sessions traverse the boundary, load balancers, proxies and application servers to see where the network connection is supposed to end | Architecture diagrams, data flow diagrams, and a list of every component that holds a network session | Design shows one session timer but omits proxies, reverse caches or database connections that keep sessions open |
| Examine: configuration settings and associated documentation | Checks timeout and idle settings on each layer that holds a connection, and compares them to the defined period | Exported configuration files or screenshots for web servers, load balancers, firewalls and VPN gateways, with the change record for each value | Timeouts set at the application layer but not at the proxy or firewall, or values that differ between environments |
| Examine: system audit records | Looks for evidence that terminations actually happen in operation, such as connection close or idle timeout log entries | Log extracts showing idle or end-of-session terminations over a sampled period, with the log source and time synchronization status | No termination events exist, or logs cannot be tied to a specific session or host |
| Interview | Asks system administrators, application owners and network staff how the timeout was chosen, who changes it, and how they know it still works | Named owners for each timeout setting and a record of who approved the defined period | Staff describe the intended behavior from memory and cannot point to the setting that enforces it |
| Test | Starts an idle session and observes whether the network connection closes after the defined period, and checks that a normal logout also ends the connection | Test plan, test steps, timestamps of the idle start and the observed disconnect, and the captured result | Test covers only the browser session, so the TCP or TLS connection behind it remains open |
| Typical finding: layers out of step | Compares the shortest and longest timeout in the chain to see which layer decides when the connection actually ends | A single table listing each layer, its timeout value, and the owner | Idle timeout in the application is 15 minutes but the load balancer keeps the connection for much longer |
| Typical finding: documentation drift | Checks whether the system security plan and runbooks still match the live settings | Dated version of the plan, change tickets for timeout updates, and a reconciliation of plan text against exported settings | Settings changed during an upgrade, but the plan and assessment report still show the old value |
How to implement SC-10 step by step
This sequence turns SC-10 from a policy sentence into a tested, owned and reviewable setting. Each step ends with a named output, so an assessor can trace the requirement from the defined inactivity period to the configuration, the test result and the review record.
Define the inactivity period for each system and session type
The system owner, with security and the business owner, sets the organization-defined period that SC-10 leaves open, and records it separately for each system and session type, such as administrative consoles, user application sessions, service-to-service connections and remote access. Because the control has one organization-defined parameter, this value is the decision an assessor will look for first. Confirm the value with the policy owner and the system's risk documentation before any configuration work begins. The output is a short approved table of systems, session types, inactivity periods and the rationale for each, signed by the owner.
Map every network session path that must end
Inventory the network connections the system holds open, including user sessions through load balancers, reverse proxies and web application firewalls, administrative sessions into hypervisors and bastion hosts, database connections, API clients and connections to external services. Note which layer owns each session, because a timeout set at one layer does not always end a session held at another. Include sessions crossing the boundary described in SC-7, since those are the ones most often missed. The output is a session path diagram or table naming each path, its endpoints and the component responsible for ending it.
Configure timeouts at the correct layers
The engineering team sets the idle timeout on each layer identified in the mapping, for example in the operating system's SSH or remote desktop settings, the application server, the reverse proxy, the firewall's session handling and the database connection pool. Keep the values consistent with the approved table, and make sure a session cannot outlive the shortest timeout in its path. Store the configuration in version control so that changes are traceable. The output is a configuration record per layer, with the file names, keys and values that implement each approved period.
Test that connections actually terminate
Test each session path in a non-production environment by opening a connection, leaving it idle past the approved period and confirming that the network connection closes, not just that a screen locks or a user is logged out. Repeat the test for end-of-session disconnects, such as a normal logout or a closed client. Record the time of each test, the observed result and any path that stayed open. This is the difference between SC-10 and AC session lock controls, so test the network state directly with connection listings or firewall state tables. The output is a dated test record with pass or fail results and a fix for every failure.
Collect audit and configuration evidence
Gather the evidence an assessor examines for SC-10: system design documentation showing the session paths, configuration settings with their associated documentation, and audit records that show disconnect events or timeout behavior where the platform logs them. Where a platform does not log disconnects, note that gap and record the configuration as the primary evidence. Check that log timestamps are synchronized so disconnect events can be correlated. The output is an evidence folder indexed by session path, each item tied to the approved period it supports.
Document the setting and assign an owner
Write a short standard or procedure that states the approved inactivity periods, the layers they apply to, the owner of each layer and the test method used. Name a single accountable owner for the control and an owner for each configuration layer, so that a change in one team does not silently break another. Link the document to the system security and privacy plan that the authorizing official reviews. The output is an approved document with named owners and a version history that matches the configuration record.
Set a review trigger and monitor for drift
Define the events that reopen the SC-10 setting: a change to the system architecture, a new session path, a new load balancer or remote access method, a change to the organization-defined period, or a finding from a security test or assessment. Add a scheduled check that compares live configuration with the documented values, using configuration management or compliance scanning tools where the organization already runs them. Confirm the review cadence with the control's policy owner. The output is a review trigger list and a drift check record that show when the setting was last confirmed and by whom.
Evidence that satisfies SC-10 and how to keep it current
An assessor testing SC-10 wants proof that network sessions actually end when they should, and that the documented timeout matches what runs in production. The artifacts below connect the written definition of the control to the live configuration and to the records of what happened. Each one goes stale if it is not refreshed when the system changes.
Defined parameter in the SSP
SC-10 has one organization-defined parameter: the period of inactivity after which a network connection is terminated. The system security plan should state the value chosen for each system or component, the session types it covers (for example, administrative SSH, web application sessions and API connections), and who approved it. Check that the value in the plan matches the value an assessor can see in configuration. A parameter that exists only in a policy document will not satisfy the control on its own.
Configuration exports with timeout values
Export the live settings from every component that terminates network sessions, including load balancers, reverse proxies, firewalls, bastion hosts and application servers. Each export should show the inactivity timeout and the session end behavior as deployed. Store exports with a timestamp and the host or service name so an assessor can trace each value to a system. Re-export after every patch cycle, because a rebuilt image or upgraded package can reset a default without anyone noticing.
Test results showing disconnects
Configuration shows intent. A test shows the behavior. Record a dated test in which an idle session is left open past the defined period and the connection is shown to close, with the client, server and any intermediary logs attached. Include a test where the session ends normally at logout or at a defined session end. Repeat these tests whenever the timeout, the proxy chain or the client software changes, and note which component was the last one to close the connection.
Audit records of terminated sessions
Logs from the proxy, firewall or application show the disconnect events that happened in production. Confirm that session termination events are written to the central log store with a timestamp, the session identifier and the reason for closure, such as inactivity or normal end. Sampling these records over the audit period shows the control operating rather than only being configured. If the platform does not log terminations, document the gap and the compensating evidence in the plan of action and milestones.
Change records when timeouts move
Any change to the inactivity value needs a change ticket that names the old value, the new value, the approver and the reason, such as a usability complaint or a new compliance requirement. Link the ticket to the updated configuration export and to a retest. Assessors often find that a value was changed during an incident or a performance tuning exercise and never reflected in the SSP. Reconcile change tickets against the SSP at each review cycle to catch these drifts early.
Scheduled reconciliation between documents and systems
Set a recurring check, aligned with the organization's review schedule, that compares the SSP parameter, the exported settings and the most recent test results. Any mismatch becomes a finding with an owner and a due date. Ask your implementation partner or internal team to automate the export step where the platform supports it, and confirm with the platform vendor which settings are exposed through its API or configuration files before relying on that method.
What meeting SC-10 costs in money and effort
This table breaks down the cost components of meeting SC-10 Network disconnect, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price is published here and fees follow from a written scope.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it |
|---|---|---|---|
| Configuration and engineering of session timeouts | Internal platform or network engineers, or an implementation partner under a fixed-scope agreement | One-time, with changes when systems change | Number of session paths (SSH, admin consoles, VPN, web applications, database clients) and the number of systems that need separate settings |
| Testing that disconnects occur at session end or after the defined inactivity period | Internal testers or a security testing provider | One-time per test cycle, repeated after significant change | Number of distinct protocols and entry points, and whether tests run against production-like environments |
| Evidence collection and retention | Internal compliance or platform staff, sometimes automated by configuration management tooling | Recurring, usually on each assessment cycle | Number of systems in scope, the evidence format the assessor expects, and how many configuration snapshots must be kept |
| Parameter documentation and ongoing review | Control owner and system administrators | Recurring, tied to review frequency set in the organization's policy | How often the inactivity period is reviewed and how many teams share responsibility for session settings |
| Independent assessment and sampling | Independent assessor or auditor, who is not paid by the implementation partner for issuing findings | Recurring, per assessment cycle | FedRAMP class or impact baseline, system count, and how many sampled session paths the assessor selects |
| External testing or review of network session behavior | Third-party testing firm, if the organization chooses to buy it | Optional, one-time or recurring | Scope of the test and whether the organization wants independent validation beyond its own evidence |
| Open-source tooling | Organization pays for hosting, staff time and any commercial support it chooses, with no per-seat license for the core project | Recurring infrastructure and staff time | Hosting footprint, number of endpoints monitored, and whether the team runs the tool or buys support |
Who owns SC-10 and what an implementation partner can take on
The organization owns SC-10 in full. It decides the defined inactivity period that the control's organization-defined parameter requires, approves the network sessions in scope, accepts the residual risk of any exception, and remains accountable for the control whether or not an outside party helped configure it. Because SC-10 is implemented by the system, the organization must be able to show that the system itself ends sessions as the documented rule says, and that the rule is written down, owned and reviewed.
- Timeout parameter: Set and document the inactivity period and the session types it covers, then record who approved it and why.
- Configuration ownership: Keep authority over firewall, proxy, load balancer and application timeout settings, and approve every change through its change process.
- Testing and monitoring: Run or commission periodic checks that idle sessions are actually terminated, and keep the results.
- Evidence: Retain system design documentation, configuration exports and audit records that show the control operating over time.
- Assessment readiness: Name an internal owner who can answer assessor interview questions about the control.
Before any engagement starts, confirm that an internal owner can explain the timeout decision and produce current configuration evidence without help from a vendor.
DeployOpen, as an implementation partner, can plan, configure, document and prepare evidence for SC-10 on self-hosted open-source platforms inside the client's own infrastructure. The partner works to a written scope and produces configuration, test records and evidence packages. It does not set the organization's risk decision for the timeout, does not accept risk, and does not certify that the control is met.
- Configuration work: Apply the agreed inactivity settings to the in-scope components, such as proxies, firewall policies and application session handling, and document each setting.
- Testing preparation: Build repeatable checks that show idle connections are closed, and run them before handover.
- Evidence preparation: Organize configuration exports, audit records and test results so the organization can present them to an assessor.
- Documentation support: Draft the system design notes and procedures that describe how SC-10 is implemented, for the organization to review and approve.
- Scope boundaries: Work is fixed in writing, so items such as the timeout value, cross-system ownership and the assessment itself are either agreed in advance or excluded.
Before signing a scope, confirm which systems, sessions and evidence formats are included, and who signs off each deliverable.
An independent auditor, assessor or certification body examines and tests SC-10 and issues the assessment result. The assessor uses the SP 800-53A procedure for the control, which contains one determination statement and examine, interview and test methods. Independence is the reason the result carries weight, so the assessor must not design, configure or sign off the control it tests.
- Examine: Review system design documentation, system configuration settings and associated documentation, and system audit records.
- Interview: Ask the organization's owners how the timeout was chosen, who approves changes and how exceptions are handled.
- Test: Observe or run session tests to confirm that idle and ended connections are terminated as documented.
- Reporting: The assessor, not DeployOpen, produces the findings and any assessment report.
- Line to hold: Partners supply evidence and explanations. They do not write the conclusion or pass the control on the assessor's behalf.
Before engaging an assessor, confirm their independence from the implementation partner and agree in writing which evidence they will accept.
Where SC-10 evidence usually fails
SC-10 is a short control, but its evidence breaks in predictable places: the timeout is never defined, it is enforced in one tier but not another, and the records that prove it drift after changes. Each card below names one gap and the check that closes it before an assessor finds it.
No defined inactivity parameter
SC-10 asks for a defined period of inactivity after which the network connection ends, and that value is an organization-defined parameter. Teams often rely on a vendor default that nobody recorded. Before testing, confirm that a specific value is written into the system security plan and matches what the configuration actually enforces. If the value is absent, an assessor cannot test it and the control fails by default. Document one value, with its owner and rationale, before anything else.
Timeouts enforced in one tier only
An application may end idle sessions while the reverse proxy, load balancer or database connection pool keeps the underlying network connection open. The network session persists even though the user is gone. Inventory every tier a session traverses and record the idle timeout at each one. Then test each tier separately by idling a connection and confirming it closes, rather than inferring it from the application log.
Confusing session lock with disconnect
Locking a screen or ending a user session under the AC family does not necessarily close the underlying network connection, and SC-10 is a different requirement. Evidence that shows a login prompt reappearing does not satisfy SC-10. Separate the two in your control mapping, cite AC session controls and SC-10 with distinct evidence, and show the network-level close, such as a socket or connection termination record.
No proof of actual termination
A configuration file that sets a timeout shows intent, not behavior. Assessors examine configuration settings, design documentation and audit records, so the evidence should include a test in which an idle connection is observed closing, plus logs of terminated sessions. Where the platform is self-hosted, capture firewall or proxy logs showing the connection state change. Without this behavioral proof, the control rests on documentation alone.
Stale evidence after upgrades
Proxy, database and operating system upgrades can reset timeout defaults, and a new release can change how keepalive packets are handled. Evidence captured before an upgrade may no longer describe the running system. Tie each SC-10 test to a configuration version and re-run it after every change to a tier in the session path. Track the NIST SP 800-53 release used for the control mapping as well, since Release 5.2.0 changed several controls and the mapping should show which release it cites.
Questions buyers ask about SC-10 cost, effort and scope
How long does it take to implement SC-10 network disconnect?
The control itself is one setting per communications session type, so the duration depends on how many session types exist and how many systems need the change, not on the control text. Effort rises with the number of applications, load balancers, VPN gateways, remote access paths and administrative interfaces that hold sessions, and with the change process each system must pass through. No duration is set by NIST for SC-10, and the supplied sources give no timeline. Ask any implementation partner for a written scope that lists each session type, system and the test evidence per system before agreeing a schedule.
Can an in-house team implement SC-10 without outside help?
Often yes, if the team already owns the platforms that hold sessions and can change their timeout and disconnect settings under change control. The work is mostly configuration, documentation and testing rather than new software. Outside help becomes more useful when many heterogeneous systems need consistent settings, when the team lacks someone who can produce test evidence in the form an assessor expects, or when the organization wants an independent review before assessment. The organization keeps ownership of the control either way. Confirm with your assessor which systems fall inside the authorization boundary before deciding who does the work.
How does SC-10 differ from AC session lock and termination controls?
SC-10 operates at the network connection layer: it ends the communications session between components when the session finishes or has been idle for a defined period. The AC family controls work at the user layer, covering when a user session locks or terminates and how a user is logged out. A user can be locked out of a workstation while a network connection stays open, and a network connection can be dropped without locking the user. Assessors usually test both, so each needs its own configuration and its own evidence. Your AC session control owner and your SC-10 owner should agree which timeouts apply to which layer.
What evidence does an assessor ask for to test SC-10?
The assessment procedure for SC-10 in SP 800-53A Release 5.2.0 uses one determination statement and examines system design documentation, system configuration settings with their associated documentation, and system audit records. Interview and test methods also apply. In practice, an assessor will ask for the defined inactivity period, the configuration that enforces it on each relevant component, and records showing that sessions were actually ended. Keep the parameter value in your system security plan, export configuration from each platform, and retain logs that show disconnect events. Confirm the exact artifacts with your assessor before collecting them.
What does outside help cover for SC-10 and what stays with my team?
An implementation partner can prepare the configuration, document the parameter, produce test evidence and help align it with the system security plan. Independent auditors or assessors perform the assessment and issue any report. Your organization owns the control decision, the defined inactivity period and the risk acceptance. Work that typically moves outside includes writing the configuration baseline, building repeatable tests, and collecting logs in a form assessors can review. Ask any provider for a fixed written scope that names each system, each deliverable and who signs off on the parameter value.
Which open-source tools can help produce SC-10 evidence?
Several self-hosted tools can support evidence collection, though none of them is a complete SC-10 solution on its own. OPNsense can log rule matches in its live log view, which helps show how boundary traffic is handled. Wazuh Security Configuration Assessment checks endpoint configuration against YAML policies, and Fleet policies ask yes or no questions of devices as osquery queries, with pass or fail results per device. Whether a given platform exposes a specific session timeout setting should be confirmed in that platform's documentation and your own testing. Use the tools to gather configuration and results, and document how each one maps to your defined parameter.
Is there an official cost estimate for implementing SC-10?
No, the supplied sources do not include a cost or effort figure for SC-10, and NIST states that it does not estimate compliance or certification costs. Cost depends on the number of systems in scope, the platforms involved, whether settings are already standardized, the test and evidence work required, and the assessor's fees. Those costs split into one-time work such as the initial configuration, documentation and first assessment, and recurring work such as re-testing after changes and evidence refresh. Request a written quote that separates each system, each deliverable, the assessor's fees and any retainer for ongoing support.
Is SC-10 required for every SP 800-53 baseline?
SC-10 is assigned to the moderate and high baselines in SP 800-53B, so it is not part of the low baseline. FedRAMP's Rev5 baselines require it at Classes C and D. Whether it applies to your system depends on the impact level your authorizing official or contract assigns and the baseline selected for your system. Confirm the baseline and any tailoring with your authorizing body before scoping work, since a tailored baseline may add or remove controls.
Open-source tooling that supports SC-10 evidence
Open-source tools can produce useful evidence for SC-10, but none of them checks the one thing an assessor will ask about first: whether the session timeout the organization defined is actually enforced on the systems in scope. Before relying on any tool, confirm with its documentation and a test in your own environment that it can read the specific timeout or session setting you chose. The organization still owns the parameter value, the decision about which connections are covered, and the conclusion that the control is met.
OPNsense can support the network side of the control. Its stateful packet filter rules pass, block or reject traffic by source, destination, port and protocol, and its rule logging can be turned on so that matches are visible in the live log view. Export the rule set and the relevant log entries as dated records to show how administrative and application sessions are handled at the boundary. Note that a firewall rule does not itself show that a server closes an idle session, so pair these records with host or application configuration evidence. Wazuh's Security Configuration Assessment (licensed under GPL-2.0-only) checks endpoints against YAML policies that examine files and running processes, and its shipped policies are mostly based on CIS benchmarks. A custom policy can check the value of an SSH, web server or application timeout key in a file, and the scan results record pass or fail for each check over time. Fleet (MIT) policies work differently: each policy is a yes or no osquery question, and the policies page shows which devices pass or fail. A Fleet policy can ask whether a timeout setting exists on a device, which gives a per-device view that changes when someone edits the configuration.
Licensing matters for the evidence package. OPNsense is BSD-2-Clause, Wazuh is GPL-2.0-only, and Fleet is MIT, so confirm that each license permits your intended use, modification and internal distribution, and have counsel review any custom policies or forks you plan to ship. Plan for drift: a timeout that passes today can change after an upgrade or a configuration push, so schedule the scans, keep the reports, and record who reviews failures and how fast they are fixed. Decide early which of these records your assessor will accept as the source of truth, and agree that format with the assessor before collecting evidence.
