CMMC Level 2 Controls

CMMC MFA Requirements: What IA.L2-3.5.3 Actually Requires

Q: Does CMMC require MFA for all users?

For network access to in-scope systems, yes for both privileged and non-privileged users. For local access, IA.L2-3.5.3 explicitly requires MFA for privileged accounts, not for every standard local-only desktop login.

Q: Does CMMC require MFA for desktop login?

For a privileged local login, yes. For a standard non-privileged local-only login, not under IA.L2-3.5.3 by itself, but MFA is required once that user accesses an in-scope system over a network.

Q: Does VPN MFA satisfy CMMC?

VPN MFA covers the VPN path but does not automatically cover cloud apps, local admin access, mobile access, RDP/SSH, admin consoles, or vendor tools. Map every access path and check for bypass routes before treating the control as met.

Q: What evidence do assessors need for MFA?

Evidence supporting all four objectives: a privileged-account inventory and proof of MFA enforcement for local privileged, network privileged, and network non-privileged access, including policy exports, sign-in logs, an exception list, and dated enforcement tests.

By The Defense Compliance Report Editorial Team · Last reviewed: July 2026 · Regulatory sources verified: July 3, 2026

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency. This is educational research, not legal, contractual, or compliance advice.

Here’s the short version.

CMMC MFA requirements center on one control — IA.L2-3.5.3 — with two close cousins: MA.L2-3.7.5 (MFA on nonlocal/remote maintenance sessions) and IA.L2-3.5.4 (replay-resistant authentication). They kick in at Level 2, not Level 1. If your contract requires CMMC Level 2 (because your systems process, store, or transmit Controlled Unclassified Information, or CUI), you must use multi-factor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts.

Now the part that costs people contracts: MFA is not a control you can “flip on and check the box.” The requirement is about coverage— every account, every access path — and about evidence an assessor can verify. And unlike most gaps, an MFA gap cannot be parked on a plan-to-fix-later. We’ll show you exactly why below, with the rule text to back it up.

CMMC MFA requirements at a glance

The shortest safe answer: privileged accounts need MFA for both local and network access; non-privileged accounts need MFA for networkaccess. The requirement applies inside your CMMC assessment scope, so the real question isn’t “do we have MFA” — it’s “does MFA cover every in-scope account and access path, and can we prove it.” (Source: NIST SP 800-171 Rev. 2, §3.5.3; DoD CMMC Assessment Guide — Level 2, objectives 3.5.3[a]–[d].)

Access path	Privileged account (admin)	Non-privileged account (standard user)
Local access (direct console login, no network)	MFA required	Not required by 3.5.3 alone
Network access (VPN, RDP, SSH, cloud apps, email, VDI, remote)	MFA required	MFA required
Mobile device reaching a CUI app or email	MFA required (if in scope)	MFA required (if in scope)
Nonlocal maintenance (vendor over the internet)	MFA required — see MA.L2-3.7.5	Usually a vendor/maintenance case

That table resolves the main confusion. The rest of this page handles the edge cases that actually send people back to the search bar: standard-user desktop logins, VPN-only setups, Microsoft 365 and GCC High, whether SMS counts, whether MFA has to be FIPS-validated, what an assessor wants to see, and how MFA affects your score.

Not sure which row you land in? Run the free CMMC MFA Scope Checkerbelow — a few non-sensitive questions and you’ll see which access paths still need MFA and evidence. Do not enter CUI, drawings, or sensitive contract details. ↓ Jump to the Scope Checker

Yes, ifyou handle (or expect to handle) CUI, you’re headed for CMMC Level 2, and you need to know precisely where MFA attaches and what proves it.

Probably not, ifyour contract is FCI-only Level 1 — MFA (IA.L2-3.5.3) isn’t in your requirement set; see our CMMC levels overview instead. Either way, the contract clause sets your level — a checklist doesn’t.

The one honest catch about CMMC and MFA

Answer capsule: MFA is one of the two or three easiest CMMC controls to turn on— and one of the easiest to fail an assessment on. The failure is almost never “we don’t have MFA.” It’s a coverage gap (a VPN covered, but not local admin login), a bypass route (cloud email reachable without MFA), a shared admin account, or evidence that proves enrollment but not enforcement.

Turning on MFA in Microsoft 365 can be a twenty-minute task. That’s the trap. CMMC does not ask whether you have MFA. It asks whether MFA covers everyrequired account and access path, uses factors that hold up, and is documented so an assessor can trace policy to proof. The distance between “we have MFA” and “we pass IA.L2-3.5.3” is exactly where contractors lose certifications.

Here’s the good news: this gap is completely knowable and completely fixable. The rule defines the required categories. The DoD assessment guide defines the objectives and assessment methods. And the matrix further down this page maps those requirements to the real access paths and the evidence you actually have to produce.

The right CMMC provider depends on your actual gap. Use The Defense Compliance Report’s Find My CMMC Path tool to map your situation to the right provider category (RPO, MSSP, GRC platform, or CUI enclave) before you spend anything. The contract clause sets your level, not a checklist.

Find My CMMC Path →

Do not submit CUI, drawings, or sensitive contract details. Provider matching may generate referral or partner compensation, disclosed at the point of recommendation; it never changes our regulatory analysis.

CMMC MFA Scope Checker

