Boundary Protection | Split Tunneling for Remote Devices

To meet the boundary protection | split tunneling for remote devices requirement, you must block split tunneling for remote devices that connect to your systems, unless you can prove the split tunnel is securely provisioned with defined safeguards. Operationally, that means enforcing “no local LAN / no concurrent internet path” in your VPN/ZTNA profiles by default, and tightly documenting any exception path. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Default stance: disable split tunneling for remote access sessions into organizational systems. (NIST Special Publication 800-53 Revision 5)
• If you allow split tunneling, you need explicit safeguards, technical enforcement, and evidence that the safeguards are applied. (NIST Special Publication 800-53 Revision 5)
• Auditors will look for device-scoped enforcement (MDM/EDR), not just a written policy.

Split tunneling is a remote access configuration where a user’s device sends some traffic through the corporate tunnel (to reach internal apps) while sending other traffic directly to the internet (or local networks) outside your monitored boundary. SC-7(7) treats that pattern as a boundary protection problem: your “remote device” becomes an unmanaged routing bridge between your environment and untrusted networks unless you deliberately control and secure it. (NIST Special Publication 800-53 Revision 5)

For a CCO or GRC lead, the fastest path to operationalizing SC-7(7) is to make one decision and then implement it consistently: (1) prohibit split tunneling for all remote connections, or (2) allow it only for defined use cases with defined safeguards that you can enforce and evidence. The control’s language is short, but the exam reality is not: assessors will test your actual VPN/ZTNA settings, your exception workflow, and whether remote endpoints are configured to prevent unsafe routing behavior. (NIST Special Publication 800-53 Revision 5)

This page gives you requirement-level guidance you can hand to network/security engineering, plus the artifacts you should collect for an audit-ready story.

Regulatory text

Requirement (verbatim excerpt): “Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using organization-defined safeguards.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation (what you must do):

1. Baseline: For remote devices connecting into your systems, configure remote access so traffic does not split between the protected tunnel and an uncontrolled path. (NIST Special Publication 800-53 Revision 5)
2. Conditional allowance: If you permit split tunneling for a specific scenario, you must (a) define safeguards, (b) enforce them technically, and (c) keep evidence that the safeguards are in effect for the covered users/devices. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation of the requirement

SC-7(7) is about preventing your remote access solution from turning endpoints into “dual-homed” gateways. With split tunneling enabled, an endpoint can talk to your internal environment while also maintaining a separate, direct path to untrusted networks. That increases the chance that malware, unsafe DNS resolution, browser-based attacks, or local network attacks can reach internal resources through the already-authenticated device session.

Your compliance obligation is binary in practice:

• Default deny: block split tunneling for remote connections into organizational systems.
• Exception with proof: if you allow it, document why, define safeguards, implement them, and retain evidence.

Who it applies to (entity and operational context)

Entities: Cloud service providers and federal agencies operating systems that adopt NIST SP 800-53 controls (including FedRAMP-authorized environments). (NIST Special Publication 800-53 Revision 5)

Operational contexts:

• Workforce remote access to cloud management planes, production admin consoles, jump hosts, corporate apps, and internal networks.
• Third-party remote access (contractors, support, MSPs) into your systems.
• Privileged remote sessions (admin access) where split tunneling creates high-impact exposure.
• Any environment where “remote device” includes laptops, VDI endpoints, mobile devices, or managed workstations that establish a tunnel to organizational systems.

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

Step 1: Declare your split tunneling stance (policy + technical standard)

Make a decision and write it down:

• Default: “Split tunneling is prohibited for remote devices connecting to organizational systems.” (NIST Special Publication 800-53 Revision 5)
• Exceptions: Define a short list of allowed use cases (if any), with required safeguards and approval authority.

Deliverable: a remote access standard (1–2 pages) that network/security can implement without interpretation debates.

Step 2: Inventory remote access paths and identify where split tunneling can occur

Build an inventory of:

• VPN concentrators and profiles
• ZTNA policies and client configurations
• VDI solutions (and whether the endpoint routes traffic)
• Privileged access tooling (bastions, session managers)
• Identity conditions (device compliance gates, per-app tunnels)

