CMMC Level 2 Practice 3.1.20: Verify and control/limit connections to and use of external systems

To meet CMMC Level 2 Practice 3.1.20, you must (1) identify what “external systems” can connect to your CUI environment, (2) verify those connections are approved and authenticated, and (3) technically restrict everything else with enforceable controls and logs. Treat this as a boundary-and-exceptions control with recurring evidence. ¹

Key takeaways:

• Define and document “external systems,” connection types, and approval criteria for your CUI boundary. ¹
• Enforce allow-listing and strong authentication for external connectivity; block or isolate everything else. ¹
• Build assessor-ready evidence: diagrams, configurations, approvals, and connection logs tied to recurring reviews. ²

cmmc level 2 practice 3.1.20: verify and control/limit connections to and use of external systems requirement is where many programs fail in practice, not because teams lack tools, but because they lack crisp scope, a decision rule for what is allowed, and durable evidence that controls stay enforced over time. Under CMMC Level 2, this practice maps to NIST SP 800-171 Rev. 2 control 3.1.20, so assessors will expect you to show both (a) the policy decision (“which external systems can connect, under what conditions”) and (b) the technical reality (“we actually block everything else, and we can prove it”). ¹

Operationally, “external systems” includes more than third-party vendors. It also includes employee-owned devices, partner networks, cloud services outside your authorized boundary, remote administration endpoints, and any system not under your organization’s continuous control. Your job is to prevent quiet pathways into CUI: unmanaged VPN tunnels, ad hoc remote tools, shadow SaaS sync clients, and “temporary” file transfer workarounds that become permanent. ¹

This page gives requirement-level implementation guidance you can execute quickly: what to decide, what to configure, what to log, and what to retain for a CMMC assessment. ²

Regulatory text

Regulatory excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.20 (Verify and control/limit connections to and use of external systems).” ¹

Operator meaning:
You must only permit connections between your CUI environment and external systems when you have verified the connection is authorized and you can enforce limits on how that external system connects and what it can do. You also need to prevent and detect unapproved connections in day-to-day operations, not just on paper. ¹

How this shows up in an assessment: CMMC Level 2 assessments evaluate whether your NIST SP 800-171 practices are implemented and producing objective evidence, as part of the CMMC Program structure. ³, ²

Plain-English interpretation

Implement an “allow only what we approve” model for any connection into (or out of) the CUI boundary. Verification means you can identify who/what is connecting and confirm it meets your conditions (approved purpose, approved method, approved identity, and approved security posture). Control/limit means you restrict network paths, authentication, protocols, and access rights so the external system can only do what you intended. ¹

What counts as an “external system” in practice

Use a pragmatic definition that matches how your environment operates:

• Non-corporate endpoints: BYOD laptops, personal phones, home PCs used for remote access.
• Third-party systems: supplier portals, MSP tooling, outsourced helpdesk remote tools, cloud file transfer services.
• Partner/customer networks: site-to-site links, shared enclaves, joint engineering environments.
• Non-authorized cloud services: SaaS not approved for CUI workflows, personal cloud storage sync.
  Your definition should map back to whether the system is outside your controlled authorization boundary for CUI. ¹

Who it applies to

Entity types: Defense contractors and federal contractors handling CUI who are pursuing or required to meet CMMC Level 2. ³

Operational context: Any environment where CUI is stored, processed, or transmitted, including networks, endpoints, and cloud workloads within the CUI boundary. This practice matters most where remote work, third-party support, and cloud collaboration intersect with engineering data, program management data, or controlled technical information that is treated as CUI. ²

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

Step 1: Define the CUI boundary and the connection policy (decision layer)

