Multi-Factor Authentication for CMMC Level 2: Implementing IA.L2-3.5.3

IA.L2-3.5.3 (Multifactor Authentication) is one of two CMMC Level 2 requirements that 32 CFR 170.24 scores for partial implementation. It is also a requirement that 32 CFR 170.21 bars from the POA&M behind a Conditional status. Those two rules make MFA a gate. A contractor can score 107 out of 110 and still have no CMMC status in SPRS. The obligation doesn’t depend on a CMMC phase: DFARS 252.204-7012 still requires NIST SP 800-171 Revision 2, including 3.5.3.

How MFA fits a Zero Trust design is covered in how Zero Trust maps to CMMC. Encryption under SC.L2-3.13.11 has its own page: FIPS-validated encryption for CMMC.

What does IA.L2-3.5.3 require?

IA.L2-3.5.3 requires multi-factor authentication on three access paths. Its text comes verbatim from NIST SP 800-171 Revision 2: “Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.” NIST SP 800-171A splits it into four assessment objectives. Determine if:

• [a] privileged accounts are identified;
• [b] multifactor authentication is implemented for local access to privileged accounts;
• [c] multifactor authentication is implemented for network access to privileged accounts; and
• [d] multifactor authentication is implemented for network access to non-privileged accounts.

The requirement is MET only when all four objectives are met.

The CMMC Assessment Guide’s Further Discussion says to use two or more factors “to verify privileged account holders’ identity regardless of how the user is accessing the account.” For standard accounts, it requires them “for non-privileged users accessing the system over a network.”

A privileged user, in NIST’s definition, is “a user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.” NIST maps 3.5.3 to one SP 800-53 control enhancement per path. IA-2(1) covers network access to privileged accounts, IA-2(2) network access to non-privileged accounts and IA-2(3) local access to privileged accounts.

IA.L2-3.5.3 works alongside other requirements. The Assessment Guide says it enhances IA.L2-3.5.2 (Authentication) and complements the remote-access requirements. Those include MA.L2-3.7.5 (Nonlocal Maintenance), which requires MFA for nonlocal maintenance sessions.

Local, network and remote access

Scope turns on the access definitions in NIST SP 800-171 Revision 2:

• Local access is access “obtained by direct connections without the use of networks,” such as signing in at a server console.
• Network access is access “obtained through network connections (i.e., nonlocal accesses).” NIST’s footnote lists “local area network, wide area network, Internet,” so a sign-in over the office LAN is network access.
• Remote access is “a type of network access that involves communication through external networks,” such as a VPN connection from home.

Remote access is a type of network access, so objectives [c] and [d] cover it too.

Why Revision 2 still governs

NIST’s PDFs of SP 800-171 Revision 2 and SP 800-171A (June 2018) now carry a “withdrawn” notice dated May 14, 2024, pointing to the Revision 3 editions. DoD still requires both. 32 CFR 170.2 incorporates them by reference, and the DFARS 252.204-7012 text in class deviation 2026-O0025 names Revision 2.

Which logins need multi-factor authentication?

Every sign-in to a privileged account on the information system needs MFA, whether at the console or over a network. Standard accounts need MFA for every network sign-in, and DoD’s guidance treats a desktop logon over the office LAN as network access. A standard user on a standalone computer with no network connection may use a single factor. DoD’s Cyber DFARS FAQs (Revision 4, June 2024) answer most edge cases. That FAQ is guidance on DFARS 252.204-7012. It predates class deviation 2026-O0025 (Revision 3 signed September 3, 2026), which now carries the CMMC and 7012 clauses. So record the treatment you adopt in the SSP and confirm it with your assessor.

Published guidance splits on the LAN row. DoD’s FAQ also says: “Typically, organizational desktops are used for network access and so the user has to use MFA to access their network account.” At least two practitioner guides updated in 2026 say MFA isn’t required, or not explicitly required, for a standard user’s desktop logon. Nothing in the CMMC Assessment Guide addresses the case directly. In Deep Fathom’s view, DoD’s reading is the safer basis for an SSP.

What counts as multi-factor authentication for CMMC?

MFA for CMMC means two or more different factors. A factor is something you know, like a password or PIN, or something you have, like a token or smart card. It can also be something you are, such as a fingerprint. A password plus a PIN is two items of the same factor. NIST says the requirement “should not be interpreted as requiring federal Personal Identity Verification (PIV) card or Department of Defense Common Access Card (CAC)-like solutions,” and hard or soft tokens both qualify. IA.L2-3.5.3 doesn’t require phishing-resistant MFA. NIST and CISA recommend it.

A FIDO2 key counts as two factors only when a PIN or biometric activates it. That’s Deep Fathom’s reading of NIST’s definition, since a key used without activation is one factor.

