AC.L2-3.1.14 Remote access routing: requirements and evidence

What AC.L2-3.1.14 remote access routing requires in CMMC Level 2

AC.L2-3.1.14 requires that all remote access to a CUI environment pass through managed access control points. The organization must identify and implement those points, then route every remote session through them so that no user, administrator or vendor reaches the system by a side door. For a compliance lead with remote staff and a SPRS score to defend, the practical question is whether the organization can list every remote entry point and show an assessor that each one funnels through a small, documented set of gateways. The risk is the scattered entry point. A forgotten VPN concentrator on an old firewall, a cloud administration console reachable from any address, or a vendor tunnel set up for a single project can each bypass the controls the organization built elsewhere. These paths often exist because someone needed access during an outage and nobody removed the route afterward. Because AC.L2-3.1.14 is a 1-point requirement under 32 CFR 170.24, it is not on the list of requirements that cannot be placed on a POA&M, but a missing route still undermines the case that remote access is controlled, which matters for AC.L2-3.1.12 (control remote access) and AC.L2-3.1.13 (remote access confidentiality).

Start with discovery. Export firewall rules, VPN configurations, cloud security group settings, identity provider application lists and vendor access records, then compare them against the managed points the organization intends to use. Ask your administrators and your managed service providers, in writing, whether they hold any remote access path that is not on that list. Confirm with your assessor which evidence they expect for the two assessment objectives in NIST SP 800-171A, including the list of managed points, the remote access procedures and the configuration settings that prove routing. Where a vendor or cloud provider controls the path, document the responsibility split before you rely on it.

Which remote paths and systems fall under routing for CUI

AC.L2-3.1.14 applies to remote entry points into the environment that stores, processes or transmits CUI, so the scoping work starts by listing every path a person or process can use to reach that environment from outside it. The cards below cover the paths most often missed, and each one should be checked against the boundary and remote access sections of the system security plan.

User VPN and gateway paths

Staff who work from home or travel usually reach the CUI environment through a VPN concentrator, a zero trust gateway or a remote desktop broker. Each of these is a remote access point that must be managed, so confirm which gateways exist, which network segments they reach and whether any user can connect through a path nobody documented. Routing all user sessions through a small, named set of entry points is what makes monitoring practical.

Administrator and privileged access

Administrators often connect through jump hosts, bastion servers or direct SSH and console tools that bypass the standard user gateway. Assessors look for these privileged paths because they carry the most risk. Confirm whether administrative sessions also pass through the managed access points, and list any emergency or break-glass route separately so it can be controlled and logged.

Vendor and third-party connections

Managed service providers, software vendors and support engineers who connect into the CUI environment are remote users in practice. Identify each third party, the account it uses and the route it takes in. Connections that reach CUI from outside the assessment scope also raise questions under AC.L2-3.1.20, so treat them as in scope for this requirement until the system security plan states otherwise.

Remote maintenance tools

Remote support tools such as remote desktop applications, screen sharing services and vendor diagnostic agents can open a path into a system without going through the gateway. Inventory these tools on servers, workstations and network devices, and decide which ones are permitted to route through managed points. Unapproved remote control software is a common finding because it creates an access path nobody monitors.

Cloud email and hosted infrastructure

Access to cloud email, collaboration platforms or hosted infrastructure that holds CUI is remote access even when no VPN is involved. Assessors expect the same routing decisions here, so confirm whether these services are reached through a managed access point, conditional access controls or a documented exception. Check the cloud environment boundary in the system security plan to see whether these services fall inside the assessed scope.

Confirm scope against the SSP

Each path above should appear in the system security plan with its owner, the access points it uses and the systems it reaches. Where the plan and the network disagree, the network is the evidence assessors test, so reconcile them before the assessment. A current diagram that marks every remote entry point is the fastest way to show the scope is complete.

How an assessor tests remote access routing

This table compares the two assessment objectives that NIST SP 800-171A sets for AC.L2-3.1.14, showing how an assessor tests each one, what evidence to prepare and where assessments usually stall. Read each row as a checklist of what to have ready before the assessor arrives, since both objectives must be satisfied for the requirement to be MET.