Answer capsule: To gauge whether your MFA satisfies IA.L2-3.5.3, check enforcement across every account type and access path in your CUI scope — privileged local, privileged network, and non-privileged network — plus service accounts, mobile access, and any legacy-auth bypass. If any covered path can be reached without MFA, that’s a gap. (Source: DoD CMMC Assessment Guide — Level 2, objectives 3.5.3[a]–[d].)

Answer these six questions for the systems in your CMMC scope. Each maps to a piece of the requirement. This is a self-check — do not enter CUI, drawings, or contract details.

Privileged / local (Objective 3.5.3[b])

Do all admin (privileged) accounts require MFA at the local console, not just over the network?

Privileged / network (Objective 3.5.3[c])

Do all admin accounts require MFA for every network path — VPN, RDP, SSH, cloud admin portals?

Standard / network (Objective 3.5.3[d])

Do all standard (non-privileged) users require MFA for network access to in-scope systems, including cloud email?

Service & break-glass accounts (Objective 3.5.3[a])

Have you inventoried privileged service accounts and break-glass accounts, and documented how each is handled?

Mobile (Objective DoD Level 2 guide)

If any mobile device reaches a CUI app or email, is MFA enforced on that path?

Bypass routes (Objective All objectives)

Have you confirmed there's no legacy-auth protocol (basic auth, older IMAP/SMTP) or side door that reaches CUI without MFA?

How to read your result.Every “yes” is a covered path with an evidence obligation. Any “no” is a gap — and because MFA carries a 3-to-5-point weight in the CMMC scoring methodology, a gap here isn’t a minor deduction. A “not sure” is functionally a “no” until you can show the configuration and the logs.

Turn your answers into a decision.If you hit a “no” or a “not sure,” the fix depends on the gap — scoping, enforcement, evidence, or assessment readiness. Tell us your level, scope, and timeline and we’ll match you to the right provider category.

Find My CMMC Path →

No CUI — just your level, scope, and timeline.

What are the CMMC MFA requirements? (IA.L2-3.5.3, in plain English)

Answer capsule: CMMC Level 2 uses the 110 security requirements in NIST SP 800-171 Revision 2, and the MFA requirement is IA.L2-3.5.3. It requires multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. During a Level 2 assessment, four objectives are tested: privileged accounts are identified, and MFA is implemented for local privileged access, network privileged access, and network non-privileged access. (Source: NIST SP 800-171 Rev. 2 §3.5.3; DoD CMMC Assessment Guide — Level 2.)

The control text itself is short. Straight from NIST SP 800-171 Rev. 2, requirement 3.5.3 reads:

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

CMMC restates this word-for-word as practice IA.L2-3.5.3, inside the Identification and Authentication (IA) family — one of the 14 control familiesthat make up Level 2. And this isn’t new. Contractors handling CUI have owed this requirement for years through DFARS clause 252.204-7012(Safeguarding Covered Defense Information), which points to NIST SP 800-171. CMMC’s contribution is verification — proving you’ve actually done it.

The four assessment objectives (this is what an assessor checks)

When a C3PAO or a self-assessor evaluates 3.5.3, they test four separate determination statements from the DoD Level 2 Assessment Guide. Each one becomes an evidence obligation:

Objective	What it means in practice	What proves it
3.5.3[a]	Privileged accounts are identified	A current inventory of admin / privileged / service accounts
3.5.3[b]	MFA for local privileged access	MFA enforced at the console for admin logins; test evidence
3.5.3[c]	MFA for network privileged access	MFA on admin portals, VPN, RDP, SSH, cloud consoles; logs
3.5.3[d]	MFA for network non-privileged access	MFA enforced for standard users on in-scope network access; logs

Notice what’s noton that list: MFA for a standard user’s local-only login. That single omission is the source of half the “does every desktop need MFA” debate — and we untangle it two sections down.

What actually counts as “multi-factor”

Answer capsule: For 3.5.3, MFA means authentication using two or more different factor categories: something you know (password/PIN), something you have (an authenticator app code, a security key, a smart card), or something you are (a biometric). Two passwords, or a password plus a security question, are the same factor twice and do not qualify. NIST also states this requirement should not be read as requiring a PIV/CAC-style solution. (Source: NIST SP 800-171 Rev. 2 §3.5.3.)

A company-owned laptop is not a “second factor.” It’s technically “something you have,” but it isn’t bound to a specific user, so it doesn’t authenticate the individual. Same logic kills “we only allow logins from our office IP” — a source IP address isn’t a factor.
You do not need government smart cards.NIST explicitly says 3.5.3 shouldn’t be interpreted as requiring PIV/CAC-like solutions. An authenticator app or a security key is fine.

“Local,” “network,” and “remote” — the definitions that decide everything

Local access: a direct connection to the system with no network in between — think logging in at the physical console.
Network access: access over any network — LAN, WAN, the internet, VPN, RDP, SSH, a cloud app, a VDI session.
Remote access: a type of network access that crosses an external network (working from home over VPN, for example).

The practical translation: admins need MFA everywhere (console, on-prem network, and remote), and every user needs MFA for any network loginto an in-scope system. Because remote access is a subset of network access, remote logins always fall in the “network” column.

Who actually needs MFA under IA.L2-3.5.3? (the access-path matrix)

