This is one of the three hardest practices in the entire AC family. Small contractors stumble on 3.1.12 because the practice requires control at multiple layers simultaneously: the VPN or remote access solution logs who connected and when. The conditional access policy or firewall controls what those remote sessions can reach. The endpoint security confirms the device that initiated the connection is trustworthy. The SIEM or log aggregation proves you actually reviewed the sessions. The assessor wants to see confidence in all of those layers. If you have a VPN but no way to prove you’ve reviewed who used it, that’s incomplete. If you log everything but have no controls on what remote users can reach, that’s incomplete.
The assessment room pain here is usually one of two problems. First, contractors with mature VPN infrastructure think the VPN alone is the control. “We have Cisco ASA, all remote access goes through it.” The assessor will push: “OK, so who reviewed the logs from your VPN?” Silence. Second, contractors who enabled Conditional Access in Azure AD think that’s the remote access control. But they haven’t integrated it with their on-premises systems, or they’ve excluded entire admin accounts from the policy, or they haven’t thought about how to monitor sessions that don’t originate from the phone or app that’s sitting on their desk.
This practice connects to AC.L2-3.1.1 (access control), IA.L2-3.5.2 (strong authentication), and AU.L2-3.3.2 (audit logging of remote access). Remote access is one of the highest-risk vectors, so this practice is where multiple domains converge.
This page focuses on framing the practice as a multi-layer challenge, showing how each layer fits together, and addressing the specific gotchas that kill assessments.
What the assessor is actually evaluating
The NIST language is “monitor and control user sessions associated with remote access.” In the assessment room, this breaks down into four layers:
Layer 1: Identification. Who is attempting remote access? Is it a named user? Is the device known? The assessor wants to see that you can name every remote access session to a specific person and (usually) a specific device.
Layer 2: Authorization and policy. Are you checking whether that person and device are permitted to access CUI systems? Conditional Access policies do this. Firewall rules do this. Something should be saying “yes, Alice on a corporate laptop is allowed” or “no, an unknown device is rejected.”
Layer 3: Logging and auditing. What happened during the session? Who logged in, when, from where, what did they do? You need logs that prove you can answer those questions. VPN logs, firewall logs, SIEM logs, endpoint logs. The specific logs depend on your architecture, but there must be something.
Layer 4: Review and response. Did you actually look at those logs? Can you produce evidence that someone on your team reviewed remote access activity and determined it was appropriate? This is where most contractors fail. The infrastructure exists, the logs exist, but nobody’s reviewing them. If you can’t show that review happened, the control is incomplete.
The assessor will probe each layer. They’ll ask who reviewed remote access logs, at what frequency, and what they were looking for. If your answer is “the MSSP probably logs it,” that’s not good enough. You need to show that review is happening with defined frequency and documented results.
What a realistic SSP definition looks like
[Organization Name] monitors and controls all remote access sessions to systems within the CUI boundary. Remote access is permitted only to authenticated users connecting from known, corporate-managed devices via the organization's VPN or remote desktop gateway. All remote access attempts are logged, including connection time, user identity, device identity, source IP address, and access outcome.
Conditional access policies enforce that only devices meeting compliance requirements (current antivirus definition, current operating system patches, disk encryption enabled) are permitted to initiate remote sessions. Administrators must authenticate using multi-factor authentication for all remote access. Sessions to administrative resources are logged and reviewed at least weekly by the IT Director or designee. Non-administrative remote access is reviewed monthly. Session logs are retained for at least one year.
The MSSP manages VPN infrastructure, logs aggregation, and provides a monthly summary of all remote access activity to the IT Director for review. The IT Director signs off on the review and documents any anomalies or actions taken.
Look at what’s happening in that language. First, it’s very specific: “VPN or remote desktop gateway,” not “encrypted connection.” Second, it names the review frequency differently for different account types: weekly for admin, monthly for standard users. That’s precise, and it matters. Third, it documents that MSSP involvement doesn’t remove the contractor’s responsibility to review. The contractor does the review, the MSSP provides the data.
How to present your evidence
- Conditional Access policy screenshots showing device compliance requirements
- VPN or remote access gateway configuration showing authentication and logging
- Firewall or network access control rules limiting remote access destinations
- Sample VPN/remote access logs showing user, device, time, source IP, and outcome
- Evidence of periodic review of remote access logs (dated summary or audit record)
- If applicable, documented incident or action taken based on remote access log review
- Multi-factor authentication configuration for remote access
Have these ready, organized by layer:
Authentication and Authorization Layer. Pull up your Conditional Access policies. The assessor will want to see the conditions: which users can access, which devices, what compliance checks must pass. They’ll look for obvious problems, like entire admin groups excluded from the policy or ridiculous excludes like “all users from the executive IP range.”
If you’re using a traditional VPN or RDP gateway, pull up the configuration showing how you’re enforcing authentication (MFA required?) and what the system logs.
Network Controls Layer. Show your firewall rules or access control lists. Remote access should terminate in a specific zone (DMZ, management VLAN) with onward access to CUI systems restricted. If remote access lands directly on your file servers, that’s a problem. The assessor will ask how you’re controlling where remote sessions can go.
Logging Layer. Pull up actual logs from your VPN, RDP gateway, or firewall. The assessor wants to see what information is being captured. One sample VPN session log showing user, timestamp, source IP, device name, and outcome. One RDP gateway log showing the same. These don’t need to be redacted, but they do need to be real.
Review Layer. This is critical. Pull up a recent review record. Could be a dated email from the IT Director saying “reviewed remote access logs for March, all sessions appeared legitimate.” Could be a signed spreadsheet showing “10 VPN sessions reviewed, no anomalies noted.” Could be a ticket in your MSSP ticketing system documenting “monthly review: 23 sessions, all approved.”
The format doesn’t matter. The proof that review happened does.
MFA Configuration. Show that MFA is required for remote access. If you’re using Azure AD, pull up the Conditional Access policy showing “grant access” requires “require multi-factor authentication.” If you’re using a traditional VPN, show the client software configuration or gateway settings requiring an OTP or hardware token.
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
Entire groups excluded from Conditional Access or MFA policy. "All executives are excluded from device compliance" or "all admins are excluded from MFA." The assessor will push hard here. There's almost never a good reason to exclude someone. If there is one (legacy system that doesn't support MFA), it should be documented, time-limited, and part of a remediation plan.
No evidence of log review. You have a VPN, logs are being generated, but nobody's looking at them. The assessor will ask "when did you last review these logs?" and silence is damning. You need dated proof of review, at least monthly.
Remote access goes directly to CUI systems with no intermediate controls. Remote desktop straight to your file server, SSH straight to your app server. The assessor wants to see that remote access lands in a controlled zone first, then requires separate authentication or additional authorization to reach sensitive systems.
Vague or missing MFA requirement. "Most remote users have MFA enabled" is not the same as "MFA is required for all remote access." The SSP should be unambiguous, and the policy should enforce it.
Different processes for different users but no documentation. Admins go through VPN, standard users use RDP, contractors use a third service. That's fine, but the SSP needs to name each path and explain why. If the assessor can't figure out how remote access is segmented, they'll probe until they find a gap.
Clear, multi-layer controls that the assessor can see and understand. VPN or remote access gateway with authentication and logging. Conditional Access or network controls limiting what remote sessions can reach. Dated evidence of periodic review with documented findings. MFA enforced without exceptions (or exceptions clearly documented and justified). If you can walk the assessor through the whole chain from authentication through review, 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
This is one of the few practices where the MSSP’s involvement is actually central to your compliance. Most MSSPs manage the VPN, the logs, the infrastructure. Your job is different: you’re responsible for the business decision of who gets remote access and the operational discipline of reviewing what happens.
What’s on you (the contractor):
- Defining the remote access policy in your SSP (who, under what conditions, to what resources)
- Approving or denying remote access requests
- Reviewing remote access logs at a defined frequency
- Documenting your review and any actions taken
- Deciding what constitutes an anomaly that needs investigation
What’s on the MSSP:
- Deploying and configuring the VPN or remote access gateway
- Enforcing MFA and other authentication mechanisms
- Collecting and aggregating logs
- Providing regular reports showing who accessed what and when
- Implementing any firewall or network rules you define
- Flagging obvious security issues for your review
The assessor will ask you (the contractor) “who reviews the logs?” and will want to hear your name, not the MSSP’s name. The MSSP can show the infrastructure and talk through how it works, but you need to demonstrate the business-level oversight.
This is one of the hardest practices in AC. Assessors dig deep. They'll ask about VPN logs, conditional access, endpoint checks, and your review process. If any layer is weak or missing, they'll find it. Have a clear story that connects all the pieces: how you authenticate remote users, what they can reach, how you monitor the sessions, and evidence of periodic review. If you can walk through that chain smoothly, the assessor's confidence goes up. Gaps in any layer create findings. Be thorough in your pre-assessment prep.
This is where the best MSSPs shine. They don't just hand you raw logs and say "you review these." They do the review themselves, create a summary highlighting what matters, and present it to you with recommendations. You then sign off, add any context they might be missing, and document the review. This shared responsibility model is much more auditable than expecting a contractor to wade through gigabytes of raw logs. If your MSSP isn't doing something like this, ask for it. Or do a monthly review call where they walk you through the highlights. The assessor will respect that much more than a vague "yeah, someone's probably looking at the logs."
This page covers AC.L2-3.1.12 from NIST SP 800-171 Rev 2 (3.1.12). 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.