SC-7(7): Split Tunneling for Remote Devices

SC-7(7) requires you to prevent split tunneling on remote devices connected to your organizational systems, unless you have a securely provisioned split-tunnel design that you can defend and evidence. Operationally, that means enforcing full-tunnel VPN (or equivalent routing controls) by default, tightly governing any exceptions, and retaining configuration and monitoring evidence. ¹

Key takeaways:

• Default to “no split tunneling” for remote access; treat split tunnel as an exception that needs explicit secure provisioning. ¹
• Your pass/fail in audits usually hinges on enforceable device/network configurations plus proof they are deployed and monitored. ²
• Document the exception design (“securely provisioned”) and bind it to technical controls, approvals, and recurring evidence capture. ¹

The sc-7(7): split tunneling for remote devices requirement exists because split tunneling creates a direct path for loss of visibility and control: a remote endpoint can be simultaneously connected to your environment and to untrusted networks. That breaks common security assumptions behind boundary protection, centralized inspection, and consistent policy enforcement.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing SC-7(7) is to translate it into three concrete deliverables: (1) an enforced technical posture (full-tunnel remote access by default), (2) a tightly defined exception pattern for any “securely provisioned” split tunnel use case, and (3) evidence that stands up to an assessor’s scrutiny. The control is “medium” severity in many baselines, but it routinely becomes a high-impact audit issue when organizations cannot prove enforcement across endpoints and remote access technologies.

This page gives requirement-level implementation guidance you can hand to IT/network/security teams, then collect the artifacts you need for assessment readiness under NIST SP 800-53 Rev. 5. ²

Regulatory text

Text (excerpt): “Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using {{ insert: param, sc-07.07_odp }}.” ¹

Operator interpretation (what you must do):

1. Prevent split tunneling for remote devices when they connect to organizational systems (most commonly via VPN or a zero trust network access client). ¹
2. Allow split tunneling only as an exception when you can show it is “securely provisioned.” Because the parameter content is organization-defined, you must define what “securely provisioned” means in your environment and enforce it technically. ¹

Practical translation: Your baseline stance is “remote device traffic goes through the organization’s controlled path for inspection and policy,” unless a documented, approved architecture restricts the split tunnel to specific destinations and applies compensating protections.

Plain-English requirement interpretation

Split tunneling means a remote device sends some traffic through the corporate tunnel while other traffic goes directly to the internet (or other networks). SC-7(7) expects you to block that behavior because it reduces centralized security enforcement and can create bridging risk between trusted and untrusted networks. ¹

The requirement does not forbid all split tunneling forever. It allows it only if you can show a secure design, and you can demonstrate it is implemented as intended across your remote fleet.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data commonly map to NIST SP 800-53 controls. ²

Operational contexts where SC-7(7) is in scope:

• Managed laptops/desktops connecting from home networks, hotels, or public Wi‑Fi to organizational systems.
• Administrative access paths into sensitive environments.
• Remote access used by third parties (support providers, consultants) using your managed device, your VDI, or your remote access stack.

Typical in-scope technologies:

• VPN clients and concentrators
• ZTNA agents/connectors
• VDI/Citrix/RDS access patterns (split tunneling may appear at the endpoint, the VDI host, or both)
• Endpoint management baselines that control route tables, DNS, and proxy settings

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

Step 1: Define your “securely provisioned split tunnel” exception

Because the excerpt references an organization-defined parameter, you need a written definition that engineering can implement and audit can test. ¹

Minimum elements to define:

• Allowed use cases: e.g., bandwidth constraints for specific SaaS, region-specific routing, or VoIP optimization.
• Traffic scope: destination allow-list (FQDN/IP/CIDR), ports, and protocols permitted outside the tunnel.
• Security controls on excluded traffic: DNS security, endpoint firewall, EDR, secure web gateway, or other inspection path.
• Prohibited conditions: admin access, privileged sessions, or sensitive data access over a split path.
• Approval authority and review cadence: who signs off, how often exceptions are revalidated.

Deliverable: a short standard (1–2 pages) plus an exception template.

Step 2: Establish “default deny split tunneling” for all remote access profiles

Your baseline configuration should route all client traffic through the controlled tunnel (full-tunnel) and enforce that policy centrally. ¹

Implementation tasks for your technical teams:

• Create or update VPN/ZTNA profiles to force tunnel all traffic.
• Ensure DNS resolution for organizational and internet traffic follows the intended security path (common failure point: DNS leaking outside the tunnel).
• Block user override (no “disconnect tunnel for local access,” no local route manipulation privileges).

Step 3: Implement exceptions as narrow, testable configurations

If you permit split tunneling, implement it as a constrained policy object with explicit routing rules, not an informal “we allow it for performance.” ¹

Hardening checklist for exceptions:

• Route only to explicitly approved destinations outside the tunnel.
• Use device posture requirements (managed device, healthy state) before applying an exception profile.
• Log when an exception profile is assigned, removed, or modified.
• Require ticketed approval with a business owner and security owner.

Step 4: Validate with testing that matches how assessors will test

Assessors will not accept “policy says no split tunneling” if they can reproduce it on a client device.

Validation methods you can institutionalize:

• Confirm route table behavior on a representative endpoint with the remote access client connected.
• Confirm DNS path and proxy path follow expected enforcement.
• Attempt to access a known internet destination and verify whether traffic egresses through your controlled environment (where applicable).

Step 5: Operational monitoring and drift control

SC-7(7) becomes fragile when remote access profiles drift, new regions are added, or an MDM baseline changes. Set up monitoring for:

