What MFA configuration meets CMMC IA.L2-3.5.3?

MFA is the most-tested authentication practice in CMMC and one of the practices most commonly cited as NOT MET at first assessment. The requirement is platform-agnostic; the implementation patterns vary by environment.

The practice text (NIST SP 800-171 Rev 2 § 3.5.3)

"Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts."

The CMMC practice identifier is IA.L2-3.5.3.

What MFA needs to cover

"Privileged accounts" includes administrators, service accounts with elevated access, and any account capable of changing security configuration. "Network access" includes any access where the user is not physically at the system.

Implementation patterns by environment

The OSA selects the mechanism. Common patterns:

• Microsoft 365 (GCC High, Azure Government, GCC): Entra ID Conditional Access policies as the enforcement mechanism — typically one requiring MFA for users accessing CUI applications, one requiring MFA plus device compliance for privileged accounts, and one blocking legacy authentication. Entra ID P2 (or M365 E3/E5) license is required for Conditional Access.
• AWS GovCloud: AWS IAM with MFA enforcement, AWS Identity Center / SSO with MFA, optionally federated through an identity provider.
• Google Workspace for Government: 2-Step Verification enforcement with security key, authenticator, or other approved factors.
• On-premises Active Directory: Smart card / PIV authentication, RADIUS-backed MFA (Duo, RSA SecurID, etc.), or IdP-federated MFA. Privileged Access Workstations are common for admin scenarios.
• Federated identity stacks: Okta, Ping, Auth0, AD FS — MFA enforced at the federation layer.
• Hardware tokens: FIDO2 / WebAuthn keys for high-assurance scenarios, particularly for break-glass and privileged accounts.

What every implementation must address

• Legacy authentication blocking. Any path that bypasses MFA — legacy Exchange protocols (POP, IMAP, SMTP-AUTH), basic auth on web services, older RDP modes — must be blocked. Otherwise MFA is theoretical.
• Privileged account hardening. Privileged accounts usually need stronger factors than user accounts — FIDO2 or hardware tokens rather than SMS, conditional access tied to compliant device, just-in-time elevation.
• Service account handling. Service accounts that can interactively sign in need MFA or technical prevention of interactive sign-in.
• Break-glass accounts. Excluded from standard MFA Conditional Access — require alternative strong authentication (FIDO2 keys, hardware tokens) plus monitoring and alerting on use.
• Enforcement state verification. Whatever the platform, verify enforcement is on (not in report-only mode) and applies to the actual user population.

What evidence the assessor will examine

• Configuration evidence of the MFA enforcement mechanism — conditional access policies, IAM settings, smart card / PIV configuration, RADIUS configuration — showing policy state, scope, and required factors.
• Live demonstration of an MFA challenge for both a privileged and a non-privileged account.
• Sign-in logs (or equivalent) showing MFA success and any MFA failures.
• Evidence that legacy authentication or other MFA-bypass paths are blocked.
• Documentation of MFA exceptions (if any) with risk acceptance and compensating controls.

Why 3.5.3 cannot be on a POA&M

3.5.3 is on the restricted list per 32 CFR § 170.21(a)(2) and consistently identified in CAP guidance as a practice that cannot be POA&M'd. NOT MET on 3.5.3 fails the assessment regardless of total score. MFA gaps must be remediated before the assessment, not deferred.

Common errors

• MFA enforced via legacy per-user toggles rather than centralized policy. Per-user toggles in some platforms can be bypassed by legacy authentication and are inferior to centralized conditional-access enforcement.
• Legacy authentication not blocked. If legacy auth still works, MFA can be bypassed for any account capable of legacy protocols — regardless of platform.
• Service accounts excluded from MFA without compensating controls. If a service account has interactive sign-in capability, it needs MFA or it needs to be technically prevented from interactive sign-in.
• Break-glass accounts without alternative strong authentication. Break-glass accounts excluded from standard MFA require FIDO2 keys, hardware tokens, or equivalent strong alternative authentication, with monitoring and alerting on use.
• SMS-only MFA for privileged accounts. SMS is the weakest second factor; many assessors expect FIDO2, hardware tokens, or authenticator-app for privileged accounts.
• Enforcement in report-only or testing mode. A policy that doesn't enforce isn't enforcement — verify the operational state, not the configured intent.