SI-14(3): Non-persistent Connectivity

SI-14(3) requires you to make remote or logical connections to your system non-persistent: establish them only when needed, then automatically terminate them after a defined time or condition. To operationalize it quickly, set a clear “disconnect after X” standard, enforce it via technical controls (VPN/SSH/RDP/API/session timeouts), and retain configuration and log evidence. ¹

Key takeaways:

• Define “on-demand” connection methods and a concrete termination rule (time-based or event-based) for each access path. ¹
• Enforce non-persistence with system settings, identity/session controls, and network access tooling, not just policy. ¹
• Evidence is mostly configs + logs: you need proof the timeout/termination settings exist and operate in production. ¹

The si-14(3): non-persistent connectivity requirement is a practical control aimed at shrinking the window of exposure created by “always-on” connections. Persistent sessions expand attack surface: a compromised endpoint, stolen token, or forgotten admin session can become a standing bridge into your environment. SI-14(3) pushes you toward “connect only when needed, disconnect promptly,” backed by enforceable settings and audit-ready proof. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to make this assessable is to treat it like an access-path standard. Identify every pathway that can create a session into the system (interactive admin, user remote access, service-to-service, third-party support), decide the termination condition for each, then configure the relevant platforms to enforce it automatically. Where you can’t technically force termination, you document an exception with compensating controls and an owner. ¹

This page focuses on turning SI-14(3) into a short implementation procedure, a small set of standard configurations, and a repeatable evidence package you can hand to an assessor without debate. ¹

Regulatory text

NIST SI-14(3) excerpt: “Establish connections to the system on demand and terminate connections after {{ insert: param, si-14.03_odp }}.” ¹

Operator meaning:

1. You do not allow standing connectivity by default. Connections should be initiated as needed (for example, user-initiated VPN, privileged admin jump access started for a change window, third-party support session started by ticket).
2. You must end the connection after a defined organization-defined parameter (ODP). That ODP can be a time limit (idle timeout, maximum session duration) or a condition (ticket closure, task completion, step-up approval expiration), as long as it is explicit and enforced. ¹

Plain-English interpretation

Your system should not maintain indefinite sessions or “always-connected” tunnels just because it’s convenient. If a connection exists, it should exist for a reason, and it should end automatically when that reason expires. For assessability, the control lives or dies on two points:

• Your defined termination rule (the ODP).
• Technical enforcement of that rule across the connection types you actually use. ¹

Who it applies to

Entity scope: Federal information systems and contractor systems handling federal data that have adopted or are assessed against NIST SP 800-53 Rev. 5 controls. ¹

Operational scope (where this shows up in real environments):

• Remote user access into an enclave (VPN/ZTNA/VDI).
• Privileged admin access (SSH/RDP via bastion, PAM session brokering).
• Third-party support access (time-bound vendor access, support tunnels).
• Cloud console access (SSO-based console sessions, role sessions).
• API and service sessions (tokens, session lifetimes, long-lived keys where “connection” maps to session validity).
  Your job is to decide which of these count as “connections to the system” for your boundary and then make them non-persistent in practice. ¹

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

Step 1: Write the ODP in operational terms

Define what triggers termination and where it is enforced. Keep it short and implementable.

A usable ODP statement looks like:

• “Administrative remote sessions terminate after an idle timeout and have a maximum session duration; third-party access terminates at ticket closure or approval expiry, whichever comes first.” ¹

Avoid an ODP that is purely aspirational (“sessions should be short”) because you cannot test it.

Step 2: Inventory connection paths and map owners

Create a one-page connection-path inventory table. Minimum columns:

• Connection type (VPN, SSH, RDP, cloud console, API session, support access)
• System/component in scope
• Identity plane (IdP, local accounts, PAM)
• Enforcement point (VPN gateway, bastion, IdP session policy, PAM, reverse proxy)
• Termination control (idle timeout, max duration, approval expiry, kill switch)
• Control owner (Network, IAM, Platform, SecOps)

This converts SI-14(3) from “security concept” into a list of enforceable settings. ¹

Step 3: Implement technical enforcement for each path

Pick the enforcement layer that is hardest to bypass.

Common patterns assessors accept because they are testable:

• VPN / ZTNA: enforce idle timeout and maximum connection duration at the gateway/controller; require user-initiated connections rather than permanent tunnels where feasible.
• SSH/RDP admin access: require access through a bastion/jump host with session timeouts and automatic disconnect; disable direct inbound admin protocols from the internet.
• PAM-brokered privileged sessions: time-bound approvals, automatic session termination, and session recording tied to a ticket or change window.
• Cloud console sessions: enforce SSO session lifetime policies; restrict long-lived access keys; prefer short-lived role sessions where possible.
• Third-party support: require per-request enablement (ticket-gated), time-boxed access, and an explicit disable step in the runbook.

Your assessor will look for evidence that these are system settings, not “we tell admins to log out.” ¹

Step 4: Add a “disconnect on close” workflow for exceptions and break-glass

You will have edge cases: incident response, emergency maintenance, legacy systems.

Create an exception workflow with:

• Business justification
• Compensating controls (more monitoring, jump host only, dedicated accounts, approval)
• Expiration and re-approval trigger
• Required post-activity termination step and confirmation (disable account, remove firewall rule, revoke token)

Keep exceptions rare and time-bound, and track them like you track access approvals. ¹

Step 5: Make it auditable: test and monitor

Add one operational test per connection type:

• Attempt an idle session and confirm disconnect.
• Attempt to exceed max session duration and confirm termination.
• Confirm third-party access cannot be established without an approved request.
• Verify logs show session start/stop or token issuance/expiry events.

