Multi-Factor Authentication Methods Acceptable Under CMMC

CMMC Level 2 expects you to enforce multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. NIST SP 800-171 Rev. 2 sets that requirement in IA.L2-3.5.3 and adds a replay-resistance requirement in IA.L2-3.5.4. Remote maintenance sessions also fall under an MFA requirement in MA.L2-3.7.5. You need factor combinations that meet the rule, identity methods that your environment supports, and clean evidence.

CMMC definition of MFA

NIST SP 800-171 Rev. 2 establishes the control language that CMMC Level 2 adopts. IA.L2-3.5.3 requires use of multifactor authentication (MFA) for local and network access to privileged accounts, and for network access to non-privileged accounts. IA.L2-3.5.4 requires you to employ replay-resistant authentication for those same access paths. MA.L2-3.7.5 requires MFA for nonlocal maintenance sessions over external connections.

The DoD Level 2 Assessment Guide and the NIST body of work define MFA as two or more different factor types. The factor categories are well known across federal guidance: something you know, something you have, and something you are. The guide also calls out common physical authenticators, including hardware tokens that produce time-based or challenge-response codes, and smart cards.

CMMC does not name a vendor or a single product. You pick authenticators that use distinct factors and you apply them to the access types the controls name.

For a quick mapping context on the full set of Level 2 controls, see our overview in NIST 800-171 to CMMC Level 2 Mapping.

Accepted factor types and authenticators

Knowledge factors cover a password or PIN. Every account will carry a knowledge factor as a baseline. A knowledge factor alone never meets IA.L2-3.5.3. Pair it with a possession or inherence factor.

Possession factors cover something you bind to the user. Common examples in the federal field include smart cards such as PIV or CAC, FIDO2 security keys, device-bound passkeys, and OATH tokens. Microsoft Entra ID also supports app-based one-time codes and push approvals through Microsoft Authenticator. Hardware tokens and smart cards meet the physical authenticator examples the DoD guide describes.

Inherence factors cover biometrics. Windows Hello for Business uses device-bound key material and can add a biometric gesture to unlock the private key on a managed device. Fingerprint or face factors can contribute to an MFA pair when the system gates the cryptographic action with that biometric.

Replay resistance matters. IA.L2-3.5.4 pushes you to methods that prevent an attacker from reusing a captured response. Possession factors that perform a cryptographic challenge, such as FIDO2 keys, device-bound passkeys, Windows Hello for Business, or certificate-based authentication, align with that aim. Knowledge plus SMS can raise risk because SMS codes can face interception or redirection. CISA advises agencies to prefer phishing-resistant options.

Microsoft identity methods that fit

Microsoft documents the MFA methods that Microsoft Entra ID supports across commercial and US Government clouds. The platform supports these methods in GCC, GCC High, and DoD environments, with feature availability noted on Microsoft Learn.

Certificate-based authentication (CBA). You can use X.509 client certificates against Microsoft Entra ID. In Office 365 GCC High and DoD, a federated identity design enables use of PIV and CAC cards.
FIDO2 security keys and device-bound passkeys. Microsoft Entra ID supports FIDO2 security keys and device-bound passkeys as phishing-resistant factors.
Windows Hello for Business (WHfB). WHfB uses key-based authentication tied to the device and can use a biometric or PIN to unlock the private key.
Microsoft Authenticator. Push approvals with number match and time-based one-time passwords can serve as the possession factor in an MFA pair.
OATH tokens. Hardware or software OATH tokens generate time-based one-time codes.
SMS and voice. The service supports SMS and voice call codes. These methods count as possession factors, though federal guidance ranks them lower for phishing resistance.

Microsoft Entra documentation outlines how these methods work and where Microsoft offers them. The feature availability page calls out the support scope in GCC, GCC High, and DoD. The Microsoft public sector identity blog describes phishing-resistant options for US government organizations, including CBA with PIV or CAC, FIDO2 security keys, device-bound passkeys, passkeys in Microsoft Authenticator, and Windows Hello for Business.