Assessment objective	How the assessor tests it	Evidence to prepare	Common findings
Managed access control points are identified and implemented	Examine the documented list of managed network access control points, then confirm each one exists and is configured as described in the system security plan	Inventory of every managed access control point, system security plan entries, configuration exports, and change records showing when each point was added	Points named in the plan but missing from the live environment, or points running with default or unreviewed settings
Remote access is routed through the managed access control points	Review remote access procedures, then test whether a remote session actually traverses a managed point by tracing a sample connection end to end	Remote access procedures, network diagrams showing the routing path, firewall or gateway rule sets, and audit records from sample remote sessions	A remote path that bypasses the managed points, such as a vendor tunnel, a cloud admin portal or a legacy VPN left enabled outside the inventory
Scope of remote access paths	Ask the organization to enumerate every route into the CUI boundary, then check each route against the managed point inventory	Documented list of all remote entry paths, including cloud consoles and hosted services that hold CUI, with owners for each path	Remote paths discovered only during testing, often from shadow IT, emergency access accounts or third-party support connections
Monitoring of routed sessions	Check that audit records from managed points show remote sessions, and that a sample of records can be traced to a user or device	Sample audit records from each managed point, log retention settings, and documentation of who reviews them	Logs that are enabled on some points only, or records that cannot be linked to an individual session

How to implement managed remote access points step by step

This sequence turns scattered remote access into a short, documented list of managed access control points that every remote session must pass through. The output is evidence an assessor can test against the AC.L2-3.1.14 assessment objectives.

Inventory every remote path into the CUI boundary
Start by listing every way a session can reach systems that store, process or transmit CUI from outside the boundary. Include VPN concentrators, remote desktop and jump hosts, administrative consoles, vendor access, cloud management portals, and access to hosted email or infrastructure. Owners are usually the network and IT teams, with the security lead reviewing the list. The step is done when the inventory is signed off and each path has an owner, a protocol and a business reason. Confirm that the inventory also covers paths added informally, such as a vendor tunnel someone set up years ago.
Decide the small set of managed access points
Choose the minimum number of gateways that will carry all remote access, such as a VPN concentrator, a bastion host or a reverse proxy in front of internal applications. Record each point's address, its purpose, its administrators and its change owner in an approved point list. Keeping the list short makes it easier to monitor and to show an assessor that nothing bypasses it. The step is done when the approved list is reviewed and accepted by the system owner and the security lead, and it is referenced in the system security plan.
Route each remote path through the managed points
Reconfigure each inventoried path so that sessions terminate at, or pass through, an approved access point. This often means moving vendor access, admin tools and cloud management traffic behind the same gateway, and removing direct port forwards or dual-homed hosts. Document the change in the configuration record. The step is done when a test session from each remote path shows it entering through an approved point and no alternative route is available.
Block all other remote routes with firewall rules
Write rules that permit remote traffic only to and from the approved access points and deny everything else that crosses the boundary. In a stateful packet filter such as OPNsense, this means source and destination aliases for the approved points and explicit block rules with logging enabled. Keep the rule set and its rationale in version control or a change record. The step is done when the exported rule set matches the approved point list and the rules are visible in the firewall configuration review.
Add inspection and protection at the access points
Where the managed points publish web applications, place inspection in front of them to filter attacks such as SQL injection and cross-site scripting. For example, a web application firewall such as Coraza can run OWASP Core Rule Set rules through a supported proxy. This is an illustrative control, not a requirement of 3.1.14 itself, and its rule tuning should be tested before it blocks legitimate traffic. The step is done when protection is enabled and documented, and the rule version and mode are recorded.
Configure logging and monitoring of every remote session
Enable session logs at each access point and at the firewall, capturing the user or device identity, source, destination, protocol, time and result. Forward the logs to the central audit store and set review responsibilities. Confirm that blocked attempts are logged too, since they show the routing control working. The step is done when a sample of sessions and a sample of blocked attempts can be pulled from the log store with complete fields, and retention is set in line with the audit requirements in the AU family.
Test the routing and record the results
Test the design rather than assume it. Attempt remote connections through each path, try to reach internal systems directly, and confirm that only approved points succeed. Record the test plan, the date, the tester, the expected and actual results, and any defects fixed. Assessors look for evidence of this test, so keep the output in final form. The step is done when every test passes or each exception has a documented risk decision and a remediation owner.
Document the result in the system security plan
Update the system security plan to describe the approved access points, the routing design, the firewall and gateway rules, the logging arrangement and the test results, and link each to 3.1.14. Also reference the related remote access requirements (AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.15, IA.L2-3.5.3 and MA.L2-3.7.5) so the picture is consistent. Set a review trigger for any new remote path. The step is done when the plan is approved and the evidence package is complete. Organizations usually prepare this package themselves, and an independent assessor decides whether it satisfies the requirement.

How the managed access points and enforcement fit together