Phishing resistance is where federal rules and contractor rules part. NIST SP 800-63B-4 says “Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems.” Applications at its AAL2 level must also offer a phishing-resistant option. Those mandates address agencies and federal systems. In Deep Fathom’s reading, they don’t reach a contractor’s own system under 3.5.3. NIST also says one-time-code and out-of-band authenticators “SHALL NOT be considered phishing-resistant.” CISA calls phishing-resistant MFA “the gold standard” in its phishing-resistant MFA fact sheet. For how phishing resistance fits a Zero Trust design, see how Zero Trust maps to CMMC.

Replay resistance is a separate requirement. IA.L2-3.5.4 (Replay-Resistant Authentication) requires replay-resistant mechanisms for network access to privileged and non-privileged accounts. DoD’s FAQ gives Transport Layer Security (TLS) and time-synchronous or challenge-response one-time authenticators as examples. Under 32 CFR 170.24 it is worth 1 point.

How does partial MFA affect the score and a POA&M?

IA.L2-3.5.3 is scored at 3 or 5 points. A POA&M that lists any gap can’t support a Conditional status. Under 32 CFR 170.24, “three (3) points are subtracted from the maximum score if MFA is implemented only for remote and privileged users,” and “Five (5) points are subtracted from the maximum score if MFA is not implemented for any users.” 32 CFR 170.21 grants a Conditional Level 2 status only when no POA&M item is worth more than 1 point. It makes one exception, for SC.L2-3.13.11 encryption. For an MFA gap, the SPRS Level 2 self-assessment entry guide says the status type is “No CMMC Status regardless of score.”

Four details decide real cases:

• The text of 32 CFR 170.24 names one 3-point pattern. That pattern is MFA for remote and privileged users and nobody else. A different gap, such as MFA on the VPN and cloud applications but not at the server console, is NOT MET under objective [b]. The rule’s scoring table (Table 7) scores any “Partially effective implementation” at 3 points and a “Non-effective (not implemented at all)” one at 5, without saying which patterns count as partial. The DoD Assessment Methodology values 3.5.3 at “3 to 5” points, so any deduction exceeds 1 point and the POA&M outcome is the same.
• A partial rollout is NOT MET. The DoD Assessment Methodology says that if a rollout “is only 75% complete, and there is a plan of action still being implemented, 3.5.3 will be considered ‘not implemented’.” 32 CFR 170.24 adds that a POA&M “is not a substitute for a completed requirement.”
• Award follows status. Where a solicitation designates Level 2 (Self) under DFARS 252.204-7025, an offeror without a current CMMC status in SPRS at that level and a current affirmation is not eligible for award. See CMMC self-assessment vs C3PAO certification.

Last, a C3PAO may re-evaluate a NOT MET requirement during its assessment and for 10 business days after it. That applies only when additional evidence shows the requirement “has been MET,” the change doesn’t limit other requirements already scored MET, and the findings report hasn’t been delivered. See re-evaluation and POA&M under CMMC.

Worked example: 107 out of 110 and no status

A contractor self-assesses against all 110 requirements, and 109 are MET. MFA is in place for remote users and administrators. Standard users sign in to the office network with a password alone.

The ratio isn’t the problem. 32 CFR 170.24 still requires a POA&M for the MFA gap, but 32 CFR 170.21 doesn’t let that POA&M support a Conditional status. SPRS sets the status type to No CMMC Status “regardless of score,” and the contractor has no Level 2 (Self) status to affirm for a bid that requires one.

Extend MFA to standard users, and the requirement is MET. Now the score is 110. That’s a Final Level 2 (Self) result the Affirming Official can affirm.

How to implement MFA across a CUI environment

Implementing MFA for CMMC Level 2 starts with an inventory of privileged accounts and access paths. Then enforce a second factor on every path the requirement covers, document the result in the SSP, and test each path before an assessment. Deep Fathom recommends the nine-step sequence below, organized by the four assessment objectives. Where DoD and NIST text is silent, the step says so. Whether an implementation meets each objective is the assessor’s call.

1. Inventory privileged accounts and access paths [a]. List every account with security-relevant rights. That includes domain and local administrators, cloud tenant and identity-provider administrators, hypervisor and network-device administrators, and any service account a person can sign in to. Map each account type to the paths it uses: console, office LAN, VPN, cloud portal, VDI, mobile device and vendor maintenance.
2. Choose authenticators. Give administrators a phishing-resistant option, such as a FIDO2 key or a smart card. For other users, follow CISA’s ranking in the authenticator table above.

Enforcement comes next, path by path.

