This practice is the middle piece of the remote access trio (AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.14). Where 3.1.12 is about monitoring and 3.1.13 is about encryption, 3.1.14 is about architecture. It’s asking: do you have a defensible network design where remote access doesn’t go directly to your CUI systems? The best small contractors use one of three patterns: VPN with internal firewall rules, RDP gateway in the DMZ with conditional access, or cloud-based jump host with IP whitelisting. The worst ones have VPN that dumps directly onto the corporate network with no further controls. This practice also connects to SC.L2-3.13.1 (system boundary) in defining how remote access relates to your CUI enclave.
The assessment room conversation is usually quick if you’ve thought about it. The assessor asks “walk me through the network path a remote user takes to reach CUI systems.” If you can draw a clean path with a control point in the middle, they move on. If you say “they VPN in and then access our server,” the assessor will ask whether the VPN is the only access path, whether firewall rules limit where they can go, and whether anyone’s verified those rules actually work.
What the assessor is actually evaluating
The NIST language is “route remote access through managed access control points.” The assessor is checking that you’ve thought about network topology as deliberate architecture with chosen tools. They want to see that the path from a remote user to a CUI system goes through something you can control and monitor.
This is partly about defense in depth. Even if someone compromises a remote user’s VPN credentials, additional network controls should prevent them from reaching every system on your network. It’s also about logging. If a jump host or gateway is the ingress point, you can log all remote access in one place.
The assessor will ask one of three ways. First, “walk me through the network path.” Second, “show me your network diagram.” Third, “what prevents a remote user from accessing systems other than what they need?” If you can’t answer clearly, expect a finding.
What a realistic SSP definition looks like
[Organization Name] routes all remote access through a managed access control point. Users connect to the corporate VPN, which terminates on a dedicated VPN gateway in the DMZ. From the VPN gateway, users access CUI systems through an RDP gateway or application server configured as an intermediary. Direct access from the VPN network to backend CUI systems is blocked by firewall rules.
Firewall rules restrict the VPN network to specific destinations: the RDP gateway, the application server, and a single internal file server used for CUI storage. All other systems are inaccessible to remote users. These rules are reviewed quarterly by the IT Director, and logs from the firewall are monitored to identify any unauthorized connection attempts.
Jump host configuration requires multi-factor authentication and logs all administrative sessions. Non-administrative remote access to the application server requires authentication through Entra ID and is logged in the application's audit log.
This language is doing several things. First, it names the managed access control points: “VPN gateway,” “RDP gateway,” “application server.” Second, it describes the restricted path: “only these destinations are accessible.” Third, it mentions review and monitoring: “rules are reviewed quarterly,” “logs are monitored.” That’s the complete picture the assessor wants to see.
How to present your evidence
- Network diagram showing remote access path and control points
- Firewall rules (ACLs) restricting remote access destinations
- Jump host or RDP gateway configuration
- Evidence that firewall rules are tested and enforced (e.g., failed connection attempt logs)
- Review records of firewall rules (dated audit showing rules were reviewed)
- If applicable, routing policy or network segmentation documentation
Have these ready:
Network diagram. This is your primary evidence for this practice. It should show remote users on the left, the VPN gateway or jump host in the middle, and backend CUI systems on the right. Lines should represent allowed paths. Blocked paths should be clearly marked as denied. This doesn’t need to be fancy, but it needs to be clear and match your actual network.
Firewall rules or ACLs. Pull up the firewall configuration showing rules that restrict where VPN traffic can go. If it’s a Cisco ASA or Fortinet Fortigate, you can export the ACL. If it’s a software firewall, show the inbound/outbound rules. The assessor wants to see rule names that match your SSP description and rule targets that match your network diagram.
Failed connection test. If you have firewall logs showing a connection attempt that was blocked, that’s gold. It proves the rules actually work. “Remote user on VPN network attempted to reach internal file server X, connection denied by rule Y.” That’s perfect evidence of the control working.
Jump host or gateway configuration. If you have a dedicated jump host or RDP gateway, show the configuration. This could be screenshots of the server’s network settings, installed software, or access control lists. It should be clear that this system is the intended path for remote access.
Review records. If you periodically review the firewall rules or access control lists, include that documentation. Even a dated email from the IT Director saying “reviewed firewall ACLs for remote access, confirmed they restrict traffic to approved destinations” is sufficient.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No intermediate control point. VPN dumps directly onto the internal network with no firewall rules or jump host. Remote users can access any system they authenticate to. The assessor will ask "what stops a remote user from reaching systems they shouldn't?" and "nothing, they're on the network" is the answer that creates a finding.
Vague or missing network diagram. The diagram doesn't clearly show the remote access path. It's unclear where the VPN terminates, what it connects to, or what rules apply. When the assessor can't understand your network from the diagram, they'll push for clarification.
Firewall rules that allow too much. Rules allow VPN traffic to reach any system, or allow it to the entire internal subnet. That's too permissive. Rules should be specific: "VPN to RDP gateway only" or "VPN to application server on port 443 only."
Rules documented but not actually enforced. The firewall config shows rules, but testing or logs show traffic is reaching restricted systems. Rules exist on paper but aren't actually applied. Test your rules before the assessment.
No review of rules or routing configuration. Rules were set up years ago and haven't been looked at since. If you can't show recent evidence of review, the assessor will question whether the controls are still appropriate.
A clear network diagram showing the remote access path through a managed control point. Specific firewall rules or network ACLs that restrict where remote traffic can go. Evidence (logs, testing results) showing the rules actually work. A review record confirming the rules are still appropriate. If you can walk the assessor through the network path and show the specific controls that restrict it, this practice closes quickly.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
Your MSP or MSSP typically manages the network infrastructure, firewall, and VPN. Your job is to define the remote access policy and ensure the network design reflects it.
What’s on you (the contractor):
- Defining which systems remote users should be able to reach
- Approving the network topology and firewall rules
- Periodically reviewing the rules to ensure they’re still correct
- Understanding and explaining the remote access path to the assessor
What’s on the MSP:
- Designing and implementing the network segmentation
- Configuring firewall rules and access control lists
- Testing that rules work as intended
- Providing documentation (network diagram, firewall config, access logs)
- Keeping rules updated as systems change
The assessor will usually ask you (the contractor) “walk me through the network diagram” because it’s your responsibility to understand and explain the architecture. Your MSP can then show the detailed firewall configuration and logs.
Assessors ask you to walk them through the network path a remote user takes to reach CUI systems. Have your network diagram ready and be able to explain it without technical jargon. Point out the control points, the firewall rules, and how traffic is restricted. If you get confused or can't explain the path clearly, the assessor will lose confidence in this control. Know your own network architecture. Understand which systems remote users can reach and which they can't, and be able to explain why.
Before the assessment, have your MSP walk you through the network diagram and firewall rules. Make sure you understand which systems are accessible to remote users and why. Then, in the assessment room, be the one who explains it. Your MSP can show the detailed config, but you should be able to draw or describe the path and the control points without hesitation. If you're confused about the network architecture during the assessment, the assessor will notice and will doubt the whole control. A 30-minute call with your MSP two weeks prior prevents this problem.
This page covers AC.L2-3.1.14 from NIST SP 800-171 Rev 2 (3.1.14). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.