A remote session under AC.L2-3.1.14 should pass through a small set of managed access control points before it reaches any system that stores, processes or transmits CUI. Trace the path from the remote user or vendor outward. The user first reaches an entry point, usually a remote access gateway or VPN concentrator, where the identity is checked against the directory and the multifactor policy set under the identification and authentication requirements. Only after that check does the session cross into the internal network. The gateway is the first hop that should generate an authentication record, and the organization should be able to show which users and vendor accounts can reach it at all.

Behind the gateway, a firewall policy decides which internal addresses and ports the authenticated session may reach. In a self-hosted design this is often an OPNsense rule set, where address aliases define the CUI enclaves, a default deny rule closes everything else, and per-rule logging records each match. The assessor will look for two things here: that no remote path bypasses the gateway and firewall pair, and that the rules are the ones the organization documented. Coraza, deployed in front of a web application that holds CUI, adds a second inspection hop for HTTP traffic, although it does not replace the network policy. Confirm with the vendor and your own architecture whether each component can be configured to log to your central collector.

Logging is the part most often left incomplete. Each hop should write its own records: the gateway for session start, identity and source address; the firewall for allowed and denied flows; and the application layer for requests it inspects. Decide which system is the authoritative log for each hop, confirm time synchronization across all of them, and test one remote session end to end to see whether the records can be correlated. The procedure that an assessor is most likely to ask you to demonstrate is a single traced session, so run that test before the assessment and keep the output in final form.

Evidence that proves remote access goes through managed points

Assessors testing AC.L2-3.1.14 look for proof on two fronts: that the managed access control points exist and are documented, and that remote sessions actually pass through them. The cards below cover the artifacts that show both, and the upkeep needed to keep them current between assessments.

Inventory of managed access control points

This is the list of every managed network access control point that remote sessions may traverse, such as VPN concentrators, remote access gateways, and firewall interfaces that terminate remote traffic. Each entry should name the device, its location in the boundary, its owner, and the remote access types it serves. Assessors start here, so check that the list matches the network diagram and the system security plan. Any gateway missing from the list is a path an assessor may ask about.

Remote access procedures

Written procedures describe how remote access is requested, approved, configured and removed, and how a remote user reaches the system only through an approved point. They should name the roles responsible for each step and the conditions under which exceptions are allowed. Keep the approved version and its revision history on file. A procedure that describes an older gateway or a retired VPN will weaken the rest of the evidence.

Configuration exports for gateways and firewall rules

Export the running configuration of each gateway and the firewall rules that force remote traffic through managed points. For OPNsense, that means rule sets, aliases for remote address groups, and the logging option enabled on the relevant rules. Confirm that exports show the current state, not a planned change. Store exports with a date and hash so a reviewer can tell whether a configuration changed after evidence was captured.

Audit records of remote sessions

Session logs show who connected, when, from where, and through which access control point. They support the claim that all remote access was routed through managed points and that no session bypassed them. Confirm that logs from gateways and firewalls are retained, time-synchronized, and protected from alteration. Sample a set of sessions and trace each one from user identity to gateway record to firewall log entry.

Periodic reviews of remote access paths

A dated review record shows that someone compared the managed point inventory, firewall rules and session logs against the actual network and found no unmanaged path. Record who performed the review, what they compared, the findings, and the corrective actions with owners and dates. Reviews should repeat on a schedule the organization defines, and any change to remote access should trigger an additional review.

Keeping evidence current and final

Assessors accept evidence only in final form, so a draft inventory, an unsigned procedure or a configuration export marked as pending will not satisfy the requirement. Assign an owner to each artifact, set a review cadence, and tie updates to change control so every gateway addition or rule change produces a new record. Ask your assessor or implementation partner to confirm which artifact formats and dates they will accept before the assessment begins.

What meeting AC.L2-3.1.14 costs in money and effort

