03.13.09 Network disconnect: requirements and evidence

What NIST SP 800-171 network disconnect (03.13.09) requires

Requirement 03.13.09 asks the organization to terminate the network connection tied to a communications session either when the session ends or after a defined period of inactivity. It is one of the 97 Rev. 3 requirements in *NIST SP 800-171 Rev. 3*, and a contract or assessment that names NIST SP 800-171 will expect you to show how your systems do this. The requirement is short, but the work behind it is not, because the timeout has to be set, enforced and evidenced at the right layer. The risk is simple to describe. A session left open after a user walks away, on a shared workstation, a kiosk, a jump host or a remote administration console, gives the next person at that device a live path into systems that hold CUI. The inactivity period is an organization-defined parameter (ODP). NIST does not supply a value, so your organization must choose one, document it in the system security plan and make sure the system enforces it. If a contracting agency specifies a value, use that value. Confirm with the agency before you assume a default.

Three things usually make this hard. First, ownership is split: the application may keep its own session timer, the network layer may hold idle connections open for its own reasons, and the endpoint may lock the screen without ending the underlying connection. Each team can believe the requirement belongs to someone else. Second, timeout values are often set during deployment and never recorded, so the number an assessor finds in a configuration file may not match what the policy says. Third, the assessment method for this requirement uses examine, interview and test steps, so you need to show the setting, explain who manages it and demonstrate the disconnect actually happens. Start by listing every layer that holds a session for CUI, assign an owner to each timeout, and test each one against the documented value.

Where NIST SP 800-171 network disconnect applies in your environment

03.13.09 applies to every communications session that carries CUI, so the first job is deciding which sessions sit inside the boundary. Each card below names one scoping decision, the team that usually owns the layer, and how that decision changes the configuration and evidence you will need.

Web applications serving CUI

Any web application where users view or change CUI needs an inactivity timeout that ends the network connection, not just a logged-out page. Check where the timer lives: the application framework, the reverse proxy or the load balancer. If more than one layer sets a timeout, document which value governs and confirm the others do not extend it. Application and platform teams usually share this layer, so assign one owner for the setting.

VPN and remote access sessions

Remote sessions into the CUI enclave are often the clearest case for a defined inactivity period enforced at the gateway. Confirm whether the VPN concentrator, firewall or zero trust access proxy drops idle tunnels, and whether the value is the one written in your system security plan. Network operations usually owns this layer, and the configuration export and session logs become the examine and test evidence.

Administrative consoles and privileged sessions

Administrative interfaces such as hypervisor consoles, cloud management portals and SSH access to servers hold the widest control over CUI, so they warrant the strictest idle limits. Decide whether privileged sessions get a shorter period than user sessions and record that choice as an organization-defined parameter. Expect interviews with system administrators to test whether the setting is applied in practice.

APIs and service-to-service connections

Machine connections rarely go idle the way user sessions do, so an inactivity rule may not apply to them at all, and the decision must be written down. Identify which API connections carry CUI, whether they use persistent connections or connection pools, and how the system ends sessions that stop sending traffic. Development and platform teams own the client libraries and gateways that set these values.

Database connections

Database sessions opened by applications can persist in connection pools long after a user leaves, which can keep CUI-bearing connections alive. Check the pool idle timeout and the database server's own idle session limit, and confirm both are in the configuration baseline. Database administrators own these settings, and the change record for each pool value supports the evidence package.

Cloud-hosted and third-party services

A managed identity provider, SaaS collaboration tool or hosted load balancer that touches CUI sessions may sit inside your boundary through its contract and data flows. Ask each provider where it enforces session termination, whether it lets you configure the period, and what logs it can produce for an assessor. Where the provider cannot meet your defined value, record the gap in the plan of action and milestones rather than assuming it is covered.

How assessors test NIST SP 800-171 network disconnect under SP 800-171A

This table shows how an assessor covers 03.13.09 under SP 800-171A Rev. 3, grouped by examine, interview and test method, with the evidence to prepare and the findings that commonly appear. Read each row as a question the assessor will ask and the artifact that answers it. The main takeaway is that the policy, the configured value and the observed behavior must all agree, because the ODP check and the test method will expose any gap between them.