• Remote access profile changes (config change control)
• Endpoint policy compliance status for VPN/ZTNA configurations
• Exceptions inventory (who has split tunneling enabled, why, and for how long)

Step 6: Assign ownership, cadence, and evidence capture

A common gap is “engineering did the work,” but GRC cannot prove it repeatedly.

Minimum operating model:

• Control owner (network/security engineering)
• Oversight owner (GRC/compliance)
• Monthly evidence pull (configs, exception list, and change log)
• Formal exception review and sign-off workflow

Daydream fit (earned mention): if you track controls and evidence in Daydream, map SC-7(7) to a named control owner, link the implementation procedure, and schedule recurring evidence collection so assessment readiness is not a scramble. ¹

Required evidence and artifacts to retain

Keep evidence that proves (1) enforcement, (2) exceptions are securely provisioned, and (3) ongoing operation.

Design & governance

• Remote access standard stating split tunneling is prevented by default, with defined exception criteria. ¹
• Exception template and approval workflow (ticketing or GRC workflow export).
• Network/security architecture diagram for remote access traffic flow (baseline and exception).

Technical enforcement

• VPN/ZTNA configuration exports/screenshots showing full-tunnel settings and locked-down client behavior.
• MDM/endpoint configuration policy showing users cannot alter routes or disable enforcement.
• Secure split-tunnel profiles (if any) with explicit allowed destinations.

Operational proof

• Current inventory of remote users/devices and which profile is assigned (baseline vs exception).
• Change management records for remote access profile modifications.
• Logs or reports demonstrating monitoring of remote access connections and policy compliance.

Common exam/audit questions and hangups

Expect these questions, and pre-package answers plus evidence:

• “Show me that remote clients cannot send internet traffic outside the tunnel.” Provide config plus a validation test record. ¹
• “Do any users have split tunneling enabled? Why?” Provide an exceptions register with approvals and expirations.
• “What does ‘securely provisioned’ mean here?” Provide your defined parameter, the technical implementation, and compensating controls. ¹
• “How do you prevent drift?” Provide change control, configuration monitoring, and periodic review evidence.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A written policy without enforceable settings fails quickly in testing. Fix: require config exports and endpoint validation artifacts.
2. Broad split tunnel rules. “Allow all internet direct” is split tunneling without secure provisioning. Fix: constrain by destination allow-list and document the rationale.
3. DNS leakage. Teams enforce full-tunnel routing but forget DNS, allowing direct resolver access. Fix: validate DNS path and block non-approved resolvers.
4. No exception lifecycle. Once split tunneling is granted, it never expires. Fix: time-bound exceptions with re-approval and automated reminders.
5. Third-party remote access blind spot. External support sessions bypass your standard client. Fix: require third parties to use managed jump hosts, VDI, or your controlled access path, and document any deviation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: SC-7(7) failures tend to surface during assessments, ATO/FedRAMP-style reviews, incident postmortems, and boundary-control testing. ²

Risk implications you can state precisely without inventing statistics:

• Split tunneling can reduce your ability to inspect, log, and block malicious traffic consistently across remote users.
• A compromised remote device can become a bridge between untrusted networks and organizational systems if traffic is not constrained.

Practical 30/60/90-day execution plan

30 days: Decide the stance and stop the bleeding

• Name control owner and approver for exceptions.
• Inventory remote access methods (VPN, ZTNA, VDI paths) and identify where split tunneling is currently possible.
• Set default remote access profiles to full-tunnel where you can do so without breaking mission-critical workflows.
• Draft the “securely provisioned split tunnel” exception standard and socialize it with network/security engineering. ¹

60 days: Implement enforceable controls and evidence capture

• Roll out baseline configurations broadly through your VPN/ZTNA and endpoint management tools.
• Implement constrained exception profiles and require ticketed approvals.
• Build recurring evidence exports: configs, exception list, and change logs.
• Run validation tests and store results as assessment artifacts.

90 days: Operationalize monitoring and tighten exceptions

• Put configuration changes under change control with clear rollback steps.
• Add drift detection: alert on policy/profile changes and on endpoints out of compliance.
• Review exceptions with stakeholders; remove or narrow ones that no longer have a justified need.
• In Daydream (or your GRC system), connect SC-7(7) to owners, procedures, and recurring evidence tasks so the control stays “alive” between audits. ¹

Frequently Asked Questions

Does SC-7(7) mean split tunneling is always forbidden?

No. It requires you to prevent split tunneling unless you have a “securely provisioned” split-tunnel design defined and enforced in your environment. ¹

What counts as “remote devices” for SC-7(7)?

Any device connecting from outside your controlled network boundary into organizational systems through remote access. In practice, this includes employee endpoints and managed endpoints used by third parties.

We use ZTNA instead of a traditional VPN. Is SC-7(7) still relevant?

Yes. The control outcome is about traffic paths from remote endpoints while connected to organizational systems, regardless of whether the technology is labeled VPN or ZTNA. ²

How do we justify an exception for performance or SaaS breakouts?

Document the business need, restrict the breakout to explicit destinations, and show compensating controls that make the split tunnel “securely provisioned” under your defined standard. Retain the approval and the technical policy artifact. ¹

What evidence is most persuasive to an assessor?

Configuration exports that show full-tunnel enforcement, an exceptions register with approvals, and a simple validation record showing observed routing/DNS behavior on a sample endpoint. ¹

How do we handle third-party support that “needs” split tunneling?

Prefer a controlled access pattern (jump host, VDI, managed device, or controlled remote access client). If you must allow an exception, time-bound it and constrain destinations and privileges.

Footnotes

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

2. NIST SP 800-53 Rev. 5