MFA gets attention, but Rev. 2 remote-access requirements also require monitoring and control of sessions, cryptographic protection, and routing remote access through managed access-control points.
In practice, the question that matters for a small defense contractor is narrower: does the requirement map to a specific control inside the FCI/CUI boundary, is an owner assigned, and is there current evidence it is actually operating?
The rule in plain English
3.1.12 addresses monitoring and control, 3.1.13 protects remote-session confidentiality with cryptography, and 3.1.14 requires routing through managed access-control points.
Think in paths: every approved remote path into the CUI environment should be known, authenticated, encrypted, logged, and administratively controlled.
How to implement it without overbuilding
Consolidate remote administration and user access through managed VPN, VDI, zero-trust access, or other approved gateways rather than scattered direct exposure.
Separate vendor maintenance, privileged administration, and ordinary user access when their risk or evidence needs differ.
What evidence to keep
Keep gateway configuration, encryption settings, access rules, remote-session logs, approved user/device lists, and exception records.
A good log sample can be tied to a known user, device, source, destination, and approved method.
Where teams get into trouble
Recurring failures include forgotten direct RDP, vendor tunnels outside the approved gateway, strong MFA with weak logging, or split paths nobody included in the diagram.
Small-contractor walkthrough
Remote users connect through a managed gateway while an equipment vendor uses a separate remote-support agent. The contractor must decide whether both paths are authorized, encrypted, monitored, and routed through managed control points—or retire the ungoverned path.
- Enumerate every remote method.
- Remove unapproved direct paths.
- Verify encryption.
- Centralize access points.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: enumerate every remote method; remove unapproved direct paths; verify encryption; and centralize access points. Assign an owner and an evidence location to each decision.
Manual deep review: inventory every remote path and test the architecture end to end
List every way a person can reach the CUI environment from outside: user VPN, VDI, zero-trust access, RDP gateway, cloud administration, RMM, firewall management, vendor support agent, remote maintenance, and any directly exposed service. For each path, record who may use it, source-device requirements, authentication, cryptography, managed access-control point, post-gateway restrictions, logging, and whether the path is still necessary. The unofficial second path is a recurring assessment surprise.
3.1.12 requires permitted remote access to be identified, controlled, and monitored. Define the restrictions that apply—approved users, managed devices, conditional access, gateway policy, network or application destinations, and separate authorization for privileged commands where applicable. Then show who owns the remote-access telemetry, where it is retained, and what activity creates an investigation. A log that nobody can retrieve or review is weak operating evidence.
For 3.1.13, identify the cryptographic mechanism that protects remote-session confidentiality and verify it is actually in force across each approved path. Where CUI confidentiality relies on cryptography, connect the implementation to the organization's FIPS-validation analysis rather than assuming any encrypted protocol automatically qualifies. For 3.1.14, route sessions through managed access-control points the organization administers and can evidence.
Run one end-to-end test for an ordinary remote user and one privileged or vendor path. Start outside the boundary, reach an allowed CUI resource through the approved control point, verify authentication, cryptography, restrictions, and logging, then attempt a prohibited route or destination and confirm it is blocked. Close the session and confirm the evidence is retrievable, including when an MSP or provider operates part of the path.
- Remote-path inventory.
- Approved users/devices and restrictions.
- Cryptographic mechanism evidence.
- Managed gateway/access-control point.
- Session monitoring and allowed/blocked path test.
Manual assessment cross-check
Compare the documented remote-path inventory with VPN, firewall, RMM, cloud-administration, and vendor-support records to find undeclared secondary access paths.
Use CMMC Remote Access Beyond MFA: Monitoring, Encryption, and Managed Access Points (3.1.12–3.1.14) as an operating guide, not as a substitute for the controlling source. Before publication or assessment use, re-open the current NIST SP 800-171 Rev. 2 requirement, the corresponding NIST SP 800-171A assessment objectives, and the DoD CMMC Level 2 Assessment Guide. Confirm that every mandatory statement on the page maps to those sources or to a clearly labeled organizational implementation choice.
Additional objective-level implementation notes
Describe remote access as an end-to-end path rather than a VPN product. For each method, record the external endpoint condition, identity and authentication, cryptographic protection, managed access-control point, destinations reachable after connection, monitoring source, and privilege level. This exposes secure gateways that still grant unnecessarily broad internal reach or vendor agents that bypass the managed point.
Where cryptography protects CUI confidentiality, retain the analysis supporting the organization's FIPS conclusion rather than relying on an 'encryption enabled' screenshot. For managed access points, show routing or policy enforcement that forces the session through the controlled point. For monitoring, retain connection evidence that ties the event to the user and path, including provider-operated logs.
Final manual spot check
For a final spot check, compare the approved remote-access inventory against firewall rules, VPN configuration, RMM tools, cloud administrative portals, and vendor-support software. Investigate every remote method that appears in the technology but not in the documentation. Then test one approved path from an external endpoint to a permitted CUI resource and one prohibited path. The evidence should show managed routing, cryptographic protection, monitoring, and a blocked route where access is not authorized.
One more edge case to verify
Include privileged and maintenance access in the same remote-path inventory. A user VPN may be well controlled while an administrative browser session, RMM agent, or vendor tunnel creates a separate unmanaged route into the same environment.
A short working check
- ✓Enumerate every remote method.
- ✓Remove unapproved direct paths.
- ✓Verify encryption.
- ✓Centralize access points.
- ✓Retain session logs.
- ✓Review vendor remote access.
Common questions
Does MFA by itself satisfy remote access?
No. Monitoring, cryptographic protection, and managed access points are separate requirements.
Can zero-trust access replace VPN?
Potentially. The requirement is outcome-based; document how the service provides the required control and evidence.
Are remote support tools relevant?
Yes when they provide access to in-scope systems or support them.
What should we test?
Demonstrate that an approved user reaches the environment through the managed path and that the expected logs are produced.
Is a VPN alone enough for 3.1.12 through 3.1.14?
No. Remote access also needs to be identified, controlled, monitored, cryptographically protected, and routed through managed access-control points.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