Assessment method and objects	What the assessor checks	Evidence to have ready	Common findings
Examine: system and communications protection policy and procedures	That policy states the network disconnect requirement and assigns an owner	Approved SC policy, procedure document, revision history and approval record	Policy exists but never names an inactivity period or an owner
Examine: network disconnect procedures	That documented steps show how sessions end at session close or after inactivity	Runbook or standard showing the inactivity period and who maintains it	Procedure describes intent only, with no link to a configuration item
Examine: system design documentation	That the design shows where disconnect is enforced (application, server, gateway or endpoint)	Architecture diagrams and component descriptions for each in-scope system	Design omits a tier, such as a load balancer or VPN concentrator, that holds sessions
Examine: system configuration settings	That the configured inactivity timeout matches the organization-defined value	Exported configuration files, timeout parameters and change records for each component	A timeout value exists in policy but not in configuration, or differs between components
Examine: system audit records	That disconnect events are recorded and can be traced to a session	Log samples showing session termination events and their timestamps	No logs exist for session termination, so the assessor cannot verify operation
Interview: personnel with information security responsibilities	That staff understand the defined period and who approves changes to it	Named roles, responsibility matrix and a short walkthrough of the approval path	Staff cite a different value from the one documented
Interview: system developers and system administrators	That developers built the timeout and administrators maintain it after changes	Engineer and admin walkthrough, and records of who changed the setting last	Administrators are unaware the timeout was overridden during a migration
Test: mechanisms supporting network disconnect	That a session actually ends at the end of the session or after the defined inactivity period	Test scripts, test results and a witnessed or recorded run against each in-scope system	Session stays open beyond the defined period, or the test covers only one component
ODP check: organization-defined parameter is defined	That the inactivity period is set to a specific value and not left open-ended	A single recorded value in the SSP or policy that matches the configuration	The parameter is described as configurable but no value is assigned

Implementing network disconnect in the right order

This sequence turns the 03.13.09 requirement into a configured, tested and documented behavior: CUI sessions end on a defined inactivity period at every layer that holds them, and an assessor can trace each setting to a procedure, a test result and an audit record.

Confirm which CUI sessions are in scope
Start by listing every communications session that carries or gives access to CUI, including user sessions to applications, administrative sessions, remote access sessions, and service-to-service connections that stay open. The system owner and the security lead should agree on this list and map each session to the components it crosses, such as the application, the load balancer or reverse proxy, the VPN or remote access gateway, and the endpoints and administrative tools used to reach it. This step is complete when the scope list is approved and matches the boundary described in the system security plan. Without this list, the inactivity period cannot be set for the right sessions.
Set and document the inactivity period and session-end rules
Assign the organization-defined value for the inactivity period that 03.13.09 requires, and record the rules for what ends a session, including normal logout and the end of a defined session lifetime. Because the requirement's organization-defined parameter is not set by NIST, the organization or its federal customer must choose the value and be able to justify it in its risk documentation. Confirm with the contracting agency whether it has specified a value. The output is a signed parameter record that names the value, the sessions it applies to, the approver and the review date.
Configure timeouts at each layer that holds a session
Apply the documented value in each component, not only in the application. Application servers, reverse proxies or load balancers, VPN or remote access gateways, and administrative tools can each keep a connection open after the user has stopped, so each needs its own idle timeout that is no longer than the agreed period. Export the configuration files or settings screens from each component and store them under configuration management, so the values can be compared against the parameter record. The output is a configuration baseline in which every in-scope layer shows the same agreed value or a documented reason for a different one.
Test that connections actually terminate
Run a scripted test for each session type in scope. Open a session, stop all activity, wait past the configured period, and then confirm the server side has released the connection and the client can no longer send requests without re-authenticating. Repeat the test for sessions that end normally, and record the results with the time, the session identifier, the component and the pass or fail outcome. Failures go back into configuration or into a documented exception. The output is a dated test record that shows the behavior, which is the evidence an assessor will use for the test method in SP 800-171A.
Record audit events for session termination
Confirm that each layer writes an audit record when it ends a session because of inactivity or session expiry, and that the record includes the user or service identity, the session identifier, the time and the reason. Send these records to the central log store, where access and retention follow the audit and accountability controls. Test the pipeline by generating a termination and finding the record in the central store. The output is a sample set of termination records from each layer, with a note on any layer that does not log termination and the compensating control in place.
Write the procedure and system design notes
Write the procedure that staff follow to set, change and verify the inactivity period, and the design notes that explain where timeouts are enforced and why. Keep these aligned with the configuration baseline and the test records, because an assessor interviewing system administrators and developers will compare what they say with what the documents and settings show. Include who owns each setting, how a change is approved, and how the test is repeated after an upgrade. The output is an approved procedure and design note that cite the parameter record, the baseline and the latest test results.
Confirm the evidence set before assessment
Before an assessment, check that the parameter record, configuration baseline, test records, audit samples and procedure all agree on the same value, scope and owners. Ask the independent assessor which artifacts it expects and in what format, and confirm the scoring and assessment approach that applies to your contract, since the requirement is tested through examine, interview and test methods. DeployOpen can prepare the systems and evidence for this review, but the organization owns the control and only an independent assessor can issue results. The output is an evidence index that maps each artifact to the determination statements it supports.