For each, note:

• Can this tool enable split tunneling?
• Where is it configured (console, MDM profile, client settings)?
• Who can change it (RBAC group)?

Step 3: Enforce “no split tunnel” in your baseline profiles

Give engineering explicit configuration targets. Examples of enforcement objectives (tool-agnostic):

• Force all traffic destined for organizational systems through the tunnel.
• Prevent simultaneous routing to local subnets while connected, unless explicitly approved.
• Restrict client ability to override routes.
• Apply the baseline to all standard remote access groups (workforce + third parties) unless exception-tagged.

What auditors want to see: settings screenshots/exports and a statement that “users cannot self-enable split tunneling.”

Step 4: If you allow split tunneling, define “organization-defined safeguards”

SC-7(7) requires safeguards if you permit split tunneling, but it leaves “safeguards” to you. (NIST Special Publication 800-53 Revision 5) Keep this practical and enforceable. A workable safeguard set usually includes:

Safeguard design checklist (pick what you can enforce):

• Device eligibility gate: split tunneling allowed only from managed, compliant devices (MDM posture checks; EDR present; disk encryption on).
• Traffic constraints: only specific destinations bypass the tunnel (for example, approved SaaS allowlist) while sensitive traffic remains tunneled.
• DNS control: require secure DNS handling aligned with your boundary strategy (avoid endpoint-resolved internal DNS outside the tunnel).
• No local subnet access while connected (or explicitly define which local subnets are allowed and why).
• Monitoring: log remote access sessions and policy decisions (who connected, from which device posture, which profile applied).
• Privileged separation: privileged admin sessions never use split tunneling (or require a separate hardened access path).

Write the safeguards as testable statements: “Split tunneling is permitted only for profile X; profile X requires device compliance signal Y and prohibits local subnet routes.”

Step 5: Implement an exception workflow that produces audit-grade proof

If exceptions exist, treat them like firewall rule exceptions:

• Request includes business justification, user group, device population, systems accessed, and compensating controls.
• Security review validates safeguards and confirms technical feasibility.
• Approval is time-bounded or event-bounded (for example, tied to a project or support window).
• Periodic review removes stale exceptions.

If you use Daydream to run third-party risk and access governance workflows, capture the exception record, approving authority, and the mapped safeguard evidence in one place so the audit packet is not spread across email, tickets, and VPN console screenshots.

Step 6: Validate with a test plan (don’t trust config)

Assessors often find “policy says no split tunneling” but the client still routes local traffic. Validate:

• Connect from a test device in the standard group and confirm traffic behavior matches your policy.
• Connect from an exception-tagged device and confirm only the intended split behavior occurs.
• Verify logs show the right profile/policy applied.

Step 7: Operationalize changes (change control + monitoring)

Put the relevant settings under:

• Change control (who can change split tunnel settings; documented approvals).
• Configuration monitoring (alerts when VPN/ZTNA profiles change).
• Access reviews (who is assigned the exception profile).

Required evidence and artifacts to retain

Keep artifacts that prove enforcement, not intent:

Policy & standards

• Remote access standard stating split tunneling stance and exception criteria. (NIST Special Publication 800-53 Revision 5)

Technical enforcement

• VPN/ZTNA configuration exports or screenshots showing split tunnel disabled for baseline profiles.
• MDM configuration profiles (if used) that enforce network/VPN settings on endpoints.
• Group membership evidence for who receives baseline vs exception profile.

Safeguards (if split tunneling permitted)

• Documented “organization-defined safeguards” and how they are enforced. (NIST Special Publication 800-53 Revision 5)
• Exception approvals, scope, and review history.

Logging & monitoring

• Sample logs proving remote sessions are captured and policy decisions are recorded (user, device, profile).

Common exam/audit questions and hangups

