Why IA.L2-3.5.3 Gets Misread
IA.L2-3.5.3 is one of the highest-value requirements in CMMC Level 2. It carries up to 5 SPRS points and cannot be placed on a POA&M under 32 CFR 170.21, which limits Level 2 POA&Ms to requirements worth 1 point or less. The point deduction is not always the full 5: under 32 CFR 170.24, partial credit applies. If MFA is implemented for some users (remote and privileged) but not all, the deduction is 3 points. The full 5-point deduction only applies if MFA is not implemented for any users.
The requirement text reads: "Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts." That sentence covers two distinct scenarios with different scope. The most common mistake is treating them as the same thing, or only implementing MFA for administrators and assuming everyone else is covered.
The practical implication: your IT administrator logging in at the server console in your facility needs MFA. Your remote engineer connecting over VPN to access drawings also needs MFA. Your office worker logging into a domain-joined laptop at their desk without VPN does not need MFA under this specific requirement (though other controls may apply).
The Two Scenarios Broken Down
The requirement covers different account types under different access conditions. Understanding the matrix prevents both under-implementation (gaps that create findings) and over-implementation (wasted effort trying to satisfy requirements that do not apply).
| Account Type | Access Type | MFA Required? |
|---|---|---|
| Privileged (admins, IT staff) | Local logon (at the console, at a workstation) | Yes |
| Privileged (admins, IT staff) | Network access (RDP, SSH, VPN, remote admin) | Yes |
| Non-privileged (standard users) | Network access (VPN, remote desktop, web apps) | Yes |
| Non-privileged (standard users) | Local logon (domain-joined workstation, no VPN) | Not required under 3.5.3 |
The asymmetry between privileged and non-privileged accounts reflects the risk model. A standard user account that is compromised through local access on a specific workstation has bounded blast radius. A privileged account compromised through any access path has much wider impact, so both access types are covered.
NIST defines a privileged account as an account with access authorization significantly exceeding that of a standard user, and a privileged user as one authorized to perform security-relevant functions that ordinary users are not authorized to perform. In practice this means domain administrators, local administrators, system administrators, privileged service accounts, and other accounts that can modify security configurations, manage users, or access systems beyond normal scope.
VPN and Remote Workers
Remote employees connecting over Cisco AnyConnect or similar VPN to reach on-premises CUI systems are performing network access. That access type triggers the non-privileged account scenario under 3.5.3 regardless of their role. An engineer, a project manager, a procurement specialist — all of them need MFA enforced at the network access layer.
Enforcing Duo MFA at the Cisco VPN gateway is a clean, assessor-defensible solution for this scenario. Authentication occurs before the session is established, which means MFA is satisfied at the perimeter. As long as VPN is the only path to CUI systems for non-privileged users, the network access requirement is fully covered by that single enforcement point.
Common routes that create unintended bypass paths include cloud-hosted applications that are accessible from the internet without going through VPN, file shares reachable via a direct cloud sync client, and email or collaboration tools where CUI might be accessible without a VPN session. If a user can reach CUI systems or CUI data through any of these paths without hitting an MFA prompt, that access path needs MFA or needs to be closed.
Privileged Accounts: Both Local and Network Access
The more operationally demanding side of 3.5.3 for most small contractors is the privileged account scope. Unlike non-privileged users, administrators and IT staff must have MFA enforced even when they are sitting in the office logging into a workstation or server locally. VPN-enforced MFA does not cover this scenario.
Consider a typical small DIB contractor IT environment. The domain admin logs into a Windows Server in the server room using domain credentials. That is local access to a privileged account. The same admin RDPs into a server from their desk. That is network access to a privileged account. Both require MFA under 3.5.3.
| Privileged Access Scenario | Covered by VPN MFA? | Additional MFA Required? |
|---|---|---|
| Admin connects via VPN, then RDPs to a server | Yes (VPN enforces MFA before session) | No, if VPN MFA is enforced and Duo is configured for the RDP path |
| Admin logs into server console locally (on-prem, no VPN) | No | Yes — Windows Hello for Business or Duo Windows Logon Agent |
| Admin logs into a domain-joined workstation locally | No | Yes — MFA must be enforced at Windows logon for privileged accounts |
| Admin uses a service account to run scheduled tasks | Not applicable | Service accounts should not be privileged unless necessary; evaluate under least privilege controls |
The most practical enforcement options for local privileged logon are Duo Security's Windows Logon agent, which intercepts the Windows authentication sequence and requires a Duo push or passcode, and Windows Hello for Business, which uses biometric or PIN-based authentication backed by a TPM chip to satisfy the MFA requirement. Both are assessor-recognized solutions and integrate with existing Active Directory environments.
A Practical, Assessor-Defensible Implementation
For a small DIB contractor running on-premises Active Directory with Cisco VPN and a mix of local and remote users, a layered approach covers all 3.5.3 scenarios without unnecessary complexity.
| Layer | What It Covers | How |
|---|---|---|
| Layer 1 — VPN Gateway | Network access for all users (privileged and non-privileged) | Cisco Duo integrated with AnyConnect or ASA. All VPN authentication requires Duo push or passcode before session is established. |
| Layer 2 — Windows Logon (privileged only) | Local access to privileged accounts | Duo Windows Logon agent or Windows Hello for Business deployed to administrator workstations and servers. Enforced via Group Policy or Intune configuration profile. |
| Layer 3 — Path Audit | Non-VPN access routes to CUI | Enumerate all paths by which non-privileged users can reach CUI systems or data. Close or add MFA to any path that bypasses VPN. |
This three-layer approach produces a clean assessor narrative: all users hitting CUI via network access authenticate through Duo at the VPN perimeter, and all privileged accounts have MFA enforced at local logon as well. The SSP implementation statement for IA.L2-3.5.3 maps directly to these two enforcement points.
Hybrid Azure/Intune Environments
Contractors with a hybrid posture — on-premises Active Directory joined to Azure AD (Entra ID), with Intune managing device compliance — have a meaningful advantage for 3.5.3 implementation. Azure AD Conditional Access can enforce MFA as a prerequisite for device compliance, which translates to enforced MFA before any resource access is granted through that path.
A Conditional Access policy requiring MFA for all cloud resource access covers the network access scenarios for both privileged and non-privileged accounts for anything routed through Azure AD. Combined with Duo MFA at the VPN gateway for on-premises CUI access, hybrid environments can achieve full 3.5.3 coverage with enforcement points that are centrally managed and auditable.
Key Conditional Access policy settings for 3.5.3 alignment:
| Policy Setting | Recommended Configuration |
|---|---|
| Assignments: Users | All users (scope down to CUI system users at minimum; all users is simplest and most defensible) |
| Assignments: Cloud apps | All cloud apps, or specifically the apps that provide access to CUI |
| Access controls: Grant | Require MFA. Optionally require device compliance (Intune-managed). |
| Session: Sign-in frequency | Set a defined re-authentication period rather than allowing persistent sessions indefinitely |
One consideration with hybrid environments: if Intune-managed devices are Entra ID joined and use Windows Hello for Business as the primary authentication method, that can satisfy MFA at local logon for privileged accounts if configured correctly. Windows Hello for Business uses two factors inherently (device TPM plus PIN or biometric), and Microsoft documentation and NIST guidance recognize it as MFA-compliant. Verify that the WHfB configuration ties authentication to a specific device and that the PIN policy meets minimum complexity requirements.
What Counts as MFA Under CMMC
NIST SP 800-171 aligns with NIST SP 800-63B for authenticator guidance. Multi-factor authentication requires two distinct authentication factors from the following categories: something you know (password, PIN), something you have (authenticator app, hardware token, smart card), and something you are (biometric). Any combination of two distinct factors satisfies the definition.
| Method | MFA-Compliant? | Notes |
|---|---|---|
| Password + Duo push notification | Yes | Combination of something you know and something you have. Widely used and assessor-accepted. |
| Password + TOTP code (Authenticator app) | Yes | TOTP via Microsoft Authenticator, Google Authenticator, or similar. Satisfies the two-factor requirement. |
| Password + hardware token (YubiKey, RSA) | Yes | Hardware FIDO2 or OTP tokens are strong options, particularly for privileged accounts. |
| Windows Hello for Business (PIN + TPM) | Yes | PIN is bound to specific device hardware via TPM. Treated as two factors. Requires correct WHfB configuration. |
| Biometric + device (WHfB facial/fingerprint) | Yes | Something you are plus the device credential. Recognized as MFA when implemented via WHfB. |
| SMS text message code | Conditionally | NIST SP 800-63B classifies PSTN/SMS as a restricted authenticator. Not expressly prohibited under current Level 2 requirements, but a weaker option that should be replaced with an authenticator app or hardware token where practical. |
| Password alone, even a strong one | No | A single factor regardless of length or complexity is not MFA. |
| Password + security question | No | Both are something you know. Two instances of the same factor category do not satisfy MFA. |
Common 3.5.3 Gaps in Small DIB Environments
| Gap | Why It Creates a Finding |
|---|---|
| MFA on VPN only, no local MFA for admins | Local access to privileged accounts is explicitly required. VPN MFA does not cover an admin logging in at the server console or a local workstation. |
| MFA enforced for admins only, standard users not covered for remote access | 3.5.3 covers non-privileged accounts for network access. A remote standard user without MFA on VPN is a gap regardless of their role. |
| VPN MFA with a split-tunnel configuration passing some CUI traffic without VPN | If a non-privileged user can reach a CUI system without the VPN session that enforces MFA, that access path is not covered. |
| Cloud app accessible directly without VPN, no separate MFA enforced | A cloud-hosted file share, project management tool, or engineering application accessible from the public internet must have its own MFA enforcement if it provides access to CUI. |
| MFA implemented but not enforced (optional or skippable) | An MFA prompt that can be bypassed by clicking "skip" or "remind me later" does not satisfy the requirement. Enforcement must be mandatory. |
| Shared or generic admin accounts | MFA cannot be meaningfully applied to an account that multiple people use. Shared accounts also violate IA.L2-3.5.1 (individual identification). Both issues produce separate findings. |
Frequently Asked Questions
Yes. Non-privileged users connecting over VPN to reach CUI systems are performing network access to non-privileged accounts, which is explicitly covered by 3.5.3. Their role as a standard user does not exempt them. If they connect over your Cisco VPN and Duo MFA is enforced at that gateway, the requirement is satisfied for that access path. The question to verify is whether they have any other path to CUI that bypasses that MFA checkpoint.
It satisfies the network access scenario for privileged accounts, yes. If an admin authenticates through Duo at the VPN gateway and then accesses servers or systems over that session, the network access MFA requirement is met. However, 3.5.3 also requires MFA for local access to privileged accounts, which VPN MFA does not address. An admin who can bypass VPN and log in locally at a server or workstation without hitting an MFA prompt has a gap that needs a separate control: Duo Windows Logon agent or Windows Hello for Business.
Not under 3.5.3. Local access to non-privileged accounts is the one scenario the requirement does not cover. A standard user sitting at their office workstation, on-premises, logging in without VPN is out of scope for this specific practice. That said, if their workstation is Intune-managed and Azure AD joined, Windows Hello for Business may already be in use as the authentication method, which means MFA is happening anyway as a byproduct of your device management posture.
NIST SP 800-63B treats PSTN and SMS out-of-band authentication as a restricted authenticator due to SIM-swap and SS7 interception risks, but SMS is not expressly prohibited under current CMMC Level 2 guidance. Saying SMS automatically creates a 3.5.3 finding goes beyond what the official text supports. The safer and accurate characterization: SMS is not expressly prohibited under current Level 2 guidance, but it is a weaker, restricted option under NIST guidance and should be replaced with an authenticator app push or hardware token where practical.
Yes, when properly configured. Windows Hello for Business uses a PIN or biometric that is bound to the specific device via TPM hardware. This creates two distinct factors: the device itself (something you have) and the PIN or biometric (something you know or something you are). NIST and Microsoft documentation both recognize this as MFA-compliant. The key requirements are that WHfB is deployed through Intune or Group Policy in a way that enforces it rather than making it optional, and that the PIN meets minimum complexity requirements.
For cloud resource access in a hybrid environment, Conditional Access can enforce MFA as a condition before any resource is accessible, covering the network access scenarios for both account types. A Conditional Access policy requiring MFA for all users accessing CUI-relevant cloud applications is a strong, centrally managed enforcement point. Combined with Duo at the VPN gateway for on-premises resource access, hybrid environments can achieve clean 3.5.3 coverage with auditable enforcement across both paths.
Yes. 1TEN's Requirements Browser covers all 11 IA domain requirements including 3.5.3, with guided C3PAO assessment questions that walk through the two-scenario structure, the MFA methods in use, and the enforcement evidence assessors will request. The platform helps you document which tools enforce MFA at which access paths and links that evidence to the specific assessment objectives for 3.5.3 in your SSP. The IA domain guide at /cmmc-identification-authentication covers all 11 requirements in detail.