Evidence that passes network disconnect testing and how to keep it current

An assessor testing 03.13.09 will look for a small set of artifacts that agree with each other on one thing: the inactivity period the organization defined. Each artifact below shows a different layer of the same control, and each needs a refresh routine so it still matches the running system at the next assessment.

Written policy naming the inactivity period

The policy or procedure should state the organization-defined inactivity period after which the system ends a network connection tied to a communications session, and say when the session ends regardless of activity. Name the systems in scope and the role that owns the setting. Version the document and record its approval date, so an assessor can see which value was in force during the assessment window. Check that the number here is the same number used everywhere else.

Configuration exports from each layer

Export timeout settings from every component that holds a session open, such as the load balancer, reverse proxy, application server, database listener, VPN gateway and remote administration tools. Screenshots are weaker than exports because they cannot be diffed. Store exports in version control and capture them after each change request, so a changed timeout produces a new record with an author and a reason.

Design documentation for the session model

Architecture documents should show which connections are communications sessions, where each one starts and ends, and which component enforces the inactivity timer. Assessors use this to confirm no layer was missed, for example a persistent database connection pool that sits outside the application timeout. Note any layer that relies on another component to terminate the connection, and identify that component.

Test records of terminations

Keep dated test results showing that a session ends at the defined inactivity period and at explicit session end. Record the test account, the client, the starting time, the last activity time and the observed disconnect time. Repeat the test after upgrades, proxy changes or new integrations, because a timeout that worked on the old reverse proxy may not survive a migration. Store results with the configuration export they tested.

Audit records of terminations

Logs from the enforcing components should record session terminations with a timestamp, the session or user identifier, and the reason, such as timeout or logout. Confirm that these records are retained long enough for an assessor to sample them and that they are protected from change. Sampling a few terminations against the defined period is a fast way for an assessor to confirm the setting works in production, not only in a test environment.

Change control that keeps the value consistent

Put the inactivity value under change control with a named owner and a review trigger, such as each assessment cycle or each major platform upgrade. When the value changes, update the policy, the configuration exports, the design documents and the test records in the same change. Mismatched values across artifacts are a common reason an assessor cannot close the requirement, even when the system behaves correctly.

What meeting network disconnect costs in money and effort

This table breaks the cost of meeting 03.13.09 into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to scope a written quote, since no price or duration for this requirement is published in the supplied sources. The main takeaway is that most of the cost comes from configuring and evidencing timeouts across every layer that holds a session, not from the timeout itself.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Engineering time to set the inactivity period	Internal platform team or implementation partner	One-time, then recurring on change	Up with the number of session types and layers; down with a single documented standard value
Timeout configuration across layers	Internal engineers or implementation partner	One-time per system, plus updates	Up with load balancers, proxies, application servers, databases and VPN gateways each holding sessions
Legacy applications without native timeouts	Internal developers or vendor of the application	One-time, can be significant	Up sharply when an application cannot expire sessions and needs a wrapper, proxy or replacement
Testing that disconnects actually occur	Internal testers or a security consultant	One-time per release, then recurring	Up with the number of session paths; down when test cases are scripted and rerun automatically
Tooling and licenses	Organization, to the vendor of commercial products	Recurring license fees where applicable	Self-hosted open-source components can remove license spend, but staff time to operate them remains
Evidence upkeep	Internal compliance or security staff	Recurring	Up with frequent configuration changes; down when settings are captured in version-controlled configuration and audit logs
External review by a qualified assessor or consultant	Organization pays the consultant or assessor under a written scope	One-time readiness review, then recurring for assessments	Up with unclear ownership of ODP values and scattered settings; ask for a fixed scope before work starts
Assessor time and sampling	Organization pays the assessor when the assessment is contracted	Recurring per assessment cycle	Up when settings are undocumented and the assessor must interview many administrators to confirm them

Open-source tools that produce or support network disconnect evidence