1. Document the CUI boundary (systems, subnets, cloud tenants, identity providers, and managed endpoints). Keep it consistent with your SSP. ¹
2. Define “external system” for your program and list examples that matter in your environment (BYOD, contractor laptops, MSP tools, non-approved SaaS). ¹
3. Set approval criteria for any external connection, such as:
   • Business purpose and data types permitted
   • Approved connection methods (VPN, ZTNA, VDI, managed file transfer)
   • Required authentication (MFA, device certificates, conditional access)
   • Minimum security requirements (managed device, patch level, EDR present)
   • Logging requirements and review cadence
     Put this in an “External Systems Connectivity Standard” referenced by policy. ¹

Step 2: Build an allow-list of approved external connections (inventory layer)

1. Create a register of approved external systems and connection paths:
   • External system name/owner (third party or internal business unit)
   • Connection type (remote access, API, SFTP, support tool, email relay)
   • Target assets inside boundary
   • Authentication method and authorization scope
   • Approver and expiration/renewal trigger
2. Tie each entry to a risk acceptance or security review outcome (even lightweight) so approvals are defensible. ¹

Step 3: Enforce technical controls to block everything else (control layer)

Your controls should make “unapproved” connections fail by default.

Common technical patterns assessors understand:

• Remote access: Centralize through approved VPN/ZTNA or VDI; require MFA; restrict to managed devices; disable split tunneling if it creates uncontrolled pathways into/out of the boundary where feasible for your architecture. ¹
• Network segmentation: Restrict inbound/outbound flows from the CUI enclave to only approved destinations and ports; implement egress controls rather than relying only on perimeter ingress rules. ¹
• Third-party support: Force vendor/third-party admin access through a controlled jump host or privileged access path with session logging; prohibit ad hoc remote-control tools. ¹
• Cloud access: Use conditional access policies that enforce compliant devices and named locations; restrict OAuth app consent and API access to approved integrations only. ¹
• Data movement controls: Control file transfer methods (managed file transfer, approved collaboration platforms in boundary); block unsanctioned sync clients and consumer storage. ¹

Step 4: Verify continuously (detection + review layer)

Verification is not a one-time approval. You need ongoing proof that:

• Connections remain limited to the allow-list
• New external connections are detected and triaged
• Exceptions are time-bound and reviewed

Implement:

1. Central log collection for remote access, firewall/secure web gateway, IdP sign-ins, and key admin tools. ¹
2. Alerting or reports for suspicious or new external connection attempts (new geographies, new devices, new third-party tools, unusual ports/protocols). ¹
3. A recurring review workflow: review approved external connections, validate owners and necessity, and remove stale access. Capture evidence each cycle. ²

Step 5: Operationalize approvals and exceptions (workflow layer)

Create a lightweight intake:

• Requester describes external system, purpose, and data involved (CUI or not)
• Security reviews against your criteria
• Approval recorded with owner, scope, and expiration
• Implementation ticket links to firewall/IdP/PAM changes
• Post-change validation step (screenshots + test results) This is where tools like Daydream fit naturally: map 3.1.20 to a documented control, assign owners, and automate recurring evidence capture so you are not rebuilding artifacts right before assessment. ²

Required evidence and artifacts to retain

Keep evidence that shows both design and operating effectiveness:

Core documents

• System Security Plan (SSP) references for boundary and external connectivity rules. ¹
• External Systems Connectivity Policy/Standard (approval criteria, allowed methods, prohibited methods). ¹
• Network and data flow diagrams showing external ingress/egress points. ¹

Registers and approvals

• Approved external systems / connectivity allow-list with owners and approval records.
• Exception register with justification, compensating controls, expiration, and sign-off.

Technical configurations (exported or screen-captured)

• Firewall/segmentation rules demonstrating allow-listing and blocked outbound where applicable.
• VPN/ZTNA/VDI configuration showing MFA and device restrictions.
• IdP conditional access policies for external access and third-party app controls.
• Privileged access workflow for third-party admin sessions (jump host/PAM settings).

Operational evidence

• Sample logs for external connection attempts and successful sessions.
• Review meeting notes or tickets from periodic access/connection review.
• Incident tickets showing response to unapproved connection attempts (even if benign).

Common exam/audit questions and hangups

