CMMC Level 2 Practice 3.13.7: Prevent remote devices from simultaneously establishing non-remote connections with

To meet CMMC Level 2 Practice 3.13.7, you must stop remote endpoints (laptops, admin workstations, jump boxes) from being connected to your internal network while they are also connected to another network at the same time (for example, split-tunneling VPN or dual-homed connections). Operationalize this by enforcing network path controls in VPN/ZTNA, endpoint settings, and firewall rules, then retain proof the controls are enabled and monitored. ¹

Key takeaways:

• Disable or strictly control split tunneling and other dual-connection scenarios for remote endpoints that access CUI.
• Enforce the requirement with technical controls (VPN/ZTNA policy, endpoint firewall, NAC/conditional access), not just policy statements.
• Retain configuration evidence and testing results that show the control is operating for in-scope users and devices. ¹

The target keyword for this requirement page is: cmmc level 2 practice 3.13.7: prevent remote devices from simultaneously establishing non-remote connections with requirement.

Practice 3.13.7 is a practical network-path control. Assessors look for whether your remote devices can “bridge” networks (intentionally or accidentally) while accessing your environment that stores, processes, or transmits CUI. The classic failure mode is split tunneling: a laptop connects to your corporate VPN while still reaching the public internet directly or staying connected to home Wi‑Fi in a way that permits traffic to flow between networks. Another common issue is a dual-homed workstation (wired plus Wi‑Fi, or two active NICs) that creates an unmonitored path around security controls.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize 3.13.7 is to: define your in-scope remote access methods, pick a technical enforcement pattern (full-tunnel VPN, ZTNA with strict egress control, or equivalent), then prove it works with configuration exports and a small set of repeatable test cases. This practice is mapped to NIST SP 800-171 Rev. 2 and is assessed under CMMC Level 2 expectations. ^{1 2 3}

Regulatory text

Provided excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.7 (Prevent remote devices from simultaneously establishing non-remote connections with).” ^{1 3}

Operator interpretation: If a device is remotely connected into your environment (VPN/ZTNA/remote desktop to an internal host), you must prevent that same device from also maintaining an additional, non-approved network connection that could route traffic outside your managed security boundary. Your goal is to eliminate “bridge” paths that bypass inspection, logging, or policy enforcement. ¹

Plain-English interpretation (what the requirement means)

You are controlling simultaneous connections. A remote user device should not be able to:

• Connect to your corporate network (or enclave) and
• Keep a second active path to another network that is not controlled by you (home network, coffee shop network, cellular hotspot, public internet path that bypasses your VPN/ZTNA controls)

In practice, you implement this by forcing one of these outcomes for in-scope remote access:

1. All traffic goes through the approved remote access channel (common: full-tunnel VPN), or
2. Only tightly controlled destinations are reachable while remote-access is active, with strong endpoint/network enforcement that prevents alternative routing.

This requirement is less about user intent and more about the technical reality: dual connections create routes around your monitoring stack and can enable data exfiltration, command-and-control, or lateral movement. ¹

Who it applies to (entity and operational context)

Applies to organizations pursuing CMMC Level 2 that handle CUI for the DoD supply chain, and any environment segment where CUI is accessed remotely. ^{2 3}

In scope, typically:

• Corporate- or enclave-joined laptops that access CUI repositories
• Privileged admin workstations used to manage CUI systems
• Jump hosts used for remote administration into the enclave
• Remote access infrastructure (VPN concentrators, ZTNA gateways, bastions)
• Users and third parties with remote access into in-scope systems (for example, outsourced IT support), if allowed by your boundary design

Often out of scope (only if your boundary and access model truly exclude CUI):

• Devices that never access CUI systems and are technically blocked from doing so
  Your scoping decision must be defensible and documented for assessment under your CMMC Level 2 boundary approach. ³

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

Step 1: Identify all “remote devices” and remote access methods

Create a simple inventory view for:

• Remote access technologies: VPN, ZTNA, VDI, remote desktop gateways, SSH bastions
• Device types: managed laptops, BYOD (if permitted), admin workstations, third-party support endpoints
• Network paths: home Wi‑Fi, cellular, guest Wi‑Fi, wired plus Wi‑Fi combinations

