MFA for CMMC: Which Logins Need It, Which Accounts Need More, and Where Companies Get It Wrong
Enabling MFA Is Not the Same as Enforcing It Everywhere It Matters
Multi-factor authentication is not a single switch. NIST SP 800-171 requires MFA for remote access and for privileged accounts — but the assessment objectives probe far deeper than "is MFA turned on?" Which login flows are covered, which accounts bypass it, which factors are strong enough, and how you prove enforcement are what separate a passing assessment from a finding.
Interactive Users, Remote Users, Admins, Service Accounts, Break-Glass Accounts
Not every account has the same MFA obligation under NIST SP 800-171 — but every account type has an MFA question the assessor will ask. Understanding which controls apply to which accounts is the first step toward a defensible configuration.
The two primary MFA controls are:
AC.L2-3.1.19 (via 3.1.12): Employ cryptographic mechanisms to protect the confidentiality of remote access sessions — which, combined with 3.5.3, means remote access requires MFA regardless of privilege level.
In practical terms, this creates a matrix of requirements:
| Account Type | Local Access | Remote / Network Access | Notes |
|---|---|---|---|
| Standard user (non-privileged) | MFA recommended | MFA required | Any user accessing in-scope systems over a network — including cloud apps — triggers the network access MFA requirement. |
| Privileged user (admin) | MFA required | MFA required | Both local and remote access to privileged accounts require MFA. This includes Global Admins, Exchange Admins, Intune Admins, firewall admins — any elevated role. |
| Service account | MFA not typical | Compensating controls | Service accounts used for automated processes typically cannot perform interactive MFA. Compensating controls — managed identity, certificate-based auth, IP restriction, and monitoring — must be documented. |
| Break-glass / emergency account | MFA exception documented | MFA exception documented | Break-glass accounts are designed for scenarios where MFA infrastructure is unavailable. They must be excluded from conditional access MFA policies — but the exception must be documented, the credentials secured, and every use logged and investigated. |
| Shared / generic account | Should not exist | Shared accounts undermine AU.L2-3.3.2 (unique user traceability). Eliminate shared accounts or convert them to named accounts with individual MFA enrollment. If elimination is impossible, document the exception and the compensating control. | |
Workstation Logon Versus Application Access Versus VPN Access
Contractors frequently implement MFA for one access path and miss others — creating gaps that assessors are specifically trained to identify. The MFA enforcement must cover every authentication flow that provides access to CUI or to systems that manage CUI.
Workstation Logon (Windows Hello / Console)
For cloud-joined or hybrid-joined devices authenticating to Azure AD, MFA can be enforced through conditional access at the point of Windows logon. Windows Hello for Business — using PIN backed by TPM, biometric, or FIDO2 key — counts as multi-factor because the device itself is the first factor (something you have) and the PIN or biometric is the second (something you know or are). For on-premises-only domain logons, MFA is harder: you need a third-party MFA solution like Duo or a smart card infrastructure.
Cloud Application Access (M365, SharePoint, Teams)
Conditional access policies in Azure AD / Entra ID enforce MFA at the application layer. A user signing into Outlook on the web, SharePoint, or Teams is challenged for MFA based on the conditional access policy configuration — factoring in device compliance, location, risk level, and application sensitivity. This is the most common MFA enforcement point in GCC High environments and the one assessors will probe first.
VPN Access
VPN concentrators authenticate users before granting network-layer access to the CUI environment. MFA at the VPN gateway is critical — it is the front door for remote users. Most enterprise VPN products (Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiClient) support RADIUS or SAML integration with an MFA provider. If MFA is enforced at the cloud app layer but not at the VPN, a remote user can reach the internal network without a second factor — and then access on-premises CUI systems directly.
Remote Desktop (RDP / RDS)
Remote Desktop sessions to servers and workstations are a high-risk access path — they provide full interactive access to the target system. If RDP is used for CUI system administration, MFA must be enforced at the RDP authentication point. Azure AD conditional access does not natively cover traditional RDP. Solutions include NLA with Duo, Azure AD Application Proxy, or Windows Hello for Business on the target host. Unprotected RDP to in-scope systems is one of the most common MFA findings.
Administrative Consoles
Firewall management interfaces, switch consoles, backup server dashboards, hypervisor management — any administrative interface for an in-scope system. These are privileged access points that require MFA under 3.5.3. Many appliance consoles do not natively support MFA. The compensating approach is to place the management interface behind a jump host or bastion that requires MFA, then restrict direct console access to the physical or out-of-band management network.
MFA in VDI and Enclave Environments
Virtual Desktop Infrastructure is a common architecture for CUI enclaves — users access a centralized virtual desktop that sits inside the enclave boundary, rather than processing CUI on their local endpoint. VDI reduces endpoint scope but introduces a specific MFA challenge: where in the authentication chain is MFA enforced?
MFA at the VDI Gateway
The user authenticates to the VDI connection broker (Azure Virtual Desktop, Citrix Gateway, VMware Horizon) with MFA before the virtual desktop session is established. The MFA challenge happens before CUI access — which is the correct enforcement point. Once inside the virtual desktop, the user operates in the enclave with full CUI access. The MFA event is logged in the identity provider and can be shown to the assessor.
MFA Only at the Local Endpoint
The user performs MFA to log into their local workstation, then connects to the VDI session without a second authentication challenge. The MFA protected the endpoint — but not the VDI session. If the local workstation is compromised after the initial MFA event, the attacker can ride the VDI session into the enclave without their own MFA challenge. MFA must be enforced at the enclave access point, not just the user's front door.
For Azure Virtual Desktop in GCC High, conditional access policies can enforce MFA at the AVD connection point. The user signs into the AVD web client or remote desktop client, conditional access evaluates the session, and MFA is required before the virtual desktop launches. This is the cleanest architecture — the MFA enforcement, the identity log, and the conditional access evaluation all reside in the same GCC High tenant and produce unified evidence.
Privileged Access and Phishing-Resistant Factors
Not all MFA factors are equally strong. NIST SP 800-171 requires MFA for privileged accounts — and the growing consensus among assessors and the DoD is that privileged accounts should use phishing-resistant authentication factors whenever possible.
The distinction matters because traditional MFA methods — SMS codes, voice calls, and even push notifications — are vulnerable to phishing, SIM swapping, and MFA fatigue attacks. A user who approves a push notification they didn't initiate has effectively bypassed MFA. For standard user accounts, these methods are acceptable. For privileged accounts that can alter the control environment, the bar should be higher.
| MFA Method | Phishing Resistant? | Suitability |
|---|---|---|
| FIDO2 security key | Yes | Strongest option. Hardware-bound, origin-bound, not replayable. Supported in Azure AD / Entra for GCC High. Recommended for all Global Admin and privileged roles. |
| Windows Hello for Business | Yes | TPM-backed, device-bound credential. Counts as multi-factor (device + PIN/biometric). Excellent for workstation logon MFA. Requires device enrollment in Azure AD. |
| Certificate-based auth (smart card / PIV) | Yes | Hardware token with X.509 certificate. Common in DoD and government environments. Requires PKI infrastructure. Supported in Azure AD CBA for GCC High. |
| Microsoft Authenticator (number matching) | Partially | Number matching reduces MFA fatigue attacks but does not prevent real-time phishing proxies. Acceptable for standard accounts. Not recommended as the sole factor for privileged accounts. |
| TOTP app (Google Authenticator, Authy) | No | Time-based codes are phishable via real-time proxy attacks. Acceptable for standard accounts. Not appropriate for privileged accounts where phishing-resistant factors are available. |
| SMS / voice call | No | Vulnerable to SIM swapping, SS7 interception, and social engineering. NIST has discouraged SMS-based MFA since SP 800-63B. Acceptable as a fallback only — never as the primary factor for privileged accounts. |
Common Weak Points: Local Admin, Legacy Protocols, Conditional Access Gaps
MFA failures in CMMC assessments rarely involve a contractor that has not enabled MFA at all. They involve contractors who enabled MFA in the most visible place — the Azure AD sign-in prompt — and missed the less obvious authentication paths that bypass it entirely.
Local Administrator Accounts
The built-in local admin account on Windows endpoints does not authenticate through Azure AD. Conditional access policies do not apply. If a user — or an attacker — logs into a workstation using the local admin password, there is no MFA challenge. For organizations using LAPS (Local Administrator Password Solution), the passwords are rotated and stored in Azure AD — but the authentication itself is still a single-factor local logon. The compensating control is to disable interactive local admin logon via Group Policy and restrict LAPS password retrieval to privileged roles with MFA.
Legacy Authentication Protocols
IMAP, POP3, SMTP AUTH, and older Exchange Web Services clients authenticate with username and password — without any MFA capability. If legacy authentication is not blocked in Azure AD, a user (or attacker) can authenticate to Exchange Online with just a password, completely bypassing conditional access and MFA. Block legacy authentication with a conditional access policy. Then verify it is blocked by reviewing the Azure AD sign-in logs for "Legacy Authentication" client app types.
Conditional Access Exclusions
Every conditional access policy has an "Exclude" list. Break-glass accounts, service accounts, and sometimes entire groups are excluded from MFA enforcement. These exclusions are necessary — but they are also the most common gap assessors find. If the exclusion list is broader than it should be — a legacy "MFA Exceptions" group with 15 members nobody has reviewed in a year — the control is undermined. Review exclusions quarterly. Document the justification for each excluded account.
Trusted Location Bypass
Some organizations configure conditional access to skip MFA when the user is on the corporate network — a "trusted location" exemption. This means an attacker on the same network — via a compromised endpoint, a rogue device, or a physical intrusion — authenticates without MFA. For CUI environments, trusted location bypasses are difficult to defend to an assessor. If you use them, document the compensating controls (NAC, device compliance requirements, physical access restrictions) and be prepared to justify the risk acceptance.
Firewall and Appliance Management
Administrators access firewall web consoles, switch CLIs, and hypervisor management interfaces — often with username and password alone. If these appliances are in the assessment boundary (and they are, if they carry CUI traffic), admin access without MFA is a finding. Place management interfaces behind an MFA-protected jump host, or use SAML/RADIUS integration to add MFA at the appliance's own authentication prompt.
How to Document Enforcement and Exceptions
The SSP must describe the MFA architecture completely — not just state that "MFA is enabled." The assessor needs to understand which policies enforce MFA, for which users, on which access paths, with which factors, and which accounts are excluded and why.
The documentation should cover:
- Conditional access policy summary — Each policy that enforces MFA, its target users/groups, the applications it covers, the conditions (device compliance, location, risk level), and the grant control (require MFA, require compliant device, or both).
- Exclusion register — Every account or group excluded from MFA enforcement: the account name, the reason for exclusion, the compensating control, and the review date. Break-glass accounts, service principals, and any conditional access exceptions must appear here.
- Authentication methods policy — Which MFA methods are allowed for standard users versus privileged users. If SMS is disabled for admins but allowed for standard users, document that. If FIDO2 is required for Global Admins, document that.
- Non-Azure-AD access paths — VPN MFA configuration (RADIUS/SAML integration), RDP MFA solution, appliance management MFA approach, and any on-premises MFA infrastructure for enclave domains.
- Break-glass procedure — How break-glass accounts are secured (hardware token in a safe, password in a sealed envelope), how their use is detected (alert rule on sign-in), and what investigation is triggered when they are used.
Evidence Examples from Microsoft and Non-Microsoft Stacks
Assessors evaluate MFA enforcement through a combination of configuration review, log analysis, and live testing. Here is the evidence package for each method:
The Bottom Line
MFA for CMMC is not a single configuration. It is a matrix of enforcement points across every access path, every account type, and every authentication protocol in the assessment boundary. Enabling MFA in Azure AD conditional access covers the most visible paths — cloud app access for standard and admin users. But it does not cover VPN authentication, RDP sessions, local admin accounts, legacy protocols, appliance management consoles, or break-glass accounts. Each of those paths requires its own enforcement mechanism, its own documentation, and its own evidence.
The contractors who pass assessments cleanly are the ones who map every access path, enforce MFA at every one, document every exception, and can demonstrate enforcement live when the assessor asks. The ones who fail are the ones who enabled MFA in the Azure AD portal and assumed everything was covered.
MFA is not a feature you enable. It is a control you enforce — across every door into your CUI environment. The assessor will walk through those doors one by one. Make sure every one of them asks for a second factor before it opens.