• “Show me where split tunneling is disabled in your remote access configuration.” Expect a live console walkthrough or exported config.
• “Can a user override routing locally?” Auditors probe client-side controls.
• “Which populations have split tunneling enabled, and why?” You need a clean list and business justification.
• “What are your organization-defined safeguards, and how do you test them?” SC-7(7) explicitly requires safeguards if you allow split tunneling. (NIST Special Publication 800-53 Revision 5)
• “How do you control third-party remote access?” Third parties are a common gap: unmanaged devices plus split tunneling is hard to defend.

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance. A written prohibition without enforced VPN/ZTNA profiles fails quickly in an assessment. Fix: retain config evidence and a validation test record.
2. Over-broad exceptions. Teams allow split tunneling “for performance” without defining safeguards. Fix: require safeguard mapping for every exception and block privileged use.
3. No device posture gating. Allowing split tunneling from unmanaged endpoints makes safeguards mostly theoretical. Fix: restrict split tunneling to managed, compliant devices or remove the exception.
4. Ignoring local subnet access. Split tunneling discussions often focus on internet traffic, but local LAN bridging is a major risk. Fix: explicitly prohibit local subnet access while connected unless justified and controlled.
5. No ownership of settings. Multiple admins can change VPN profiles without traceability. Fix: RBAC, change control, and config monitoring around remote access profiles.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SC-7(7) as an audit/authorization risk rather than a case-law-driven topic. The practical risk is still clear: split tunneling expands the attack surface and weakens boundary visibility for remote sessions. For FedRAMP-aligned programs, the main consequence is assessment findings, remediation burden, and delayed authorization if you cannot show enforced prevention or a tightly governed safeguard-based exception. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days (Immediate hardening)

• Decide the default stance: prohibit split tunneling unless exception criteria are met. (NIST Special Publication 800-53 Revision 5)
• Inventory all remote access paths and identify where split tunneling can be enabled.
• Disable split tunneling on baseline remote access profiles where technically feasible.
• Draft the exception template: justification, scope, safeguards, approval.

Next 60 days (Safeguards + governance)

• Define your organization-defined safeguards for any permitted split tunneling and map each safeguard to an enforceable mechanism. (NIST Special Publication 800-53 Revision 5)
• Implement device posture gating for any exception profiles.
• Put VPN/ZTNA profile changes under change control and restrict admin rights.
• Build an evidence packet: configs, sample logs, access group lists, exception records.

By 90 days (Assessor-ready operations)

• Run a validation test and document results for baseline and exception scenarios.
• Establish recurring reviews for exception groups and third-party remote access lists.
• Centralize artifacts (policy, configs, approvals, reviews) so audits do not depend on individual inboxes; Daydream can help keep exception approvals and evidence tied to the control narrative.

Frequently Asked Questions

Does SC-7(7) require that split tunneling is always disabled?

No. It requires you to prevent split tunneling unless the split tunnel is securely provisioned using organization-defined safeguards. (NIST Special Publication 800-53 Revision 5)

What counts as “organization-defined safeguards”?

Safeguards are the specific technical and procedural controls you define, enforce, and can evidence for any allowed split tunneling. They must be concrete enough for an assessor to verify in configuration and logs. (NIST Special Publication 800-53 Revision 5)

If we use ZTNA instead of VPN, does this still apply?

Yes. The requirement is about remote devices connecting to organizational systems and whether traffic can bypass protected paths. Your ZTNA client/policy must prevent unsafe concurrent routing or enforce safeguards for permitted split paths. (NIST Special Publication 800-53 Revision 5)

Can we allow split tunneling for third-party support vendors?

You can, but it is high-friction to defend in an assessment unless those third parties use managed, compliant endpoints and you can enforce safeguards. Many teams instead require a controlled access path (hardened jump host or managed VDI) to avoid endpoint routing risk. (NIST Special Publication 800-53 Revision 5)

What evidence is most persuasive to auditors?

Configuration evidence that shows split tunneling disabled by default, plus proof that users cannot override it. For exceptions, auditors want the safeguard definition, the technical enforcement mechanism, and an approval record tied to the affected user/device population. (NIST Special Publication 800-53 Revision 5)

We have performance issues when tunneling all traffic. Is that a valid reason to enable split tunneling?

It can be a business driver, but it does not remove the requirement. If you allow split tunneling for performance, document the justification and implement safeguards that are enforced and testable, then retain evidence that the exception is limited in scope. (NIST Special Publication 800-53 Revision 5)