No single tool proves that a session ends after a defined period of inactivity. The tools below each cover a different layer, from the network path to endpoint settings to web sessions, so an assessor sees how the pieces fit together. Confirm exact check coverage in your own environment before relying on any of them as evidence.

OPNsense rule logs for network paths

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Rule matches can be logged and reviewed in the live log view, which supports network-layer evidence that sessions are permitted and bounded. It does not by itself show application session timeouts. Confirm with your assessor whether firewall state timeout settings count toward the requirement in your scope, and document the ODP value you set for the inactivity period.

Wazuh checks for endpoint timeout settings

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies. Custom checks can verify files, registry keys and running processes that hold inactivity timeout values, then recommend remediation for failures. Use the scan results as configuration evidence, and confirm which timeout settings your chosen policies actually test before you map them to the organization-defined period.

Fleet policies for device-level checks

Fleet policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each policy. A policy can ask whether a required screen lock or session idle setting is present on each managed device, giving a current pass or fail view across the fleet. Confirm which settings your osquery tables can read on each operating system, since coverage varies by platform.

Coraza for web session protection

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, and integrates with Caddy, HAProxy, Traefik and Nginx. Coraza does not enforce or measure session timeouts. Treat it as supporting protection for web sessions, not as disconnect evidence, and rely on the application or proxy configuration for idle timeouts.

Who does what for network disconnect: your team, a partner, and the auditor

Your organization owns requirement 03.13.09 from start to finish. The requirement turns on a value you must choose: the period of inactivity after which the system ends a network connection tied to a communications session. Nobody else can set it for you, and the assessor will check that the value is defined and enforced. Your team also writes the policy and procedures, owns the decision to accept any residual risk, and answers for the outcome to the federal agency under the contract.

The ODP value: Set the inactivity period and the session-end conditions for each system in scope, and record the rationale against the business and CUI risk.
Policy and procedures: Document how network disconnect is configured, who approves changes, and how exceptions are handled.
Configuration ownership: Keep application, web server, VPN and firewall timeout settings aligned with the approved value.
Risk acceptance: Decide, in writing, whether any gap is accepted and who signs for it.
Contract accountability: Answer compliance questions from the contracting agency yourself, even when a partner did the work.

Before relying on any partner output, confirm that your own staff can explain the chosen value and why it fits your environment.

Where network disconnect assessments usually fail and how to close each gap

Network disconnect looks simple on paper, but assessors usually find the gap between what the policy says, what the systems do, and what the records prove. The cards below cover the failure points we see most often, each with the likely finding and the fix that closes it.

No inactivity value defined

03.13.09 has one organization-defined parameter: the period of inactivity after which the system must terminate a network connection. NIST does not assign that value, so the organization must set it. Assessors commonly find that the requirement is met in practice but the number was never chosen, which fails the ODP check in SP 800-171A. Fix it by naming a specific inactivity period in the system security plan, approving it under the organization's own change process, and tying it to each communications session type the system supports.

Policy and configuration disagree

A common finding is a documented inactivity period that differs from the value configured on firewalls, load balancers, application servers or operating systems. The assessor compares the policy against system configuration settings, and one mismatch is enough to question the whole control. Pull the configured values from each component, compare them with the approved parameter, and record the result in configuration baselines so drift is caught during routine review.

Timeouts conflict across layers

A session may close at the application after the configured period, while a load balancer, VPN gateway or proxy keeps the underlying TCP connection open for much longer. The user sees a logout, but the network path stays alive and can be reused. Map each layer that holds session state, document its idle timer, and confirm that the shortest effective timeout governs the whole path. Test the outermost and innermost timers together, not one at a time.

No test evidence of termination

Assessors look for proof that connections actually end, not only a configuration file that says they should. Many organizations hold a setting screenshot but no test record. Build a repeatable test that opens a session, leaves it idle past the approved period, and checks from the server or network side that the connection is gone. Keep the test scripts, dates, operator names and results together so an assessor can repeat the check.

Terminations not logged

The requirement is about ending connections, but assessors also expect the system to show that terminations happen. Without audit records of disconnect events, the organization cannot demonstrate operation over time or investigate sessions that stayed open. Confirm that the platform writes a record when an idle or end-of-session disconnect occurs, that the record includes the session identifier and timestamp, and that someone reviews the logs. Verify the fields with the vendor before relying on them.

Administrative sessions bypass timeouts

Remote maintenance sessions, jump hosts, SSH tunnels and administrator consoles often run with longer or no inactivity limits because they were set up for convenience. Assessors who review remote access paths tend to find these exceptions quickly. Inventory every administrative and remote path, apply the approved period or document a justified, approved exception with compensating controls, and test those paths the same way as user sessions.