Answer capsule: Under IA.L2-3.5.3, privileged users need MFA for local and network access, and non-privileged users need MFA for network access. The expensive mistakes happen when teams apply that one sentence without mapping real access paths — VPN, cloud email, mobile, admin consoles, local admin login, RDP/SSH, VDI, and vendor tools each raise a separate MFA and evidence question. (Source: NIST SP 800-171 Rev. 2 §3.5.3; DoD CMMC Assessment Guide — Level 2.)

The CMMC MFA Access-Path Evidence Matrix

Access situation	Account type	MFA required?	Source basis	Evidence to collect	Common failure
Local/console login to a server or workstation with admin rights	Privileged	Yes	3.5.3[b]	Local MFA config, admin group export, dated login test	MFA only on VPN, not on local admin login
RDP / SSH / admin portal / cloud console / VPN admin access	Privileged	Yes	3.5.3[c]	Conditional Access or VPN MFA policy, sign-in logs, privileged account list	A break-glass or service account left exempt
VPN or remote access into the CUI environment	Non-privileged	Yes	3.5.3[d]	VPN MFA policy, MFA logs, user-group export, test evidence	"MFA is for admins only"
Microsoft 365 / GCC High / cloud email that holds or reaches CUI	Any	Yes, if that app/path is in scope	DoD Level 2 guide: cloud email requires MFA	Tenant policy export, Conditional Access rules, sign-in logs	Assuming the cloud platform "handles MFA" for you
Standard desktop login, local only, no CUI or network access at login	Non-privileged	Not required by 3.5.3 specifically	3.5.3 covers non-privileged network access, not local-only	Scope rationale; MFA evidence on the later network access	Treating every desktop login as automatically required
Mobile device reaching a CUI app or email	Any applicable user	Yes	DoD Level 2 guide: mobile access to a CUI system/app	MDM/IdP policy, device compliance, sign-in logs	Mobile email quietly bypassing MFA
Nonlocal (remote) maintenance session	Vendor / maintenance	Yes — plus MA.L2-3.7.5 applies	3.5.3 + Maintenance control 3.7.5	Vendor access policy, maintenance records, MFA logs	A vendor's remote tool bypassing your identity provider
Legacy or COTS app with no native MFA	Any applicable user	The requirement still stands for covered paths	3.5.3 is technology-neutral	Access proxy / VDI / PAM / app-gateway evidence, architecture notes	"The app can't do MFA" treated as a valid answer
Shared or generic admin account	Privileged	An MFA problem and an identity problem	3.5.3[a] requires identifying privileged accounts	Named-account inventory, plan to eliminate shared logins	MFA bolted onto a shared account with no individual accountability
Asset that is genuinely out of scope (no CUI, no security role)	Any	Not assessed for 3.5.3	CMMC applies by assessment scope	Scope diagram, asset inventory, data-flow rationale	Leaving an undocumented CUI path in that out-of-scope zone

This matrix separates implementation (“is MFA on?”) from evidence (“can you prove it?”), and flags the common failure for each row so you can self-audit before an assessor does it for you.

You have MFA — but does it cover every row above? Before you buy another tool, map your coverage. Use Find My CMMC Path to identify whether your gap is scoping, implementation, evidence, or assessment readiness. It routes you to a provider category, not a sales pitch.

Does CMMC require MFA for every desktop login?

Answer capsule: No — not for every standard, local-only desktop login. IA.L2-3.5.3 requires MFA for local access to privileged accounts, and for network access by any user. So a non-privileged user logging in at a local console that grants no network access to CUI is not, by 3.5.3 alone, an MFA trigger. The moment that login reaches CUI over a network, MFA applies. (Source: NIST SP 800-171 Rev. 2 §3.5.3.)

Standard user, truly local-only login: Not required by 3.5.3. If the account is non-privileged and the login opens no network path to CUI, the control doesn't compel MFA on that console login.
Local admin login: Required. Privileged local access is explicitly covered by objective 3.5.3[b]. Admins logging in at the console need MFA.
The 'domino' desktop login: This is where most people are actually wrong. A standard desktop login looks local, but if it auto-mounts network drives, launches a cloud sync client, opens a VDI session, uses cached domain credentials over an always-on VPN, or otherwise reaches CUI across a network — you're now in network-access territory, and MFA applies to that path.

The accurate rule of thumb: don’t ask “is this a desktop login?” Ask “does this login give the user network access to in-scope systems?” If yes, MFA. If it’s genuinely local-only and non-privileged, 3.5.3 doesn’t force it — but document whyit’s out of that path in your scope rationale, because an assessor will ask.

Does VPN MFA satisfy CMMC MFA requirements?

Answer capsule: VPN MFA can satisfy one required network-access path, but it does not automatically satisfy all of IA.L2-3.5.3. If users can reach CUI through cloud email, Microsoft 365, VDI, direct RDP/SSH, admin consoles, or mobile apps outsidethe VPN — or if admins log in locally — VPN-only MFA leaves a gap an assessor will find. (Source: NIST SP 800-171 Rev. 2 §3.5.3; DoD CMMC Assessment Guide — Level 2.)

VPN MFA genuinely helps when the VPN is the onlydoor into your CUI network, it’s the enforced access-control point, your logs show MFA was required and used, and there are no side doors. The problem is that in most modern environments, the VPN is not the only door. Here are the bypass patterns that turn “we have VPN MFA” into a finding:

Bypass pattern	Why it breaks 3.5.3 coverage
Cloud email / collaboration reachable directly (not through the VPN)	The DoD Level 2 guide uses cloud email as an explicit MFA example — that path needs MFA on its own
Admin console or cloud portal reachable outside the VPN	Network privileged access (3.5.3[c]) still requires MFA
Local/console admin login	VPN never touches local access — 3.5.3[b] still applies
Mobile email or app access to CUI	The DoD guide calls out mobile access to CUI systems/apps
Split-tunnel or direct app access	The VPN isn't the only network path anymore
Vendor remote-support tool	Nonlocal maintenance — MFA plus MA.L2-3.7.5

If the VPN is your main enforcement point, your evidence packet needs to prove more than “the VPN has MFA.” It needs the VPN MFA policy, user/group assignment, admin-vs-standard coverage, sign-in logs, a dated enforcement test, and — critically — a documented review of bypass routes showing there’s no unauthenticated path to CUI.

↑ Run the CMMC MFA Scope Checker to see which access paths still need evidence.

What about Microsoft 365, GCC High, and Azure Government?

Answer capsule: CMMC assesses your configuration and evidence, not the cloud label. If users reach CUI through Microsoft 365, GCC High, or Azure Government, MFA must be enforced for that network-access path, and your SSP must show what the platform provides versus what you configure and prove. The DoD Level 2 Assessment Guide uses cloud-based email as an MFA example. (Source: DoD CMMC Assessment Guide — Level 2.)

Two myths worth killing here:

“GCC High covers MFA.” GCC High can support a compliant architecture, but MFA is your tenant-side responsibility. You still configure enforcement, assign it to the right users and admins, handle break-glass accounts, and produce the evidence.
“MFA is enabled, so we’re done.”Enabled is not enforced. Assessors look for MFA applied consistently across your user population and — a frequent silent failure — legacy authentication protocols (basic auth, older IMAP/SMTP) that quietly skip MFA entirely.

The cloud label suggests…	…but you still have to configure and prove
"MFA is available in the tenant"	Conditional Access (or equivalent) policy that actually enforces MFA, exported as evidence
"All users are covered"	Explicit user/group assignment showing every in-scope user is in scope of the policy
"Admins are protected"	Separate handling for privileged roles and break-glass accounts, documented
"It's a secure cloud"	Legacy authentication blocked so it can't bypass MFA on the way to CUI
"The platform logs everything"	Sign-in logs retained and retrievable to show MFA firing on real logins
"It's compliant"	An SSP narrative plus, if a provider runs the tenant, an ESP relationship and Customer Responsibility Matrix (CRM)

Treat vendor documentation as implementation help, not as the controlling authority; the authority is 32 CFR Part 170 and NIST SP 800-171 Rev. 2. Under DFARS 252.204-7012, a cloud service that stores, processes, or transmits CUI is expected to meet security requirements equivalent to the FedRAMP Moderate baseline — a reason to choose CUI-capable environments deliberately. For the platform-level detail, see our GCC High and CMMC guide.

What counts as acceptable MFA — and does SMS pass?

Answer capsule: Any method using two different factor categories satisfies the definition in 3.5.3; NIST does not require a PIV/CAC-style solution. SMS-delivered codes technically meet the two-factor definition, so 3.5.3 doesn’t ban them outright — but SMS is weak, and NIST’s current digital-identity guidance (SP 800-63B-4, finalized July 2025) classifies SMS/PSTN one-time passcodes as a restricted authenticator. For CUI, stronger methods are the safer choice. (Sources: NIST SP 800-171 Rev. 2 §3.5.3 and §3.5.4; NIST SP 800-63B-4.)

There’s a separate but related control in play here: IA.L2-3.5.4 requires replay-resistant authentication for network access. That’s the technical reason to favor app-based, hardware, or smart-card methods over plain SMS. Here’s our read on the common methods — the first two columns are grounded in the control text and NIST guidance; the verdict column is editorial judgment based on the requirement plus how assessors actually behave:

Method	Counts as MFA (3.5.3)?	Replay / phishing & assessor scrutiny	Practical verdict
Password + authenticator app code (Microsoft/Google Authenticator, TOTP)	Yes	One-time codes resist replay when the verifier accepts each once; not phishing-resistant	Widely accepted, low cost
Password + push approval (Entra / Duo push)	Yes	Stronger with number-matching; simple approve/deny is weaker (prompt-bombing)	Widely accepted; use number-matching for admins
FIDO2 security key (e.g., YubiKey)	Yes	Phishing-resistant	Strongest; preferred for privileged access
PIV / CAC smart card	Yes	Strong, cryptographic	Strong; not required by 3.5.3
Password + SMS or voice code	Yes (technically)	SMS/PSTN is a restricted authenticator under NIST SP 800-63B-4; interceptable (SIM-swap, porting)	Allowed but disfavored — don't build a new CUI program on it
Two passwords / password + security question	No — one factor twice	—	Fails 3.5.3
Company laptop alone / office IP as second factor	No — not bound to the user	—	Fails 3.5.3

Phishing-resistant MFA(like FIDO2) is a stronger tier than what IA.L2-3.5.3 strictly requires. It’s a smart choice, especially for admins, but the CMMC control doesn’t mandate it across the board. If you’re standing up MFA today for a CUI environment, don’t build on SMS.

Does CMMC MFA have to be FIPS-validated?