3. Enforce MFA on network paths [c], [d]. Require MFA in the identity provider’s sign-in policies for cloud applications and email, on the VPN, and on the VDI gateway, separate from any unmanaged client. Turn off legacy authentication protocols that accept a password without the MFA prompt.
4. Enforce MFA on local privileged logon [b]. Administrator sign-ins at a server or workstation console need two factors, through a smart card or other hard token or an MFA agent for local logon. Set any agent to fail closed. Vendor documentation shows the risk. Duo’s Windows Logon agent (Duo documentation) has a fail-open setting under which users can log in “without completing two-factor authentication if the Duo Security cloud service is unreachable.” Its installers up to version 4.2.2 enabled that setting by default.
5. Route network-device administration through an MFA-protected path [b], [c]. DoD’s FAQ says MFA on each router or database “is not a requirement,” because 3.5.3 governs access to the information system. In Deep Fathom’s view, the practical way to meet [b] and [c] for devices that can’t take a second factor is to reach them only through a jump host or bastion that enforces MFA.

Then settle the edge cases and the remaining access paths.

6. Decide how service and break-glass accounts are handled. No DoD or NIST CMMC text addresses either account type directly, and NIST’s access definitions include “processes acting on behalf of users.” In Deep Fathom’s view, a defensible approach is a service account that no person can sign in to interactively, with least privilege and an SSP entry explaining why MFA cannot apply. Any account a person can sign in to with privileged rights follows 3.5.3. For emergency (break-glass) accounts, Microsoft’s guidance for its Entra ID directory shows one workable pattern: keep a passkey or certificate-based method on them, and exclude them from conditional access policies that block or restrict sign-in.
7. Cover mobile access and vendor maintenance. For mobile access, require MFA at the system a phone or tablet reaches. For outside vendors, DoD’s FAQ allows a “one-time” MFA “through the use of a password and a separately provided token (e.g., PIN via text message to a cell phone)” when the technician is known and trusted.

Finish with the records.

8. Document it in the SSP and the CRM. The SSP describes the configuration in place for each path, the privileged-account list and any exceptions. Where an external provider runs part of MFA, its customer responsibility matrix names who owns each objective. See how to write a CMMC System Security Plan.
9. Test every path and keep the records. Sign in as an administrator and as a standard user over each path. Capture the MFA prompt and the matching sign-in log entry, and check that no legacy protocol or unmanaged route skips the second factor.

Some systems can’t take MFA at all. The Assessment Guide notes that for “a mission system that cannot be altered,” additional “technical or physical solutions can provide security.” It also defines an enduring exception, for cases such as operational technology and test equipment, as a circumstance that “must be documented within a system security plan.” Record any such case in the SSP and confirm its treatment with the assessor.

Does MFA have to be FIPS-validated?

No. There’s no FIPS requirement in IA.L2-3.5.3. FIPS validation comes from SC.L2-3.13.11 (CUI Encryption): “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” The Assessment Guide applies it to CUI “transmitted or stored outside the protected environment of the covered OSA information system (including wireless/remote access).” So the VPN or TLS session that carries CUI over a remote connection falls under 3.13.11, whatever authenticator the user signs in with.

Where does the confusion come from? NIST SP 800-63B-4 requires FIPS 140 validation for “cryptographic authenticators procured by federal agencies” and for verifiers “operated by or on behalf of federal agencies.” Those rules bind federal agencies.

On the encryption side, per NIST’s FIPS 140-3 transition page, FIPS 140-2 validations stayed active through September 21, 2026. They moved to NIST’s Historical list on September 22, 2026. NIST says that “Even on the historical list, CMVP supports the purchase and use of these modules for existing systems.” As of September 2026, no DoW or Cyber AB guidance says how assessors treat Historical modules under SC.L2-3.13.11.

Scoring differs as well. SC.L2-3.13.11 is the only requirement worth more than 1 point that 32 CFR 170.21 allows on the POA&M behind a Conditional status, and only when encryption is employed but not FIPS-validated. IA.L2-3.5.3 has no such exception. For modules, certificates and the Historical list, see FIPS-validated encryption for CMMC.

What do assessors examine for IA.L2-3.5.3?

Assessors examine documents, interview staff and test the MFA mechanisms against each of the four objectives. NIST SP 800-171A’s objects to examine are the identification and authentication policy and procedures, the SSP, system design documentation, configuration settings, audit logs and the list of system accounts. Interviews include system or network administrators and staff with account-management and information security responsibilities. Tests cover the “mechanisms supporting or implementing multifactor authentication capability.” Evidence must be final. The Assessment Guide says drafts of policies or documentation “are not eligible to be used as evidence,” and that “Most objectives will require testing.”

Deep Fathom built the evidence and test columns from the 800-171A objects. They’re suggestions. The Assessment Guide’s own methods block for 3.5.3 lists authenticator-management personnel and mechanisms. Those differ slightly from 800-171A, which 32 CFR 170.2 incorporates by reference.

