Multi-Factor Authentication for CMMC Level 2: What Defense Contractors Get Wrong

There is no security control on the CMMC Level 2 scorecard that looks more solved than multi-factor authentication. Every modern identity provider supports it. Every defense contractor I have ever audited claims to enforce it. Most security awareness training covers it in the first ten minutes. And yet, year after year, multi-factor authentication failures sit near the top of the assessment-finding tables published by C3PAOs and the Defense Industrial Base Cybersecurity Assessment Center.

The reason is straightforward: the practice IA.L2-3.5.3 in NIST SP 800-171, and its sibling controls in the IA and AC families, are far more specific than the marketing language on most identity-provider feature pages. An assessor is not asking whether your users tap a notification on a phone before logging in. The assessor is asking whether every privileged account, every network access path, and every CUI-bearing system enforces MFA in a manner that resists modern attacker techniques — and whether the cryptographic modules underneath that MFA are FIPS-validated.

The gap between the marketing claim and the assessment standard is where contractors lose points. This article walks through what IA.L2-3.5.3 actually requires, what phishing-resistant MFA means in 2026, where push-based MFA falls short, and how to implement an MFA program that survives a C3PAO walkthrough without rebuilding your entire identity stack.

What the Control Actually Says

The plain text of NIST 800-171 Revision 2 practice 3.5.3 is short: "Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts." Every word in that sentence does work, and missing any of them produces a finding.

"Local and network access" means MFA is required for two distinct access paths to privileged accounts. Network access is the obvious one — administrators authenticating over SSH, RDP, console URLs, or any remote protocol. Local access is the failure mode most contractors miss. If your domain administrator can walk up to a Windows server console and log in with a password alone, you are out of compliance regardless of how aggressively you require MFA on the VPN.

"Privileged accounts" is broader than most contractors interpret. The NIST 800-171 Revision 2 definition pulls from NIST SP 800-53, which defines a privileged account as one with "authorizations that are significantly greater than those available to the majority of users." In a typical defense contractor environment, that includes domain administrators, local administrators, root accounts on Linux systems, database administrators, hypervisor administrators, identity-provider tenant administrators, M365 Global Administrators, AWS or Azure root accounts, network device administrators, backup administrators, and the service desk accounts that can reset passwords for other privileged accounts. Service accounts with elevated permissions are also in scope when interactively used.

"Network access to non-privileged accounts" closes the loop on the standard user population. Every CUI-handling employee logging in remotely — through the VPN, through a cloud workspace, through a SaaS that handles CUI, through a virtual desktop — must complete MFA before that authentication succeeds. The only carve-out is purely local console authentication for non-privileged users, and even there, most assessors expect MFA enforcement as a baseline good practice.

NIST 800-171 Revision 3, which contractors must transition to following the publication of DoD's transition guidance in late 2025, restructures these requirements into the IA-02 family but preserves the substantive standard. The wording shifts, but the assessment evidence does not.

Phishing-Resistant MFA Is the New Baseline

For years, "MFA" in the federal context meant any combination of two factors from the password / token / biometric trio. That definition is no longer sufficient at the policy level, and it is increasingly insufficient at the operational level.

OMB Memorandum M-22-09, issued in January 2022, directed federal agencies to deploy "phishing-resistant" MFA across enterprise systems. CISA followed in late 2022 with a guidance document distinguishing phishing-resistant MFA from app-based MFA from SMS-based MFA. The CMMC final rule does not require phishing-resistant MFA explicitly for Level 2 contractors. But CMMC Level 3 inherits NIST SP 800-172 controls, and NIST 800-172 enhancement 3.5.3e directly requires "FIDO2 or PIV-based multi-factor authentication" for privileged accounts.

Even at Level 2, the assessor lens is shifting. The Joint Surveillance Voluntary Assessment results from 2024 and 2025 showed C3PAOs increasingly probing MFA implementations and flagging push-notification systems for residual phishing risk. The assessor cannot fail you outright for using push-based MFA at Level 2 — the practice does not require phishing resistance — but they can question its adequacy under the broader IA-2 control narrative, and they will note it in the assessment report.

The practical guidance for 2026: if you are building or rebuilding your MFA stack this year, plan for phishing-resistant MFA on privileged accounts now. The technologies that meet that standard are well understood:

• FIDO2 / WebAuthn security keys — hardware tokens like YubiKey 5 Series, Feitian, Google Titan, or HyperFIDO. Resistant to phishing because the cryptographic challenge is bound to the legitimate domain.
• PIV and PIV-Derived Credentials — the smart-card path used across the DoD and federal civilian agencies. Strong, well-validated, but operationally expensive for small contractors.
• Platform authenticators with attested device binding — Windows Hello for Business with hardware-backed keys, Apple Platform SSO with Secure Enclave, mobile credentials bound to TPM or Secure Element. Useful for non-privileged users when the device fleet is tightly managed.

