CMMC Level 2 Remote Access Controls Using Entra ID and VPN: A Practical Guide

Remote access is where good security programs get messy. One “temporary” exception turns into a permanent hole, then an assessor asks you to prove you monitor and control every session.

For CMMC Level 2, I treat CMMC remote access controls as a system, not a setting. Microsoft Entra ID (Conditional Access, MFA, device signals) sets the identity rules, while your VPN enforces a single, encrypted entry point into the CUI environment. When they work together, you can both reduce risk and keep clean evidence for assessment day.

Below is the approach I use with small-to-mid defense contractors that need clear, repeatable controls.

What CMMC Level 2 expects from remote access (and what to retain as evidence)

CMMC Level 2 aligns to NIST SP 800-171. For remote access, assessors look for three themes: you limit entry points, you encrypt sessions, and you monitor and control use. Microsoft publishes helpful identity mappings, but you still need to connect identity to network enforcement (and prove it). I keep Microsoft’s guidance bookmarked, especially the CMMC Level 2 access control configuration guidance.

Here’s a concise mapping I use in projects. Your VPN features differ by vendor, yet the control intent stays the same.

CMMC / NIST practice (remote-access related)	Entra ID control(s)	VPN control(s) (vendor varies)	Evidence to retain
AC.L2-3.1.12 Monitor and control remote access sessions	Conditional Access (CA) sign-in policies, user and sign-in logs	Session logs, connect/disconnect, assigned IP, device posture result (if supported)	Entra sign-in logs, CA logs, VPN session reports, alert records
AC.L2-3.1.13 Encrypt remote sessions	CA requiring modern auth apps, block legacy auth	IPsec/IKEv2 or TLS VPN with strong ciphers, disable weak protocols	VPN configuration export, crypto policy screenshots, change tickets
AC.L2-3.1.14 Route remote access via managed access points	CA to restrict apps and locations, named locations	Single approved VPN gateway or cluster, no direct inbound RDP	Network diagram, firewall rules, VPN headend inventory
AC.L2-3.1.15 Authorize privileged commands for remote sessions	Separate admin accounts, PIM approvals, CA for admin sign-ins	Admin access only after VPN, separate admin VPN group	PIM audit logs, admin CA policy, admin group membership history
IA.L2-3.5.3 MFA for network access to privileged and non-privileged accounts	Entra MFA, prefer FIDO2 or CBA, authentication strengths	SAML/RADIUS integration that enforces MFA, or cert auth plus MFA step	MFA registration report, CA policy export, VPN auth logs
MA.L2-3.7.5 MFA for remote maintenance	CA requiring MFA for tools, PIM/JIT where possible	Vendor remote support gated through VPN and MFA	Remote support records, MFA proof, maintenance tickets

If you want a plain-English control explanation that maps well to assessor expectations, I also point teams to DIB SCC CyberAssist’s AC.L2-3.1.12 guide.

My rule: if a control isn’t easy to show with logs, exports, and screenshots, it isn’t “done” yet.

Baseline design: Entra ID Conditional Access plus VPN (the setup I recommend)

My recommended baseline is strict, but it prevents the usual remote-access drift.

Identity first: MFA everywhere, stronger for admins

I start by requiring MFA for all users that can touch CUI systems. Where feasible, I choose phishing-resistant methods (FIDO2 security keys, or certificate-based authentication). Next, I create separate admin accounts for privileged work, then block those accounts from email and daily browsing. That split is simple, and it reduces credential exposure fast.

For admin workflows, I prefer a PAW or bastion approach. In practice, that means privileged actions only happen from hardened endpoints, or through a controlled jump host. I also use Entra Privileged Identity Management approvals and time limits, because “always admin” is hard to defend during assessment.

Conditional Access: require managed, healthy devices

Then I put Conditional Access in front of everything important:

• Require compliant or hybrid-joined devices for cloud apps used in the CUI enclave.
• Block legacy authentication.
• Restrict access by geography using Named Locations (approved states or countries only).
• Tighten session controls (sign-in frequency, persistent browser session limits) for higher-risk roles.

This is where Endpoint Security and Device Hardening matter. If a laptop isn’t enrolled, patched, encrypted, and protected, it doesn’t get in. That stance also helps with Business Continuity & Security because you avoid “snowflake” endpoints.