Questions buyers ask about network disconnect before hiring help

What does network disconnect work cost, and what drives the price?

The cost depends on how many systems carry CUI, how many communications sessions each one runs, and how much of the disconnect behavior already exists in the platform. Most of the spend goes to configuring session timeouts on each component, testing that sessions end as defined, and writing the procedure and evidence. DeployOpen does not publish a price list. A quote follows from a written scope that lists the in-scope systems, the platforms involved and the deliverables. No fee figure for this requirement has been established here, so ask any provider to itemize the scope and state whether the work is one-time or recurring.

How long does it take to implement and evidence network disconnect?

The timeline is set by the number of systems in scope, the change control process at each site, and whether the organization has already defined its inactivity period. Work that only needs one inactivity value on a few applications moves faster than work across boundary devices, VPN concentrators, administrative consoles and remote session tools. Ask for a schedule tied to milestones in the written scope rather than a single end date, and confirm which change windows the client must provide. No duration is stated here because none has been supplied for this requirement.

What does the client need to provide for this work?

The client needs to name the system owners for each component that carries CUI, grant read access to configuration for firewalls, applications and remote access tools, and approve change windows where a session timeout could interrupt users. It also needs a decision on the inactivity period, because Rev. 3 leaves that value to the organization. Someone with authority over the system security plan should confirm that the chosen value is written into policy and procedures. Without those inputs, the work stalls at the configuration step.

Can our own team implement network disconnect without a partner?

Yes, an internal team can set session timeouts, define the inactivity period and collect configuration records without outside help. The harder part is usually testing, because the assessment method for 03.13.09 includes examining configuration settings, interviewing administrators and testing that the mechanism actually ends sessions. Teams that run the work internally often lack a neutral reviewer for those tests. An implementation partner can prepare the configuration and evidence, and the internal team keeps ownership of the decisions.

Can a partner issue the assessment result for network disconnect?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For a DoD contract, the assessment is performed by the federal agency or by DCMA DIBCAC depending on the assessment type, and the organization's own SPRS submission is its responsibility. A partner can help the organization get ready for that review, but the result comes from the assessing body, not the implementer.

Does the DFARS and CMMC context change what network disconnect requires?

The requirement text does not change, but the scoring and the version in force do. CMMC Level 2 still uses Revision 2, where the equivalent requirement is 3.13.9, assessed as SC.L2-3.13.9 and worth 1 point under the 32 CFR 170.24 scoring methodology. A DoW Class Deviation signed 3 September 2026 has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2, and a proposed FAR overhaul would move contractors to Revision 3 with DoW-published ODP values. Confirm the revision named in your own contract before scoping the work.

What should a scope document say about network disconnect?

A useful scope names the in-scope systems and their owners, the inactivity period the organization has chosen, and the components that must end network sessions. It lists the configuration changes, the test procedure for each component, the evidence to be delivered and who reviews it. It also states which revision of SP 800-171 applies, whether the work is one-time or recurring, and which items are outside the engagement, such as the independent assessment. Ask the provider to confirm each of these in writing before work starts.

How DeployOpen works on this

DeployOpen plans, implements and documents the network disconnect capability in the client's own environment, then prepares the configuration and records an assessor can examine. The organization owns the control and the inactivity period it defines, and an independent assessor decides whether the requirement is met.

How we scope

Agree in writing which session types, systems and interfaces the network disconnect requirement covers for 03.13.09.
Record the organization-defined inactivity period as a decision the organization owns and approves before any configuration work starts.
Confirm which parts of the environment are the organization's responsibility and which are inherited from a cloud or hosting provider.

How we build

Configure session timeout and connection termination settings on in-scope platforms so they match the approved inactivity period.
Set up log records that show when connections end at session close or after inactivity, for examination later.
Test disconnect behavior on representative systems and keep the results alongside the configuration baseline.

How we hand over

Deliver the configuration settings, test results and design notes that map to the examine, interview and test objects in SP 800-171A Rev. 3.
Document the procedure for network disconnect so system administrators can operate and review it after handover.
Provide the ODP value record and the reasoning behind it, so the organization can defend the chosen period to an assessor.

How we support

Engagements are fixed-scope, with scope and deliverables agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer, so disconnect settings stay aligned after changes.
Ask your assessor early which evidence they expect for 03.13.09 and confirm it against the written scope.