Answer capsule: Not under IA.L2-3.5.3. The MFA control requires multi-factor authentication; it does not require the MFA product’s cryptography to be FIPS-validated. FIPS-validated cryptography is a separaterequirement — SC.L2-3.13.11 — that applies when cryptography is used to protect the confidentiality of CUI. The blanket claim “CMMC MFA must be FIPS-validated” overstates 3.5.3. (Sources: NIST SP 800-171 Rev. 2 §3.5.3 and §3.13.11; DFARS 252.204-7012.)

Two different controls, two different jobs:

IA.L2-3.5.3 = use MFA for the covered account/access paths. Nothing in its text conditions compliance on FIPS-validated authentication crypto.
SC.L2-3.13.11 = use FIPS-validated cryptography when cryptography protects the confidentiality of CUI.

Where do they touch? If your authentication mechanism’s cryptography is itself protecting CUI confidentiality, FIPS validation gets pulled in through 3.13.11, not through the MFA control. The net: “our MFA isn’t FIPS-validated” is not, on its own, a 3.5.3 failure. If you’re unsure how 3.13.11 applies to your specific stack, that’s a precise scoping question worth putting to a Registered Practitioner.

Can you defer MFA? SPRS scoring and the POA&M rule

Answer capsule: No — you cannot defer MFA. In the CMMC scoring methodology, missing MFA subtracts 5 points and partial MFA subtracts 3 points; 3.5.3 is one of only two requirements with built-in partial scoring. And under 32 CFR 170.21, only requirements worth 1 point may go on a POA&M, so a 3-or-5-point control like MFA must be fully implemented at the time of assessment. An MFA gap is a disqualifying finding, not a fix-it-later item. (Sources: 32 CFR §170.21 and §170.24; DoD NIST SP 800-171 Assessment Methodology.)

Part one — the score.

CMMC Level 2 scoring starts at 110 and subtracts a weighted value (1, 3, or 5 points) for each unmet requirement. MFA is a heavyweight, and it’s unusual: it has built-in partial scoring. MFA (3.5.3) is one of only two requirements scored this way (the other is 3.13.11, FIPS cryptography):

Your MFA state	Score impact (from 110)
Fully implemented for all required accounts and access paths	0 deducted
Implemented only for remote access and privileged users (not general non-privileged network users)	−3
Not implemented for any users	−5

Part two — and this is the kicker — you can’t POA&M it.

A POA&M is the short list of “NOT MET” items you’re allowed to fix after the assessment to earn a Conditional status. But per 32 CFR 170.21(a)(2), only requirements with a point value of 1may be placed on a POA&M — with a single, specific exception for FIPS encryption (SC.L2-3.13.11) at 3 points. MFA is worth 3 or 5 points. It is not the encryption exception. Therefore MFA cannot go on a POA&M at all.If MFA is a gap when the assessor arrives, it’s not a documented plan — it’s a failed control that blocks even Conditional Level 2 status.

To earn Conditional Level 2 you need a score of at least 88 out of 110 (the 80% threshold in 32 CFR 170.21), andevery 3-point and 5-point control has to be met regardless of your total. MFA fails you on both counts if it’s missing. “We’ll put MFA on the POA&M and fix it in the 180-day window” is not a plan that exists under the rule.

There’s a compliance-lifecycle angle too. CMMC requires an annual affirmation of continuous compliance posted in SPRS(the Supplier Performance Risk System). “Temporary” MFA that quietly lapses after the assessment isn’t just risky — it’s a false-affirmation exposure.

If MFA is your make-or-break gap, the next move is figuring out who closes it.Tell us your level, scope, and timeline and we’ll point you to the right provider category — readiness, managed services, enclave, or GRC. Don’t submit CUI.

Find My CMMC Path →

How do MFA requirements change by CMMC level and assessment type?

Answer capsule: Level 1 does not include IA.L2-3.5.3; Level 2 does; Level 3 builds on Level 2. The assessment type (self-assessment vs. C3PAO vs. DIBCAC) changes how the result is verified and reported, but it does not change the text of the MFA requirement for an in-scope Level 2 environment. (Sources: 32 CFR §170.14; NIST SP 800-171 Rev. 2; NIST SP 800-172.)

CMMC status	Data	Requirement set	MFA (3.5.3)?	Who assesses
Level 1 (Self)	FCI only	15 safeguards, FAR 52.204-21	No	Annual self-assessment
Level 2 (Self)	CUI (lower-risk subset)	110 requirements, NIST SP 800-171 Rev. 2	Yes	Triennial self-assessment
Level 2 (C3PAO)	CUI	Same 110 requirements	Yes	Independent C3PAO certification
Level 3 (DIBCAC)	Most sensitive CUI	The 110 plus 24 selected NIST SP 800-172 (Feb 2021) requirements	Yes (built on Level 2)	DCMA DIBCAC

CMMC Level 2 is pinned to NIST SP 800-171 Revision 2, not Revision 3. Revision 3 exists (published May 2024) and changes the MFA language, but it does not control CMMC assessments today. Plan against Rev. 2.
Level 3 is a vertical step, not a lateral one. Under 32 CFR Part 170, Level 3 adds 24 enhanced requirements from NIST SP 800-172 (Feb 2021) on top of the full Level 2 baseline, is assessed by DCMA DIBCAC, and requires Final Level 2 (C3PAO) status on the same scope first.
The contract clause sets your level, not your checklist. The solicitation's notice provision (DFARS 252.204-7025) states the required level. Don't self-assign.
Flow-down is real. CMMC requirements flow from primes to subcontractors wherever FCI or CUI is processed, stored, or transmitted in performance of the contract.