VPN: one front door, strong crypto, managed devices only

On the VPN side, I aim for one controlled access point. Your product might be Cisco, Palo Alto, Fortinet, Windows Always On VPN, or something else, so I keep the outcome consistent:

• Enforce MFA for VPN sign-in (often via SAML to Entra ID, or RADIUS plus Entra MFA).
• Prefer certificate-based authentication where your platform supports it (user or device certs).
• Use strong cipher suites and disable old protocols and weak settings.
• Restrict VPN access to managed devices, and approved geographies.
• Avoid split tunneling unless you can prove controls around DNS, inspection, and data paths.

Some vendors have sharp edges with identity mapping. For example, certificate-to-username behavior can differ, and SAML attributes can be tricky, so I research known patterns in forums when needed (see this Entra ID SAML and certificate username discussion).

Logging, policies, and assessor-ready evidence (so you can prove it works)

Controls that aren’t observable don’t build trust. I set up logging early, then I test with real users and real failure cases.

What I collect, where it goes, and what alerts I build

At minimum, I collect:

• Entra ID sign-in logs and Conditional Access logs (success and failure).
• VPN authentication logs and VPN session telemetry (connect time, disconnect time, source IP, assigned IP, group, device posture result if available).
• Endpoint signals from your EDR and device compliance platform.

Then I forward everything to centralized storage (SIEM or log platform) with a retention period that matches your policy and assessment needs. A lot of Level 2 failures come from missing proof, not missing tools. This is a theme called out in where teams fail CMMC Level 2 assessments.

Example alert use-cases I like because they’re easy to explain to an assessor:

• Admin sign-in without phishing-resistant MFA (should be blocked, alert if attempted).
• VPN logins from non-approved countries (blocked, alert on attempt).
• Repeated CA failures followed by a success from a new IP (possible spray then hit).
• VPN session established, then a disabled user account event (investigate immediately).
• Sign-in to CUI apps from non-compliant device (blocked, alert for remediation).

Policy language snippets you can adapt

I keep policy text short and enforceable. Here are snippets I use as a starting point.

Remote Access Policy (snippet)
Remote access to CUI systems is permitted only through the company-approved VPN and approved cloud services protected by Conditional Access. All remote sessions must use MFA. Access is limited to managed, encrypted, monitored endpoints. The company logs remote authentication and session activity and reviews alerts for suspicious access attempts.

Admin Remote Access Policy (snippet)
Privileged remote access requires a separate admin account, phishing-resistant MFA where feasible, and use of a hardened administrative workstation or bastion host. Administrative access is granted only for the time required to complete the task (just-in-time where supported) and is logged for audit.

Assessor-friendly evidence checklist (what I package)

I build an “evidence binder” that a tired human can follow:

• Conditional Access policy exports (PDF or screenshots) showing device, MFA, geo, and admin rules.
• MFA registration and authentication method reports for users and admins.
• PIM configuration and audit logs (approvals, activations, role settings).
• VPN configuration evidence (crypto settings, MFA integration, allowed groups, split-tunnel stance).
• VPN session logs and sample investigations tied to tickets.
• A short remote access architecture diagram showing the single entry point.
• Proof of Endpoint Security baselines (disk encryption, EDR present, compliance checks).

Common mistakes I block early

I see the same issues repeat:

• Allowing BYOD for CUI access.
• MFA “exceptions” that never expire.
• Split tunneling with no guardrails.
• Shared accounts, including shared admin IDs.
• Missing log retention, or logs that never leave the VPN appliance.
• Unmanaged endpoints accessing cloud apps after an Office 365 Migration.

As a Business Technology Partner for Small Business IT, I fold this into broader programs: Cloud Infrastructure, Cloud Management, Secure Cloud Architecture, Technology Consulting, Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Managed IT for Small Business, Cybersecurity Services, and Data Center Technology. Even clients who come to me for Restaurant POS Support and Kitchen Technology Solutions benefit, because disciplined access control reduces downtime and surprises.

Conclusion

When I implement CMMC remote access controls with Entra ID and a VPN, I focus on one front door, strong identity proof, and clean evidence. That mix makes remote work safer without turning every login into a helpdesk ticket. If you want, I can review your Conditional Access and VPN settings against the mapping table above, then turn the gaps into a short remediation plan your team can execute before assessment.