Who is responsible when an MSP or cloud provider runs MFA?

Even when a provider runs MFA, the contractor answers for it. The provider’s service also sits inside the contractor’s assessment scope. A cloud MFA or identity service that holds passwords, configuration or logs for the in-scope environment handles Security Protection Data. That makes it an External Service Provider (ESP). An MSP that configures MFA is also an ESP within the contractor’s scope. Per the DoW CIO CMMC FAQ, ESPs “do not require their own CMMC certification.” The requirement is MET when the evidence shows the provider implements the objectives it owns.

FedRAMP applies only when the provider holds CUI. Take a cloud provider that holds Security Protection Data but no CUI. Under 32 CFR 170.19 Table 4, its services “shall be assessed as Security Protection Assets.” The Scoping Guide adds that such a provider is “not required to meet FedRAMP requirements in DFARS clause 252.204-7012.” A cloud provider that stores, processes or transmits covered defense information must meet requirements equivalent to the FedRAMP Moderate baseline under DFARS 252.204-7012. Hosted VPN services and cloud-based security solutions appear among the Security Protection Asset examples in the CMMC Scoping Guide. For how these assets fit the boundary, see CUI boundary scoping.

32 CFR 170.19 requires the ESP relationship to be documented in the contractor’s SSP and in the ESP’s service description and customer responsibility matrix (CRM). The Scoping Guide tells contractors to “Evaluate the ESP’s CRM” for the objectives each party owns. One example split, from Deep Fathom’s view of common arrangements:

A provider’s own remote access into the client environment is a privileged network path. An MSP administrator who signs in without MFA leaves objective [c] NOT MET for the contractor. The CRM decides the actual split. For a template, see the customer responsibility matrix guide.

Where do MFA implementations fail?

Six patterns leave IA.L2-3.5.3 NOT MET. First come administrator console logons without MFA, a cloud or legacy-protocol side door around the VPN, and a logon agent that fails open. The other three are shared administrator accounts, an unfinished rollout, and an SSP that describes a plan instead of the configuration in place. Each maps to an objective. Patterns 1 to 3 appear in practitioner and vendor sources.

1. Local privileged logon left out [b]. MFA covers the VPN and cloud portals, but administrators still sign in at server consoles with a password alone.
2. A side door around the VPN [d]. The VPN has MFA, but a cloud application or a legacy authentication protocol accepts a password alone.
3. An agent that fails open [b]. A logon agent set to admit users when its cloud service is unreachable removes the second factor whenever that service is down.

Pattern 4 is Deep Fathom’s view. Patterns 5 and 6 follow from DoD text.

4. Shared administrator accounts [a], [c]. An account several people use can’t tie a second factor to one person, and the privileged-account list can’t name its owner.
5. An unfinished rollout [a] to [d]. 32 CFR 170.4 and the Assessment Guide say a temporary deficiency “is not based on an ‘in progress’ initial implementation” but “arises after implementation.” The one roll-out exception is a case where “specific issues with a very limited subset of equipment” are found and must be addressed separately.
6. An SSP that describes the plan [a] to [d]. An SSP that describes a planned rollout, not the configuration in place, leaves the requirement NOT MET.

Does the CMMC pause change the MFA requirement?

No. As of September 2026, the Department of War (DoW) has suspended the move to CMMC Phase 2. Contracts may designate only Level 1 (Self) or Level 2 (Self). C3PAO assessments remain available voluntarily. None of that changes the MFA obligation. DFARS 252.204-7012 still applies and still requires NIST SP 800-171 Revision 2, including requirement 3.5.3.

The rule that would move CMMC to NIST SP 800-171 Revision 3 was targeted for July 2026. As of September 2026, it hasn’t been published. In NIST SP 800-171 Revision 3, requirement 03.05.03 reads: “Implement multi-factor authentication for access to privileged and non-privileged accounts.” Its discussion adds, “This requirement applies to user accounts.” That wording drops the local and network split. If DoD adopts Revision 3, a standard user’s local sign-in would come into scope under that text. Until a rule changes it, the Revision 2 text above governs.

Next Step

Deep Fathom organizes the requirement, the SSP, the POA&M and the evidence record. Your Affirming Official affirms in SPRS, and a C3PAO, when engaged, assesses independently.

Send us your access-path inventory: each privileged and standard account type against console, office LAN, VPN, cloud, VDI, mobile and vendor access. Our team will review which of objectives [a] to [d] lack evidence. Within one business day, you’ll get back the gaps to close before your Affirming Official affirms. Send the inventory to our team, or see how Deep Fathom organizes CMMC work.