Deliverable: “Remote Access Data Flow + Device Population” worksheet that names each method, device group, and what systems they reach.

Step 2: Choose an enforcement pattern (pick one primary model)

Use a decision matrix and document the rationale.

Pattern	What you enforce	Where it works well	Typical assessor risk
Full-tunnel VPN	All traffic from remote device routes through VPN	Traditional remote work, strong central monitoring	Misconfigurations that allow split tunnel
ZTNA with strict egress control	Only specific apps/destinations allowed; block other routing	App-centric access, managed endpoints	Harder to evidence if controls are scattered
VDI-only for CUI	Endpoint never directly touches CUI; access via virtual desktop	Strong containment model	Requires tight controls on copy/paste, downloads, and identity controls (separate practices)

You can combine models, but assessment is easier when one model is standard for CUI access and exceptions are rare and documented. ¹

Step 3: Disable split tunneling (or prove an equivalent control)

For in-scope users/devices, configure your remote access so the device cannot maintain an unmonitored parallel network path.

Common control implementations (choose those that match your architecture):

• VPN policy: force full-tunnel for CUI access profiles; restrict routes
• Endpoint configuration: block IP forwarding and bridging; restrict dual NIC behavior where feasible
• Conditional access: only allow remote access from compliant, managed endpoints
• Network controls: prevent direct outbound internet access from the VPN-assigned address space except via approved egress stacks, if that is your model

Document the exception process if any business case requires split tunneling. For CMMC readiness, treat exceptions as high scrutiny and make them temporary, time-bound, and approved with compensating controls. ¹

Step 4: Prevent dual-homing and bridging at the endpoint

Assessors often probe “Can the laptop be on VPN and also have another active adapter?” Your technical controls should address:

• Wired + Wi‑Fi simultaneously
• Wi‑Fi + cellular simultaneously
• Virtual adapters created by tools that can create alternate routes

Practical measures:

• Endpoint management baselines that restrict network sharing/bridging features
• Host firewall rules to prevent inbound connections from untrusted networks while VPN/ZTNA is connected
• Detection: alert on multiple active network interfaces for in-scope device groups

Step 5: Add monitoring and a repeatable test procedure

You need proof the control operates.

Create tests your team can run on demand:

• Connect a test laptop to home Wi‑Fi, establish VPN, attempt to reach the internet directly and validate traffic routes per your policy
• Attempt to enable split tunneling or add a second route; confirm it is blocked
• Attempt to keep Wi‑Fi and Ethernet active; confirm policy outcome (one disabled, or traffic constrained)

Run these tests after changes to VPN, endpoint baselines, or remote access tooling, and store results. ¹

Step 6: Map the control to CMMC assessment expectations and keep evidence current

This practice fails frequently due to “we do it” without proof. Tie your implementation to:

• A named control owner (IT/SecOps)
• A system boundary statement (what devices and users are in scope)
• A recurring evidence capture routine (config exports + sample device checks)

Daydream fits naturally here by turning the requirement into an owned control with an evidence schedule, so you do not rebuild screenshots and exports during the assessment rush. ³

Required evidence and artifacts to retain

Keep evidence that shows design + implementation + operation:

Design / intent

• Remote access standard (full-tunnel vs ZTNA vs VDI model) approved by security leadership
• CUI boundary / enclave narrative showing how remote access enters the boundary ³

Implementation (configuration proof)

• VPN/ZTNA configuration exports showing split tunneling disabled for in-scope profiles, or equivalent routing restrictions
• Endpoint management baseline snippets that show network bridging/forwarding restrictions and host firewall posture
• Conditional access policies that limit remote access to compliant devices (if used)

Operation (ongoing proof)

• Change tickets for remote access policy updates
• Monitoring alerts or reports that detect prohibited multi-homing or route changes
• Test scripts and recent test results demonstrating expected behavior

Evidence should be attributable (date, system, owner) and reproducible. ¹

Common exam/audit questions and hangups

Expect assessors (or internal auditors) to ask:

• “Show me your VPN policy. Is split tunneling disabled for CUI access?”
• “Demonstrate from a laptop that internet traffic is forced through your corporate stack while connected.”
• “How do you prevent a user from being on VPN over Ethernet while also connected to Wi‑Fi?”
• “Do admins use a different remote access method than standard users? Show me controls for privileged endpoints.”
• “What is your exception process, and how many exceptions exist?”

Hangup to avoid: answering with a policy statement only. This practice is validated through technical configuration and observable behavior. ¹

Frequent implementation mistakes and how to avoid them

1. “Split tunneling is disabled” with no scoping clarity
   Fix: show the exact user/device groups tied to CUI access profiles, and prove those profiles enforce the restriction.

2. Only controlling VPN, not other remote paths (remote desktop gateways, third-party tools)
   Fix: inventory remote access paths and explicitly ban or control unapproved remote connectivity methods for in-scope systems.

3. Relying on users to “not do that”
   Fix: enforce via endpoint and network policy. Training supports, but does not satisfy, 3.13.7 by itself. ¹

4. Exceptions that become permanent
   Fix: require security approval, add compensating controls, log the exception, and review it on a defined cadence you can defend.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so you should treat enforcement expectations as assessment-driven under the CMMC Program rather than case-law driven. ^{2 3}

Risk-wise, the issue is straightforward: simultaneous connections can create unmanaged pathways around your boundary controls, reducing your ability to detect and contain incidents affecting CUI. If you cannot prove enforcement and monitoring, you risk a CMMC assessment finding that blocks Level 2 certification eligibility for applicable contracts. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and pick enforcement)

• Confirm the CUI boundary and list all remote access methods that touch it. ³
• Decide your primary enforcement pattern (full-tunnel VPN, ZTNA, VDI-only) for CUI access.
• Identify user/device groups in scope and remove informal remote access paths.

Days 31–60 (implement and validate)

• Implement VPN/ZTNA policy changes for in-scope profiles (disable split tunneling or implement equivalent routing constraints). ¹
• Deploy endpoint baseline changes to restrict bridging/forwarding and reduce dual-homing risk.
• Create a test procedure and capture first test evidence.

Days 61–90 (operationalize evidence and exceptions)

• Stand up monitoring/alerting for prohibited patterns (multi-interface, route anomalies, policy drift).
• Formalize the exception process and require compensating controls documentation.
• Set a recurring evidence capture routine (config exports + test runs) and store it in your GRC system (Daydream or equivalent) with control owner attestations. ³

Frequently Asked Questions

Does 3.13.7 mean we must fully disable internet access while on VPN?

Not necessarily. You must prevent simultaneous non-approved network connections that create alternate routes around your controls; many teams meet this by forcing traffic through a controlled egress path via full-tunnel VPN. ¹

Is split tunneling always prohibited for CMMC Level 2?

The practice requires preventing simultaneous connections that undermine boundary control. The most defensible approach for CUI access is to disable split tunneling for in-scope profiles, or document an equivalent technical control and prove it works. ¹

How does this apply if we use ZTNA instead of VPN?

You still have to prevent the endpoint from maintaining an ungoverned parallel path that bypasses your policy and monitoring. Your evidence should show ZTNA policy enforcement, endpoint posture controls, and test results that demonstrate constrained connectivity for in-scope access. ¹

Do we need to block Wi‑Fi when Ethernet is connected?

You need to prevent dual connectivity from creating an unmanaged bridge while the device is remotely connected to the environment. Some organizations disable one adapter; others enforce routing and firewall controls plus monitoring. Keep proof of whichever approach you choose. ¹

What evidence is strongest for assessors?

Configuration exports from the remote access system (showing split tunneling disabled or constrained routes) plus a live or recorded test from a representative device. Pair that with endpoint baseline settings and logs/alerts that show ongoing operation. ¹

How should we handle third-party remote support?

Treat third-party access as in scope if it can reach CUI systems. Route it through approved remote access methods, apply the same simultaneous-connection restrictions, and require documented approvals and monitoring for any exceptions. ³

Footnotes

1. NIST SP 800-171 Rev. 2

2. 32 CFR Part 170

3. DoD CMMC Program Guidance