You can enforce method use through Conditional Access. Many teams gate risky sign-ins, privileged role assignments, and remote administration with MFA and restrict which methods can satisfy the challenge. We describe common policy patterns in Conditional Access for DFARS 7012.

Phishing resistance and method selection

CMMC sets a floor. CISA and Microsoft urge you to exceed that floor for high-risk accounts. CISA recommends phishing-resistant authentication for all users and calls out CBA, FIDO2 security keys, Windows Hello for Business, and device-bound passkeys as the preferred options. Microsoft promotes the same set across its government identity stack.

Apply those options where the risk and control intent are highest.

Privileged roles. Require phishing-resistant methods for administrators and anyone with access to identity, security, device management, or production data.
Remote administration and maintenance. Enforce phishing-resistant MFA for nonlocal maintenance sessions to satisfy MA.L2-3.7.5 and reduce replay risk.
External access paths. Use Conditional Access to force stronger methods for sign-ins from outside trusted networks or compliant devices.

You can keep app-based OTP or push approvals for lower-risk users while you move high-risk roles to CBA, FIDO2, device-bound passkeys, or WHfB. That mix meets the controls and follows federal guidance.

Evidence assessors expect

Assessors ask you to name the accounts in scope, show policy and technical enforcement, and demonstrate the result.

Start with an inventory. Identify privileged accounts, non-privileged accounts, and service principals with administrative rights. Map the access types each account uses, including local access to servers or endpoints and network or remote access. That inventory drives coverage for IA.L2-3.5.3 and IA.L2-3.5.4.

Publish a policy that mandates MFA for the access types in scope and names the approved authenticators. Reference CBA, FIDO2, device-bound passkeys, WHfB, Authenticator, OATH tokens, and the stance on SMS and voice. State how you restrict methods for administrators and remote maintenance.

Show enforcement. Present Conditional Access policy exports, screenshots, and reference IDs that enforce MFA and method restrictions for the target groups. Include Entra ID Authentication Methods policy settings and any federation configuration that enables PIV or CAC with Office 365 GCC High or DoD.

Demonstrate operation. Capture test results that show administrators and non-privileged users performing MFA with the approved methods across local privileged access and network access paths. For remote maintenance, show the nonlocal session workflow where the technician authenticates with MFA before session establishment to meet MA.L2-3.7.5.

Record exceptions. If a system or user cannot meet the target method, document the exception, the compensating control, and the plan to close the gap. Update the System Security Plan and the POA&M accordingly. Our guide on System Security Plan content for NIST 800-171 outlines a structure that fits this evidence.

The Cyber AB CAP v2.0 explains the assessment process and the role of objective evidence. Use that process view to shape how you present your artifacts.

Common implementation mistakes

Treating MFA as a single setting. Teams switch on MFA prompts but never classify accounts or access types. Assessors then find local privileged access without MFA and network non-privileged paths that do not enforce MFA.
Allowing weak methods for admins. Administrators use SMS or voice while policy permits stronger options. Move admins to CBA, FIDO2, device-bound passkeys, or WHfB and restrict other methods for those roles.
Ignoring replay resistance. Teams meet IA.L2-3.5.3 but skip IA.L2-3.5.4. Pick methods that perform a cryptographic challenge for high-risk roles and remote maintenance.
Forgetting service accounts and break-glass. Service principals and emergency access accounts bypass MFA by design. Limit their scope, lock them down with Conditional Access exclusions only where needed, and monitor their use.

Practical selection guidance

Start by classifying users and access paths. Group administrators, contractors with remote access, and users who touch CUI. Decide which methods you will approve. For high-risk roles, target CBA with PIV or CAC in GCC High or DoD, or FIDO2 keys, device-bound passkeys, or WHfB in Entra ID. Keep Microsoft Authenticator or OATH tokens for general users where a phishing-resistant factor is not yet practical. Use Conditional Access to enforce both the presence of MFA and the allowed methods, and to require device compliance when you use WHfB.

Document the design in the SSP, record the rollout plan in the POA&M, and retain exports and test results. That set gives assessors a clear line from requirement to control to evidence.