Push notifications, OTP codes from authenticator apps, and SMS one-time passwords are not phishing-resistant. They can satisfy IA.L2-3.5.3 at Level 2, but they will not pass a Level 3 assessment, and they will increasingly attract assessor scrutiny at Level 2.

The FIPS 140 Trap Inside MFA

Defense contractors often discover during their first C3PAO assessment that the cryptographic module question reaches into their MFA stack. Practice SC.L2-3.13.11 requires FIPS-validated cryptography "to protect the confidentiality of CUI." When MFA authenticates an account that ultimately accesses CUI, the cryptographic operations underneath the authentication exchange come into scope.

In practical terms, this means:

• The hardware security keys used for FIDO2 authentication should be FIPS 140-2 or 140-3 validated for use in CUI environments. YubiKey 5 FIPS Series, for example, is validated; the standard YubiKey 5 is not. The product line is identical in form factor, but only the FIPS variant satisfies the SC.L2-3.13.11 evidence requirement.
• The TLS sessions between your identity provider and your relying parties must use FIPS-validated cipher suites. Most modern providers comply by default, but Azure AD tenants left on legacy TLS configurations and self-hosted ADFS environments with non-FIPS OpenSSL builds are common failure points.
• Authenticator applications that generate OTP codes must use FIPS-validated cryptographic libraries if the resulting authentication protects CUI access. This is one of the most common gaps in small-contractor environments where generic Google Authenticator or Microsoft Authenticator deployments are assumed to be compliant. The FIPS posture of those apps depends on the operating system's cryptographic provider and the app version.

If you are running an MFA program that uses FIDO2 keys you bought retail, with TLS configurations you have not validated, on authenticator apps you have not inventoried — your assessment evidence on SC.L2-3.13.11 is going to be thin. The control is not just about your CUI files; it is about every cryptographic operation that protects access to them.

The Five MFA Failure Modes Assessors See Most Often

Patterns repeat across assessments. These five gaps appear in nearly every Level 2 finding I review.

1. Service Accounts Without MFA

Service accounts are exempt from interactive MFA by necessity — a scheduled task cannot tap a phone notification. But they are not exempt from compliance scrutiny. The assessor will ask three questions about every privileged service account: how are credentials rotated, where are they stored, and what compensating control prevents interactive use of the account.

The expected answer involves a vaulted credential, automated rotation, conditional access policies that block interactive sign-in for the service account, and monitoring that alerts on any deviation. Contractors who answer "we just have a long password" lose points.

2. Break-Glass Accounts Without MFA

Every defense contractor needs at least one break-glass administrative account that can recover access if the MFA system itself fails. That account should be configured with strong physical-token MFA stored in a sealed safe, not exempted from MFA. The assessor will ask to see the safe, the seal procedure, and the audit logs showing when the seal was last opened.

The failure mode is the "MFA-exempt" break-glass account locked behind a long password. That is operationally tempting and assessment-fatal.

3. Network Devices Authenticated by Local Credentials

The IA controls do not stop at user authentication. Switches, routers, firewalls, wireless controllers, and out-of-band management interfaces all require MFA for administrative access. The default configuration on most network devices uses local username-and-password authentication. RADIUS or TACACS+ integration with an identity provider that enforces MFA is required to meet the standard, and many small contractors discover this gap during their first assessment.

4. Inherited MFA from a SaaS That Is Not Properly Federated

A defense contractor uses a CUI-relevant SaaS — a project management tool, a CAD vault, a contract repository. The SaaS supports MFA. The contractor turns on MFA inside the SaaS. The assessor then asks whether the SaaS authentication is federated with the contractor's identity provider, whether the MFA enforcement is logged in a central system, and how the contractor knows MFA is consistently enforced across every user.

If the answer is "we trust the SaaS to do it," the evidence is insufficient. Federated SSO with conditional access policies, or at minimum centralized logging of authentication events, is the expected pattern. Standalone SaaS MFA satisfies the technical letter of the control but creates an audit and visibility gap that assessors flag.

5. Privileged Access Workstations Without Token Binding

For Level 3 contractors and for Level 2 contractors with mature implementations, privileged access workstations are the right architecture for administrative work. An assessor will look for the workstation enrollment process, the binding between the workstation's TPM and the administrator's credential, and the policy that blocks privileged authentication from any other device.

When that binding is missing, an administrator can use their FIDO2 key on any laptop in the building, which means the strongest MFA factor in the environment is a tap of a key sitting in someone's pocket. The control envelope is technically met, but the operational protection is thin.

A Practical Implementation Sequence

