CMMC Level 2 Practice 3.1.14: Route remote access via managed access control points

To meet CMMC Level 2 Practice 3.1.14, you must ensure all remote access into your CUI environment flows through managed access control points (for example, a VPN concentrator, ZTNA gateway, or bastion host you administer) where you can enforce authentication, authorization, and logging. Block or remove “direct” inbound paths that bypass those control points. ¹

Key takeaways:

• Centralize remote entry to the CUI environment through approved gateways you manage and monitor. ²
• Eliminate shadow remote paths (ad-hoc RDP/SSH exposure, unmanaged remote tools, split tunnels that bypass inspection) through technical controls and firewall policy. ²
• Keep assessor-ready evidence: network diagrams, remote access inventories, gateway configurations, and logs showing remote sessions traverse the control points. ³

CMMC Level 2 practice 3.1.14 is a network and access-control requirement with a simple assessor lens: “Show me where remote users enter the environment that processes, stores, or transmits CUI, and prove you control that entry.” The practice maps directly to NIST SP 800-171 Rev. 2 requirement 3.1.14 and is evaluated as part of demonstrating Level 2 alignment for DoD contracting. ⁴

Operationally, this requirement is less about which remote access product you buy and more about architecture discipline. Remote access must not be a collection of one-off exceptions; it needs to be a routed, inspectable path through managed control points where you can enforce MFA (where applicable in your program), session controls, and logging tied to identities. Your biggest failure mode is accidental: a business unit enables a remote support tool, a server gets exposed for “temporary” RDP, or a third party gets a direct path that bypasses your gateway. ²

This page gives you requirement-level implementation guidance you can hand to IT/SecOps, plus the evidence bundle a CMMC assessor will expect you to produce quickly. ³

Regulatory text

Regulatory excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.14 (Route remote access via managed access control points).” ⁵

Operator interpretation:
You must design remote access so that users (employees, admins, and third parties) cannot directly reach internal CUI systems from the internet or untrusted networks. Remote access must be forced through managed access control points that you operate, configure, and monitor (for example, a centrally managed VPN/remote access gateway, ZTNA broker, or jump/bastion host). Those control points become your enforcement location for authentication, authorization, session restrictions, and logging. ²

Plain-English meaning

• “Route remote access” means remote traffic must pass through a controlled chokepoint, not “connect however it’s convenient.” ²
• “Managed access control points” means devices/services you administer with standardized configuration, change control, and monitoring. A personal workstation running an ad-hoc remote tool is not a managed control point. ²

Who it applies to

Entities

• DoD contractors and subcontractors that handle CUI and need CMMC Level 2 alignment for contract eligibility. ⁶

Operational scope (what networks/systems)

Applies to any system, network segment, enclave, or cloud environment in your CUI boundary where remote users can initiate access, including:

• Remote workforce access into CUI apps, file shares, VDI, or SaaS admin consoles (if they are in-scope for CUI).
• Administrative access paths (SSH, RDP, console access, privileged web admin).
• Third-party support access (MSP, OEM, incident response retainers) that touches the CUI boundary. ²

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

Step 1: Define “remote access” for your environment

Create a working definition your teams can execute:

• Any access originating from outside trusted internal networks (home networks, mobile, partner networks, public internet).
• Any access that crosses a boundary where you do not control the network path end-to-end. Document this definition in your access control policy and your CUI boundary narrative. ¹

Step 2: Inventory every remote access path into the CUI boundary

Build a single list that includes:

• User remote access (VPN, ZTNA, VDI, remote desktop gateways).
• Admin access paths (bastions, PAM tools, cloud admin portals, emergency access).
• “Hidden” paths (remote support tools, port forwards, exposed management ports, supplier tunnels). Tie each path to an owner and a business justification. ²

Practical tip: ask for current firewall NAT rules, cloud security group rules, and endpoint management approved software lists. This catches paths nobody remembers.

Step 3: Choose and standardize your managed access control points

Common acceptable patterns (pick one primary pattern per environment to reduce drift):

• Central VPN gateway terminating remote access, with routing restrictions to only required subnets.
• ZTNA / identity-aware proxy that publishes only specific apps and logs per-request decisions.
• Bastion/jump host for administrative access, with no direct admin access to servers from the internet.
• VDI where remote endpoints never directly touch CUI systems; they reach a controlled desktop environment first. ²

Selection criteria you can defend to an assessor:

• You can enforce access decisions centrally.
• You can produce logs that show remote sessions traverse the gateway.
• You can manage configurations consistently (baselines, change approvals, periodic review). ³

Step 4: Technically force routing through those control points

This is where many programs fail: policy says “use VPN,” but the firewall still allows direct paths.

Do the blocking work:

• Remove inbound exposure for RDP/SSH/management ports from the internet into the CUI boundary.
• Restrict security groups/NACLs/firewall rules so that only the managed control points can reach protected subnets over admin and application ports.
• Disable split tunneling if it creates an unmanaged path that bypasses your monitoring expectations for in-scope access, or document compensating controls if split tunneling remains for defined reasons. ²

Step 5: Align identity, device, and session controls at the control point

At minimum, configure:

• Central authentication tied to your identity provider (for traceability).
• Role-based access to published apps/subnets.
• Session logging (connection start/stop, user identity, source IP/device, target resource).
• Administrative approvals for privileged remote access routes. ²

If your program also requires MFA for remote access (common in CMMC-aligned designs), enforce it at the gateway so you can prove consistent operation via configuration and logs. ³

Step 6: Implement third-party remote access governance

Treat third-party access as “remote access” by default:

• Provide third parties access only through your managed control point (ZTNA app publishing, VPN with strict ACLs, or a dedicated bastion).
• Time-bound and ticket-based access where practical.
• Require named accounts; avoid shared credentials.
• Log and review their sessions the same way you would for internal admins. ²

Step 7: Operationalize the control (so it stays true)

Make it hard to drift:

• Add a change gate: any new remote access method must go through security architecture review.
• Run a recurring remote exposure check: firewall rules, cloud security group audits, and endpoint software allowlists.
• Track exceptions with expiration dates and compensating controls. ³

Daydream fit (earned mention): Daydream-style control cards and evidence bundles help you keep this from becoming a “tribal knowledge” control by defining the owner, triggers (new site, new remote tool, new third party), and the minimum artifacts you will produce each cycle. ⁷

Required evidence and artifacts to retain

Keep an assessor-ready bundle that proves both design and operation:

Architecture and scope

• CUI boundary diagram(s) showing remote entry points and managed control points.
• Data flow diagram for remote access to in-scope systems.
• Inventory of remote access methods, including third-party access paths. ³

Configurations (snapshots or exports)

• VPN/ZTNA/bastion configuration showing:
  • Allowed routes/apps
  • Authentication settings
  • Logging enabled
• Firewall/security group rules proving only control points can reach protected subnets/ports. ²

Operational records

• Remote access logs demonstrating traffic passes through the control point (sampled over time).
• Change tickets/approvals for remote access rule changes.
• Exception register with approvals and expirations.
• Control health check records and remediation closures. ³

Common exam/audit questions and hangups

Assessors and customer reviewers tend to probe these points:

1. “Show me all remote access paths.” If you miss one, they will question your inventory discipline. ³
2. “Can a user RDP directly to a server?” A single exposed rule can negate your story. ²
3. “How do you handle third-party support?” Expect scrutiny on shared accounts, always-on tunnels, and unmanaged tools. ²
4. “Prove it’s enforced, not just written.” They will ask for config evidence and logs, not only policy. ³

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“We have a VPN, so we’re compliant.”	A VPN exists, but firewall rules still allow direct inbound access or lateral routes beyond need-to-know.	Restrict routing and enforce “gateway-only” access to protected networks. 2
Unmanaged remote tools (screen sharing, remote control apps) used for support	Traffic bypasses managed points and logging standards.	Standardize a single approved method routed through your control point; block or remove the rest. 2
Third-party always-on tunnels	Creates a permanent remote path with unclear accountability.	Time-bound, least-privilege access via bastion/ZTNA with named identities and logs. 2
No evidence of continuous operation	You can describe the design, but cannot show ongoing enforcement.	Establish recurring checks and retain logs, approvals, and review records. 3

Risk implications and enforcement context

No public enforcement cases were provided in the source catalog for this specific practice, so treat enforcement risk as contract and assessment driven. A failure here commonly indicates weak perimeter control over the CUI boundary: uncontrolled entry points raise the likelihood of unauthorized access, reduce your ability to investigate incidents, and can lead to a negative CMMC assessment outcome that affects DoD contract eligibility. ⁶

A practical 30/60/90-day execution plan

First 30 days: Identify and contain

• Assign a control owner (Security Architecture or SecOps) and document the standard remote access patterns allowed for the CUI boundary. ³
• Complete the remote access path inventory, including third-party methods. ²
• Block obvious direct exposures (public RDP/SSH, unmanaged inbound rules) and open break-glass exceptions only through documented approvals. ²

Days 31–60: Standardize and prove routing

• Consolidate to managed access control points (VPN/ZTNA/bastion/VDI) and retire redundant tools. ²
• Implement “gateway-only” network access rules so that protected subnets accept remote-originating traffic only from control points. ²
• Turn on and validate logging at the control point, then test by tracing a remote session end-to-end. Store evidence centrally. ³

Days 61–90: Operationalize and harden

• Add change control gates for any new remote access method, firewall change, or third-party connectivity request. ³
• Implement recurring control health checks (exposure scans, config drift reviews, access list reviews) with tracked remediation to closure. ³
• Package the assessor evidence bundle: diagrams, configs, sample logs, exception register, and review records. ³

Frequently Asked Questions

Does “managed access control point” have to be a VPN?

No. VPN is common, but ZTNA gateways, bastion hosts, and VDI can also qualify if they are centrally administered and enforce access decisions with logging. Your evidence must show remote access routes through that managed point. ²

We use a cloud provider. Does this requirement still apply?

Yes if your cloud environment is part of your CUI boundary. You still need controlled remote entry, typically by publishing access through an identity-aware gateway or restricting admin access to a bastion or approved management plane access methods you manage. ²

Can we allow split tunneling on the VPN?

Possibly, but you must ensure split tunneling does not create an unmanaged path that bypasses your control point for in-scope access. If you keep split tunneling, document the rationale and show compensating controls and monitoring that preserve enforcement intent. ²

How do we handle emergency vendor support at odd hours?

Pre-stage a controlled method: named third-party accounts, access via your managed control point, and a documented emergency approval workflow. Keep session logs and close out access after the support event. ¹

What evidence is most persuasive to an assessor?

A network diagram plus firewall/security group rules that prove only the managed control points can reach protected subnets, combined with logs showing actual remote sessions traversing those points. Policies help, but configuration and operational records carry the assessment. ³

We found one legacy server with direct remote access. Is that automatically a fail?

Treat it as a high-priority finding: remove the direct path, route access through the managed control point, and document corrective action with timestamps and approvals. Assessors focus on whether the control is designed and operating across the scope, and whether you can show remediation discipline. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; 32 CFR Part 170

5. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

6. 32 CFR Part 170; DoD CMMC Program Guidance

7. 32 CFR Part 170