This table lists the main cost components of routing remote access through managed access control points, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to shape a written scope and to know what to ask for in a quote. No price figures are given because none were researched for this requirement.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives the cost and what to ask for
Gateway or firewall licenses	Vendor or reseller for commercial gateways; none for self-hosted open-source options such as OPNsense (BSD-2-Clause)	Usually recurring for commercial licenses and support; open-source software carries no license fee	Number of managed access points and remote paths. Ask whether the quote includes support, upgrades and HA units, and whether it is priced per user, per gateway or per throughput.
Engineering time to inventory and reroute remote paths	Internal IT staff or an implementation partner under a fixed-scope agreement	One-time, with periodic re-review when paths change	Count of remote paths, VPNs, vendor tunnels and cloud admin routes that exist today. Ask for a written inventory deliverable and a list of paths to be rerouted.
Logging storage and review	Internal security operations staff, or a managed monitoring provider; storage on your infrastructure or cloud	Recurring for storage, retention and review time	Log volume per session, retention period set by policy, and how often logs are reviewed. Ask how each managed access point forwards logs and who reviews them.
External testing or review	Independent testers or a security testing firm, engaged by the organization	Usually one-time per assessment cycle, with retesting after changes	Scope of remote entry points and whether testing covers bypass attempts around the managed points. Ask for the test scope, rules of engagement and retest terms in writing.
Assessor sampling	Independent assessor (C3PAO for Level 2 certification, where applicable); the organization supplies evidence	Recurring at each assessment cycle	Number of remote access paths the assessor samples and the completeness of configuration and audit records. Confirm current assessment requirements with the Department of War and your contracting officer, as Phase II timing has been suspended.

Open-source tools that support remote access routing evidence

OPNsense is a firewall platform licensed under BSD-2-Clause that works as a stateful packet filter. Its rules pass, block or reject traffic according to source, destination, port and protocol. For remote access routing, the useful pattern is to define the remote access entry points as a small set of controlled rules and deny traffic that bypasses them. Aliases let you group address ranges, such as the managed access points or the internal subnets they reach, so the rule set stays readable during an assessment.

Rule scope: Write rules by source, destination, port and protocol so each permitted remote path is explicit.
Aliases: Use address groups to name managed access points and internal ranges, which makes the configuration easier to review.
Per-rule logging: Enable logging on rules that matter so each match can be reviewed in the live log view.
Default deny: Confirm that traffic not matched by an approved rule is blocked, not passed.
Change records: Keep exported rule configurations with dates so you can show how the routing design changed.

Confirm with your assessor which rule exports, log retention and configuration history they will accept as evidence for your environment.

Where remote access routing usually fails an assessment

Most failures against AC.L2-3.1.14 come from remote paths nobody inventoried, not from weak gateways. The gaps below are the ones assessors most often find when they test whether all remote access passes through managed access control points, and each one has a concrete fix the organization can verify before the assessment starts.

Undocumented vendor and admin tunnels

Vendor support tunnels, emergency SSH forwards and admin VPN accounts often sit outside the managed gateway because someone set them up for a single incident and never removed them. Assessors look for any path into the CUI boundary that does not go through a listed managed access control point. Close this by sweeping firewall NAT rules, hypervisor consoles, jump hosts and vendor remote tools, then either routing each path through the managed point or removing it. Record the result in the system security plan so the inventory and the traffic agree.

Cloud consoles reachable from home networks

Administrators often reach cloud management consoles and hosted admin portals directly from home or unmanaged networks, which bypasses the gateway even when on-premises access is tightly controlled. For AC.L2-3.1.14, every route to systems that handle CUI, including hosted infrastructure, must be a managed access control point. Check identity provider conditional access, cloud network allow lists and endpoint requirements, and confirm in writing which cloud management paths are permitted and how each one is enforced.

Rules that log nothing

A managed access point that passes remote sessions without recording them cannot show that routing happens, and assessors test the audit records as evidence. Many firewall rules are created with logging disabled to reduce noise. Review every rule that admits remote traffic and enable per-rule logging where the platform supports it. Confirm that logs are retained and reviewed, and test one remote session end to end to show that the log entry matches the session.

Managed point lists that are out of date

The list of managed access control points is a required artifact, and it goes stale after a gateway is replaced, a site is added or a vendor is onboarded. An out-of-date list fails the first objective, which asks the organization to identify and implement managed points. Assign an owner to the list, tie updates to change control, and reconcile the list against firewall aliases and network diagrams at each review. Assessors compare the list to the live configuration, so any mismatch becomes a finding.

Evidence that exists only as a draft

Procedures, network diagrams and the managed point list that have not been approved, dated and version controlled do not count as final evidence. Under the CMMC scoring rules a requirement is met only when the evidence is in final form. Before the assessment, approve the remote access procedure, export the rule set and log configuration with a date, and store them in a controlled repository. Confirm with the assessor or your C3PAO which artifact formats they accept.

Questions buyers ask about AC.L2-3.1.14

How much effort does it take to meet AC.L2-3.1.14 remote access routing?