For a small or mid-sized defense contractor pursuing Level 2 in 2026, the MFA program should be built in this order:

Step 1. Inventory privileged accounts. Build a single source of truth listing every account in the environment with elevated privileges, including domain accounts, local administrators, cloud-tenant administrators, network-device accounts, and database administrators. Tie each account to a human owner and a documented purpose. This list is the input to every subsequent step.

Step 2. Federate everything. Move all CUI-relevant authentication into a single identity provider. Microsoft Entra ID (formerly Azure AD), Okta, and Ping Identity are the most common choices for defense contractors with a Microsoft footprint. The goal is one identity store, one MFA policy engine, and one audit log.

Step 3. Deploy FIPS-validated hardware keys for privileged accounts. Standardize on a single FIDO2 key model — the YubiKey 5 FIPS Series is the dominant choice in this market — and enroll every privileged account with at least two keys (primary plus backup). Set the conditional access policy to require FIDO2 for any privileged role.

Step 4. Roll out phishing-resistant MFA for non-privileged users on a defensible schedule. Platform authenticators with hardware-backed keys on Windows 11 Pro for Workstations, Windows Hello for Business with attestation, or Apple Platform SSO covers the standard user population on managed devices. For BYOD or partially managed devices, deploy hardware keys.

Step 5. Document the controls. Update the System Security Plan to reflect the actual implementation — which accounts use which factor, where the policy is enforced, how exceptions are managed. Build the evidence artifacts: screenshots of conditional access policies, exports of MFA registration data, copies of FIPS validation certificates for the hardware tokens, and the break-glass procedure.

Step 6. Monitor and prove enforcement. A C3PAO will ask for evidence that MFA is actually being enforced, not just configured. Pull thirty days of sign-in logs showing the MFA factor used on every privileged authentication. Pull the report of any sign-in that bypassed MFA and the justification for each. This is where the assessment is won or lost.

Documentation and Policy Alignment

The technical implementation is only half the work. The C3PAO will ask for policies that explicitly govern MFA — the authentication policy, the privileged access policy, the conditional access policy, and the procedures that operationalize each. Many contractors discover that their off-the-shelf templates do not match what they actually implemented, which creates inconsistencies that assessors flag.

If you are building or rebuilding this documentation, the TalonPoint PolicyPack includes a NIST-CMMC Authentication and Identification Policy and a Privileged Access Management Policy that are pre-aligned to the IA family practices. These are not a substitute for tailoring — every contractor's environment is different — but they remove the friction of starting from a blank document and ensure the control mappings are correct.

What an Assessor Wants to See in the Room

When a C3PAO sits down at your assessment and starts walking through the IA family, here is the evidence flow that produces a clean finding:

1. A scoping diagram that shows every CUI-bearing system, every authentication path into it, and every account that can reach it.
2. A privileged account inventory matching the diagram, with each account tied to a human and a purpose.
3. A conditional access policy export showing the MFA enforcement rules in plain English.
4. A representative sample of sign-in logs covering thirty to ninety days, demonstrating that MFA was used on every privileged authentication and on every network access from a non-privileged user.
5. Documentation of the MFA factors in use, including the FIPS validation status of each token.
6. The exception register showing every account exempted from MFA, with a documented compensating control and approval signature.
7. The break-glass procedure and physical safe verification.

A contractor who walks into the room with these artifacts will close out the IA family in an afternoon. A contractor who walks in without them will spend three days defending the implementation, and the assessment report will reflect every gap.

The Bottom Line

Multi-factor authentication is not the hardest CMMC control to implement. It is one of the hardest to implement correctly enough to survive a C3PAO walkthrough. The gap is rarely the technology — the products are mature and widely deployed. The gap is in the scope of enforcement, the cryptographic posture of the modules underneath, and the evidence trail that proves what you actually did.

If your MFA program covers the network-access path and ignores the local-console path, you have a finding waiting to happen. If your privileged users tap push notifications on a phone, your Level 2 assessment may survive but your Level 3 path will not. If your FIDO2 keys are the retail variant rather than the FIPS variant, your cryptography evidence is thin.

The good news is that the fix is incremental, not architectural. A defense contractor with a Microsoft-centric stack, a competent IT lead, and a one-quarter project window can move from a brittle MFA posture to a defensible one without ripping out infrastructure. Start with the privileged account inventory, federate everything, standardize on FIPS-validated keys for administrators, and document what you actually deployed. The assessment will follow.

---

TalonPoint Security helps defense contractors prepare for CMMC Level 2 assessments through documentation, control mapping, and pre-assessment readiness reviews. Our PolicyPack includes the authentication, identification, and privileged access policies referenced in this article, aligned to NIST 800-171 Revision 2 and Revision 3.