Why this matters now: Phase 1 runs November 10, 2025 through November 9, 2026 and focuses primarily on Level 1 and Level 2 self-assessments; Phase 2 begins November 10, 2026, when Level 2 certification (C3PAO) requirements expand. If Level 2 is in your future, MFA is not a “later” problem — it’s a fix-before-your-assessment problem, and C3PAO capacity tightens as the deadlines approach.

A quick note on clause numbers.As of February 1, 2026, a DoD class deviation under the “Revolutionary FAR Overhaul” renumbered several cyber clauses: FAR 52.204-21 became FAR 52.240-93, DFARS 252.204-7019 was eliminated, and DFARS 252.204-7020 moved to DFARS 252.240-7997. The CMMC clauses (252.204-7021 and 252.204-7025) and the safeguarding clause (252.204-7012) did not change, and the MFA requirement did not change.During the transition you may see both old and new numbers — always verify the exact clause text in your own solicitation.

What evidence proves MFA is implemented?

Answer capsule: A policy that says “we use MFA” is not enough. Your evidence must prove the four assessment objectives: privileged accounts are identified, and MFA is implemented for local privileged access, network privileged access, and network non-privileged access. Assessors verify through examine, interview, and test — so you need configuration exports, logs, inventories, and a working demonstration. (Source: DoD CMMC Assessment Guide — Level 2, objectives 3.5.3[a]–[d].)

Map your evidence to the objectives, not to a generic “MFA folder.” This table is your build list:

Objective	Strong evidence	Weak evidence that fails
3.5.3[a] privileged accounts identified	Admin group export, PAM/IAM report, privileged role list, dated account review	"We know who our admins are," with nothing exported
3.5.3[b] local privileged MFA	Local/console MFA configuration, privileged login test with screenshots and date	A VPN screenshot standing in for local access
3.5.3[c] network privileged MFA	Conditional Access on admin portals, VPN/RDP/SSH MFA logs, privileged sign-in report	Admins exempted "for convenience"
3.5.3[d] network non-privileged MFA	User-group MFA policy, cloud/VPN sign-in logs, enforcement test	MFA enabled but not enforced for all in-scope users

Because assessors work in three modes, prepare for all three:

Examine: policies, settings, logs, screenshots, inventories.
Interview: be able to explain who's covered, who's exempt, and why.
Test: demonstrate the MFA prompt actually firing on a representative access path.

A practical MFA evidence packet looks like this: (1) an MFA control narrative for the SSP; (2) an access-path map; (3) a privileged-account inventory; (4) non-privileged user-group mapping; (5) MFA policy exports; (6) sign-in logs; (7) an exception list; (8) break-glass account handling; (9) mobile and cloud access evidence; (10) dated test screenshots. If you can hand an assessor those ten items and they line up with what’s actually configured, MFA is rarely where you’ll struggle.

Want the packet without building it from scratch? The CMMC Readiness Checklist covers the ten artifacts above, mapped to objectives 3.5.3[a]–[d], with a short SSP-language starter for each. It’s free, and it’s yours whether or not you ever talk to us.

Download the CMMC Readiness Checklist →

What type of provider do you need if you have an MFA gap?

Answer capsule: The right provider category depends on the actual gap. A scoping or interpretation problem points to an RPO/RP; an enforcement or logging problem points to an MSSP or CMMC-focused MSP; a proof-and-workflow problem points to a GRC platform as a supporting layer; a legacy-app or CUI-boundary problem points to a CUI enclave strategy; and a C3PAO is for the assessmentwhen you’re ready — not for implementing the same environment it will assess.

Under 32 CFR §170.9, C3PAOs must manage impartiality and conflicts of interest and comply with ISO/IEC 17020:2012and the CMMC Code of Professional Conduct — and the three-year consultant bar at 32 CFR §170.8(b)(17) means a firm that provided CMMC consulting or remediation to your organization generally cannot serve on the team that assesses you. If a provider offers to both fix and certify the same environment, treat it as a red flag, not a convenience.

Your MFA problem	Likely provider category	Why
“We don't know whether this system is even in scope.”	RPO / RP (Registered Provider Organization / Registered Practitioner)	Scope and applicability come first
“We know MFA is required but can't enforce it everywhere.”	MSSP (Managed Security Service Provider) or CMMC-focused MSP	Identity, endpoint, VPN, and logging implementation
“We have MFA but no evidence packet.”	GRC platform or documentation support	Evidence organization and SSP mapping — a supporting layer, not the whole solution
“A legacy app can't do MFA.”	CUI enclave / access broker / MSSP	Architecture and scope reduction
“We're ready for the formal assessment.”	C3PAO	Certification assessment — kept separate from remediation

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

Still deciding whether this is a readiness, managed-services, enclave, GRC, or assessment problem? Our CMMC provider-category guide breaks down what each type does, and our CMMC cost guide sets expectations before you request quotes.

And here’s the disqualifier: if MFA is already enforced across every path — cloud, VPN, on-prem admin, mobile, service accounts — and documented in your SSP, you don’t need a provider for this. You’re ready. If you’re notsure whether that’s true, that uncertainty is the gap, and it’s worth ten minutes to resolve.