Effort depends less on the requirement's wording than on how many remote entry paths the organization already has. AC.L2-3.1.14 is worth 1 point under the scoring rules in 32 CFR 170.24, but meeting it means inventorying every remote access path, consolidating them behind a small set of managed access control points, and producing configuration and audit records for each. Organizations with a single VPN or zero trust gateway usually have a shorter path than those with vendor tunnels, legacy remote desktop services or hosted tools reached directly from home networks. Ask any provider to estimate effort from a written inventory of your remote paths, not from a generic checklist.

Can we meet AC.L2-3.1.14 in-house without outside help?

Yes, an organization can meet AC.L2-3.1.14 with its own staff, because the organization owns its controls and the requirement does not require an outside party. The work usually needs network, identity and security engineers who can define the managed access control points, configure routing so remote traffic passes through them, and collect logs. An implementation partner can prepare systems, configurations and evidence, but it cannot issue an assessment result. Only an independent assessor or certification body does that. If internal staff are already stretched, an outside partner can take on the build and documentation while your team keeps ownership of the decisions.

What does the team need to deliver AC.L2-3.1.14?

The work needs a short list of skills and inputs before any configuration starts:

A current inventory of remote access paths, including VPN, gateways, vendor access and cloud administration consoles
Network engineers who can enforce routing through the chosen access control points
Identity owners who can confirm who may connect and through which point
Logging and monitoring staff who can keep audit records of remote sessions
A written procedure that names the managed points and explains how new remote paths are approved

NIST SP 800-171A names the list of managed network access control points, remote access procedures, configuration settings and audit records as likely evidence, so producing these artifacts in final form is part of the job.

Can AC.L2-3.1.14 go on a POA&M, and under what conditions?

AC.L2-3.1.14 can be placed on a plan of action and milestones, but only under specific conditions. Under 32 CFR 170.21, a 1-point requirement that is not on the exclusion list in 32 CFR 170.21(a)(2)(iii) may be included for Conditional Level 2 status when the assessed score is at least 88 of 110 (0.8). The POA&M must be closed out within 180 days. Confirm with your assessor or the current rule text how the score is calculated for your environment, because the threshold applies to the whole score, not to this requirement alone. Relying on a POA&M is a risk decision, so treat it as a temporary measure with a dated closeout plan.

How does AC.L2-3.1.14 relate to AC.L2-3.1.12 and AC.L2-3.1.13?

AC.L2-3.1.12 controls which types of remote access are permitted and monitors each session, AC.L2-3.1.13 requires those sessions to be encrypted with FIPS-validated cryptography, and AC.L2-3.1.14 requires that all remote access pass through managed access control points. The CMMC Assessment Guide describes 3.1.14 as complementing five remote access requirements, including AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.15, IA.L2-3.5.3 and MA.L2-3.7.5. In practice, one well-designed gateway can produce evidence for all three, but assessors will test each objective separately, so the evidence for each should be labeled and retained.

What should we confirm about the CMMC phase schedule before spending on this control?

Confirm the current phase status with the official sources before committing budget. The Department of War suspended CMMC Phase II on 13 July 2026, and its DoW CIO page says implementation is paused in Phase 1, which began 10 November 2025, and may require only self-assessments at Levels 1 and 2. The eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule, so the two sources do not match. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Ask your contracting officer which requirements apply to your contracts, and confirm the current rule text yourself before setting a timeline.

How DeployOpen works on this

DeployOpen helps defense contractors plan and prepare the managed access control points that AC.L2-3.1.14 requires, inside the organization's own infrastructure. We prepare systems and evidence, while the organization owns the control and an independent assessor makes the final determination.

How we scope

Inventory every path remote users and administrators take into the CUI boundary, including cloud email and hosted infrastructure.
Agree in writing which access control points will be managed, and which remote routes are out of scope and why.
Confirm with the organization and its assessor which evidence sources will be produced for each assessment objective of 3.1.14.

How we build

Configure managed access control points on open-source platforms such as OPNsense, with rules, aliases and logging for remote routes.
Route remote sessions through those points and test that direct paths to protected systems are blocked.
Where web-facing services sit behind the points, evaluate Coraza as a web application firewall and confirm its rulesets fit the application.

How we hand over

Document the access control points, remote access procedures, configuration settings and audit records in final form.
Map each artifact to the two assessment objectives of NIST SP 800-171A so the organization and its assessor can trace evidence.
Deliver the documentation and configurations to the organization, which keeps ownership of the control and the signed assessment record.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Confirm with the organization how changes to remote access routes will be reviewed before they reach production.
Ask any implementation partner to confirm current CMMC requirements and phase status with the DoW CIO before scoping work starts.