Then add monitoring: alerts for sessions exceeding expected duration, dormant tunnels, or service accounts using long-lived credentials when short-lived options exist. ¹

Step 6: Assign control ownership and recurring evidence

Operationalize SI-14(3) like a control with a cadence:

• Primary owner (IAM or Network Security usually)
• Secondary owners (Platform, SecOps, Third-Party Risk for vendor access paths)
• Evidence schedule (config exports + sample logs + exception register updates)

Daydream (as a GRC system) fits naturally here: map SI-14(3) to an owner, link the implementation procedure, and set recurring evidence tasks so you do not rebuild the audit package every cycle. ¹

Required evidence and artifacts to retain

Keep evidence that proves definition, implementation, and operation:

1. Documented ODP for SI-14(3) (policy standard or control statement) showing the termination rule. ¹
2. Connection-path inventory (table) with owners and enforcement points.
3. Configuration evidence (screenshots or exports) for:
   • VPN/ZTNA timeout and max duration settings
   • Bastion/jump host session policies
   • IdP session lifetime policies
   • PAM approval duration/session termination settings (if used)
4. Operational logs demonstrating sessions terminate (sample of session start/stop; token expiry; access disabled after request).
5. Exception register for any persistent or semi-persistent connectivity, with expiration and compensating controls.
6. Procedure/runbook for enabling and disabling third-party access (ticket gating).

Common exam/audit questions and hangups

Assessors and internal audit usually press on these points:

• “What is your organization-defined termination parameter for SI-14(3), and where is it documented?” ¹
• “Show me the settings that enforce it for VPN and privileged access.”
• “Do third parties ever have standing access? If yes, why, and where is the approval and expiration?”
• “How do you know a session actually terminated versus the user saying they logged out?”
• “What systems are in scope for ‘the system’ boundary, and do the same rules apply to cloud consoles and APIs?”

Hangup to expect: teams treat “connectivity” as only network tunnels, while assessors treat it as any session that creates access. Decide your interpretation early and document it. ¹

Frequent implementation mistakes and how to avoid them

Mistake 1: Writing a policy with no enforceable settings.
Fix: tie each connection type to a specific enforcement point and configuration artifact.

Mistake 2: Forgetting third-party support paths.
Fix: require ticket-based enablement and remove accounts/firewall rules after completion.

Mistake 3: Relying on “idle timeout” only.
Fix: pair idle timeout with a maximum session duration where feasible, so long-running unattended sessions still end. ¹

Mistake 4: Long-lived API credentials treated as “not connectivity.”
Fix: document how API/session validity is bounded (short-lived tokens, rotation, scoped roles) and treat token lifetime as the “termination” analog.

Mistake 5: No exception hygiene.
Fix: keep an exception register with explicit expiration, re-approval, and compensating controls.

Risk implications (why operators care)

Non-persistent connectivity reduces blast radius. If credentials are compromised or a workstation is taken over, the attacker’s window is shorter and easier to detect. Persistent tunnels, shared vendor accounts, and never-expiring sessions create a quiet path for lateral movement and data access that can survive beyond a single security event. SI-14(3) is medium severity in many control baselines, but persistent access paths often become “high impact” in incident reviews because they are the route attackers reuse. ¹

Practical 30/60/90-day execution plan

First 30 days: Define and map

• Publish the SI-14(3) ODP statement and get technical owner sign-off. ¹
• Build the connection-path inventory and confirm all admin/third-party access routes.
• Identify gaps where no timeout/max duration exists or where third parties have standing access.
• Stand up an exception register with an approval owner and expiration requirement.

By 60 days: Enforce and document

• Implement timeout/max duration settings for the highest-risk paths first: privileged admin access and third-party remote access.
• Route privileged access through a single controlled entry point where possible (bastion/PAM).
• Update runbooks: “enable access,” “verify work,” “terminate access,” “collect evidence.”
• Start collecting config exports and sample logs as evidence.

By 90 days: Test, monitor, and make it repeatable

• Run a control test per connection type and retain results (screenshots, logs, test notes).
• Add monitoring/alerting for sessions that exceed expected duration or for dormant tunnels.
• Operationalize recurring evidence in your GRC workflow (tasking, reminders, owner attestations). Daydream can track owners, map the procedure, and request the same artifacts each cycle so evidence stays current. ¹

Frequently Asked Questions

Does SI-14(3) only apply to VPN connections?

No. Treat it as applying to any session or mechanism that establishes access to the system boundary, including privileged remote sessions, cloud console sessions, and third-party support access. Document your in-scope connection paths and enforce termination for each. ¹

What should we set for the “terminate connections after …” parameter?

NIST leaves it as an organization-defined parameter, so pick a rule your systems can enforce and you can defend operationally. Write it down, apply it consistently by connection type, and keep configuration evidence that matches the written rule. ¹

If users close their laptop, does that count as terminating connectivity?

Only if your technical controls reliably end the session (for example, the VPN gateway or IdP enforces idle/max duration). Auditors typically want proof of enforced termination, not user behavior. ¹

How do we handle third-party access for support teams that “need” persistent connectivity?

Convert persistent access into request-based enablement with time-boxed approvals, or document an exception with compensating controls and an expiration. Keep a clear disable step and evidence that access was removed after the work. ¹

Are long-lived API keys a SI-14(3) issue?

They can be, if they effectively create ongoing access without termination. Treat token/key lifetime and revocation as the “termination” mechanism, and document how you bound session validity for service-to-service access. ¹

What evidence is strongest in an assessment?

Config exports showing timeouts/max duration, paired with logs that show session termination events, plus an exception register for anything that stays connected longer. That combination proves design and operating effectiveness. ¹

Footnotes

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