Assessors commonly probe:

• “Show me all paths from the internet or external networks into the CUI boundary.” Be ready with diagrams plus actual rule sets. ¹
• “How do you define external systems, and how do you approve them?” A written standard plus an approvals register answers this. ¹
• “How do you know a third party’s remote tool isn’t being used?” You need explicit prohibitions and technical blocks, not verbal assurances. ¹
• “What happens when someone needs a new connection fast?” If the process is too slow, teams bypass it. Show an expedited but controlled workflow and time-bound exceptions. ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“Policy says only approved systems,” but no allow-list exists	No objective evidence of what’s approved	Maintain a connectivity register with approvers and scope
Over-focus on inbound firewall rules	Many data exfil and tool callbacks are outbound	Add egress controls and web controls aligned to the boundary
Third-party remote support is “handled by IT” with no guardrails	Remote tools create hidden external systems	Require controlled jump host/PAM, block unauthorized tooling
BYOD allowed for convenience	You cannot verify/maintain posture	Require managed devices or VDI with strong controls
Evidence is reconstructed before assessment	Gaps appear in logs and approvals	Set recurring evidence capture; Daydream-style control mapping helps 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases. The practical risk is straightforward: uncontrolled external connections are a primary path for unauthorized access, data spill, and loss of CUI control, which can trigger contractual and assessment consequences under the CMMC program structure. ³, ²

Practical execution plan (30/60/90-day)

Timeboxed phases help, but avoid treating them as deadlines. Use them as sequencing.

First 30 days (stabilize scope and stop the bleed)

• Confirm the CUI boundary and enumerate all external connectivity points (remote access, inbound services, cloud admin, third-party tools). ¹
• Publish an external connectivity standard: allowed methods, approval criteria, and prohibited tools. ¹
• Stand up a single approval workflow and start the allow-list register.

Days 31–60 (enforce allow-listing)

• Implement or tighten MFA and conditional access for all remote access into the boundary. ¹
• Reduce external pathways: decommission legacy VPNs, block unsanctioned remote-control tools, restrict outbound to known business needs where feasible. ¹
• Implement third-party privileged access via controlled jump paths with session logging. ¹

Days 61–90 (prove it runs and retains evidence)

• Centralize logs required to show verification (IdP, VPN/ZTNA, firewall/egress, admin sessions). ¹
• Run the first periodic review of approved external connections; record outcomes and removals.
• Package assessor-ready artifacts (diagrams, configs, registers, sample logs). Track them in Daydream to keep evidence current between reviews. ²

Frequently Asked Questions

Does “external systems” include employee home networks and personal devices?

Yes, if they are used to access the CUI boundary or handle CUI workflows, they function as external systems. Your policy and technical controls should either prohibit them or force access through a verified, controlled method like managed devices or VDI. ¹

We use cloud SaaS tools. Are those “external systems”?

If the SaaS is outside your defined CUI boundary or not approved for CUI, treat it as an external system. The control expectation is clear approval, controlled connectivity, and technical enforcement to prevent ad hoc CUI movement. ¹

What does “verify” mean for an external connection?

Verification means you can identify and authenticate the connecting user/system and confirm the connection is approved and meets your conditions (method, device posture, and authorization scope). Logs and policy-backed approvals are your proof. ¹

Do we need to block all outbound internet access from the CUI enclave?

The requirement is to control and limit external connections, not to mandate a total block. Many teams implement restrictive outbound rules plus web controls to ensure only approved destinations and services are reachable. ¹

How do we handle urgent third-party support sessions without breaking compliance?

Pre-approve the third party access method (jump host/PAM), require MFA, and record sessions. For true emergencies, allow a time-bound exception with documented approval and a post-event review. ¹

What evidence is most persuasive to an assessor for 3.1.20?

A connectivity allow-list, diagrams showing ingress/egress points, and exported configurations that enforce restrictions are usually decisive. Pair that with logs and records of recurring reviews to show the control operates over time. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170