Ready to match the gap to the right kind of help?Use The Defense Compliance Report’s Find My CMMC Path tool to compare provider categories before you request quotes. It’s not a score, a ranking, or legal advice — it routes you to the category that fits your level, scope, and timeline.

Find My CMMC Path →

A clean CMMC MFA implementation sequence

Answer capsule: The safe order is scope first, tool second. Confirm your level and CUI scope, identify privileged accounts, map every access path, enforce MFA at each required point, eliminate bypasses, collect evidence, update the SSP, then rehearse the assessment. Doing it in this order prevents the coverage gaps that cause findings.

1Confirm level and scope. Tie it to your contract clause and your FCI/CUI handling. (Sets what's in scope.) See our CMMC scoping guide.
2Identify privileged accounts. Domain admins, cloud admins, local admins, service accounts, break-glass accounts — all of them. (Serves objective 3.5.3[a].)
3Map access paths. Local, network, remote, VPN, cloud, VDI, mobile, vendor maintenance. (Feeds 3.5.3[b], [c], [d] and MA.L2-3.7.5.)
4Enforce MFA at every required point. Identity provider, VPN, PAM, endpoint/local MFA, cloud Conditional Access, VDI gateway, app proxy for legacy systems. Use replay-resistant factors per IA.L2-3.5.4. (Serves 3.5.3[b], [c], [d].)
5Eliminate bypasses. No direct cloud path without MFA, no exempted admins, no unmanaged mobile email, no vendor tool skipping your IdP, no break-glass account without documented handling. (Protects all objectives.)
6Collect evidence. Policy exports, logs, screenshots, test records, exception list, account inventory. (Proves 3.5.3[a]–[d].)
7Update the SSP. The control narrative must match what's actually configured — assessors compare the two.
8Rehearse examine / interview / test. Make sure the person doing the work can explain and demonstrate it live.

Common CMMC MFA failures that trigger findings

Answer capsule: Most MFA findings aren’t caused by a missing product. They come from incomplete coverage, bypass routes, shared privileged accounts, weak exception handling, undocumented mobile or cloud access, or evidence that proves enrollment but not enforcement.

Failure	Why it matters	The fix
MFA on VPN only	Misses local admin access and direct cloud paths	Map all access paths first
Admin-only MFA	Non-privileged network access is also covered	Enforce user network MFA
Optional enrollment	Enrollment is not enforcement	Require MFA by policy
Unmanaged break-glass accounts	Exemptions become bypasses	Document, monitor, restrict, and test them
Shared admin accounts	MFA can't prove individual accountability	Move to named privileged accounts
Legacy app with no MFA	The requirement doesn't disappear	Proxy, VDI, PAM, enclave, or re-architect
Mobile access ignored	The DoD guide calls out mobile access to CUI apps	Enforce through your IdP/MDM
No logs or screenshots	Policy alone doesn't prove operation	Build the evidence packet
"The cloud handles it"	Shared responsibility still applies	Document tenant-side controls and the CRM

What we actually verified for this page

We take primary-source citation seriously, so here’s exactly what we checked and when. For this article we read:

NIST SP 800-171 Rev. 2, §3.5.3 (MFA), §3.5.4 (replay-resistant authentication), §3.7.5 (nonlocal maintenance MFA), and §3.13.11 (FIPS-validated cryptography) — verified against NIST's published PDF on July 3, 2026.
The DoD CMMC Assessment Guide — Level 2, for the four assessment objectives 3.5.3[a]–[d] and the mobile-device and cloud-email examples — verified July 3, 2026.
The DoD NIST SP 800-171 Assessment Methodology and 32 CFR §170.24 (CMMC Scoring Methodology), for the −5 / −3 weighting and MFA's built-in partial scoring — verified July 3, 2026.
32 CFR §170.21 (POA&M requirements), confirming that only 1-point requirements are POA&M-eligible (with the single SC.L2-3.13.11 encryption exception), which is why MFA cannot be deferred — verified July 3, 2026.
32 CFR §170.14 (level requirements) and 32 CFR Part 170 definitions, confirming Level 1 aligns to FAR 52.204-21, Level 2 uses the 110 Rev. 2 requirements, and Level 3 adds the 24 selected NIST SP 800-172 (Feb 2021) requirements — verified July 3, 2026.
32 CFR §170.9 and §170.8(b)(17) plus ISO/IEC 17020:2012, for the C3PAO impartiality and three-year consultant rules — verified July 3, 2026.
The February 1, 2026 Revolutionary FAR Overhaul class deviation, confirming the clause renumbering while the CMMC clauses (252.204-7021 / 7025) and 252.204-7012 — and the MFA requirement itself — remained unchanged — verified July 3, 2026.
NIST SP 800-63B-4 (finalized July 2025), for the 'restricted authenticator' status of SMS/PSTN — cited as best-practice context, not as a CMMC mandate.

What we did not treat as authority: competitor articles (used only to understand the search landscape), Microsoft’s documentation (used as implementation guidance, not controlling authority), and Reddit or forum threads (used only to capture how contractors describe their confusion). None of those set a requirement.

How we built the MFA Access-Path Evidence Matrix

We started with the controlling requirement (NIST SP 800-171 Rev. 2 §3.5.3 and the DoD Level 2 assessment objectives). We split it into the five variables that actually decide any real-world answer: CMMC level, account privilege, access type, assessment scope, and evidence. Then we mapped the scenarios contractors ask about — desktop login, VPN, cloud email, mobile, local admin, RDP/SSH, VDI, vendor maintenance, legacy apps, shared accounts — to those variables, and for each row we recorded what the source says, what proof to collect, and the failure we see most often. Every “required / not required” call traces back to the control text or an assessment objective.

Frequently asked questions: CMMC MFA requirements

Is MFA required for CMMC Level 2?

Yes. CMMC Level 2 uses the 110 requirements in NIST SP 800-171 Rev. 2, and IA.L2-3.5.3 requires MFA for local and network access to privileged accounts and network access to non-privileged accounts. (Source: 32 CFR Part 170; NIST SP 800-171 Rev. 2 §3.5.3.)

Does CMMC require MFA for all users?

For network access to in-scope systems, yes — both privileged and non-privileged users are covered. For local access, IA.L2-3.5.3 explicitly requires MFA for privileged accounts, not for every standard local-only desktop login. (Source: NIST SP 800-171 Rev. 2 §3.5.3.)

Does CMMC require MFA for desktop login?

For a privileged (admin) local login, yes. For a standard non-privileged local-only login, not under IA.L2-3.5.3 by itself — but MFA is required the moment that user accesses an in-scope system over a network, which most desktop logins ultimately do. (Source: NIST SP 800-171 Rev. 2 §3.5.3.)

Does VPN MFA satisfy CMMC?

VPN MFA covers the VPN path, but it does not automatically cover cloud apps, local admin access, mobile access, direct RDP/SSH, admin consoles, or vendor tools. Map every access path and check for bypass routes before treating the control as met. (Source: NIST SP 800-171 Rev. 2 §3.5.3; DoD CMMC Assessment Guide — Level 2.)

Does Microsoft 365 or GCC High MFA count for CMMC?

It can, if it's configured, enforced across all required users and admins, evidenced with logs and screenshots, and documented in your SSP. The platform label alone does not prove the control is implemented. (Source: DoD CMMC Assessment Guide — Level 2.)

Does CMMC MFA have to be FIPS-validated?

Not under IA.L2-3.5.3. FIPS-validated cryptography is a separate requirement — SC.L2-3.13.11 — that applies when cryptography protects the confidentiality of CUI. (Source: NIST SP 800-171 Rev. 2 §3.5.3 and §3.13.11.)

Does SMS satisfy CMMC MFA?

SMS is technically a second factor, so IA.L2-3.5.3 does not outright ban it — but it's weak against interception, and NIST SP 800-63B-4 (finalized July 2025) classifies SMS/PSTN codes as a restricted authenticator. Use authenticator apps, security keys, or smart cards for CUI. (Source: NIST SP 800-171 Rev. 2 §3.5.4; NIST SP 800-63B-4.)

Do service accounts and shared admin accounts need MFA?

Privileged accounts are in scope, including service accounts with elevated rights. Do not treat 'MFA isn't technically feasible' as an automatic pass: inventory the account, restrict and monitor it, and document it in the SSP. Under DFARS 252.204-7012, an alternative counts as an approved 'equally effective' measure only when adjudicated by the DoD CIO — not by self-declaration. Shared admin accounts also raise an accountability problem under objective 3.5.3[a]; move to named accounts.

Does vendor remote maintenance need MFA?

Yes. Beyond IA.L2-3.5.3, nonlocal maintenance has its own control — MA.L2-3.7.5 — requiring MFA to establish remote maintenance sessions over external networks and to terminate them when complete. Treat vendor tools as access paths, not exceptions. (Source: NIST SP 800-171 Rev. 2 §3.7.5.)

Can MFA be on a POA&M for CMMC?

No. Under 32 CFR 170.21, only requirements worth 1 point are POA&M-eligible (with a single exception for FIPS encryption). MFA is worth 3 or 5 points, so it must be fully implemented at the time of assessment — an MFA gap blocks even Conditional Level 2 status. (Source: 32 CFR §170.21 and §170.24.)

What evidence do assessors need for MFA?

At minimum, evidence supporting all four objectives: a privileged-account inventory, and proof of MFA enforcement for local privileged, network privileged, and network non-privileged access. Strong packets include policy exports, sign-in logs, an exception list, and dated enforcement tests tied to the actual access paths. (Source: DoD CMMC Assessment Guide — Level 2.)

Is this legal or compliance advice?

No. This is educational research from The Defense Compliance Report, an independent trade publication on CMMC 2.0 and DIB compliance. Confirm scope, applicability, and contractual obligations with a CMMC Registered Practitioner/RPO or a qualified federal-contracts attorney.

Your next step

You came for a clear answer on CMMC MFA requirements, and here it is in one line: at Level 2, MFA (IA.L2-3.5.3) is mandatory for privileged accounts locally and over the network, and for all users over the network — it can’t be deferred, and “enabled” isn’t “enforced.” If you can prove that across every access path in your scope, you’re in good shape.

If you can’t yet — or you’re not sure — that’s a solvable problem, and the right kind of help depends on your specific gap.

Need help deciding what type of CMMC provider you need?

Tell us your level, scope, and timeline, and we’ll match you with source-checked CMMC provider options. Do not submit CUI, drawings, or sensitive contract details.

Find My CMMC Path →

Prefer to self-serve first? Download the CMMC Readiness Checklist →