StealthTech
Multi-factor authentication is the control most defense contractors think they’ve already handled. Everyone has MFA on Microsoft 365. Most have it on the VPN. On paper, the box is checked. Then a C3PAO assessor sits down, asks to see the privileged account inventory, and requests a live demonstration of an administrator logging into a server console. That’s the moment a lot of otherwise well-prepared organizations discover that “we have MFA” and “we meet IA.L2-3.5.3” are not the same statement.
This is worth a dedicated look because MFA isn’t just one control among 110. It’s consistently cited as one of the most frequently failed requirements in CMMC Level 2 assessments, it’s one of only two requirements in the entire framework with variable scoring, and unlike almost everything else in the framework, it cannot be carried on a Plan of Action and Milestones. If MFA isn’t fully implemented at assessment time, there’s no conditional path around it. This piece breaks down exactly what the control requires, where organizations get the scope wrong, and what assessors are actually looking for when they decide whether your implementation is adequate.
What IA.L2-3.5.3 Actually Requires
The control text itself is short: use multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. The plain language hides the part that trips people up, which is that MFA is required in three distinct scenarios, not one blanket policy.
Local access to privileged accounts covers an administrator logging into a server console, a workstation, or a network device directly, without going over a network connection. Network access to privileged accounts covers that same administrator connecting remotely, through a VPN, SSH, RDP, or a cloud identity provider. Network access to non-privileged accounts covers any standard user connecting to a CUI system over a network, whether that’s Microsoft 365, a VPN client, or a web-based application. The one scenario the control does not explicitly require MFA for is a standard user logging into their own local workstation while sitting at their desk, though most assessors and security practitioners still recommend it as baseline hygiene.
Miss any one of those three scenarios and the requirement is scored as not met in full, regardless of how well the other two are implemented. This is the gap that catches organizations that rolled out MFA project by project instead of scoping it against the control from the start. A company might have Conditional Access enforcing MFA for every cloud login, which covers network access for both privileged and non-privileged accounts, and still fail the requirement because local admin logins on the file server were never brought into scope. Our overview of the difference between CMMC Level 1 and Level 2 covers how this kind of scope gap tends to widen once an organization moves from FCI-only environments to full CUI protection.
Why This Is One of Only Two Controls With Partial Scoring
Under the CMMC Scoring Methodology in 32 CFR 170.24, nearly every one of the 110 security requirements is scored as a binary: met or not met, worth either one, three, or five points depending on how serious the exposure is if the control is missing. Multi-factor authentication is one of only two requirements in the entire framework where the DoD explicitly built in partial credit for partial implementation, the other being the FIPS-validated encryption requirement for CUI in transit. That detail matters because it signals how seriously the DoD’s scoring designers treat the risk of an all-or-nothing MFA gap: they built a mechanism specifically to distinguish an organization with no MFA at all from one that’s implemented it in some scenarios but not others.
In practice, that partial credit is a smaller safety net than it sounds. If MFA is missing entirely across all three required scenarios, the deduction is the maximum five points. If it’s implemented in some scenarios but not others, for example enforced on remote access but missing on local privileged logins, the deduction is smaller but still real, and it still shows up as a finding an assessor will document and a gap that needs remediation. Partial scoring changes how many points you lose. It doesn’t change whether the requirement generates a finding, and it doesn’t open a path to a POA&M for the pieces that are missing.
Why MFA Can’t Go on a POA&M
Most CMMC Level 2 requirements that aren’t fully met at assessment time can be documented on a Plan of Action and Milestones, with a defined remediation timeline that keeps a conditional certification alive while the gap gets closed. Our walkthrough of the CMMC assessment process covers how that conditional path works for most findings. Multi-factor authentication is specifically excluded from that flexibility.
It’s one of the requirements the DoD designated as too foundational to defer, on the reasoning that an organization without MFA is exposed to credential-based compromise in a way that a remediation timeline doesn’t meaningfully mitigate in the interim. Practically, this means MFA gaps discovered during a gap assessment need to be closed before the formal C3PAO assessment is scheduled, not folded into a POA&M alongside lower-priority findings.
What Assessors Actually Ask to See
The assessment objectives behind IA.L2-3.5.3 break the requirement into discrete determinations an assessor has to make: whether privileged accounts have been identified, whether MFA is implemented for local access to those accounts, whether MFA is implemented for network access to those accounts, and whether MFA is implemented for network access to non-privileged accounts. Each of those is examined, not just asked about. Assessors review policy documentation, but documentation alone doesn’t satisfy the requirement.
In practice, that means an assessor will typically ask for the actual list of privileged accounts and the systems each one administers, then ask to see a live login demonstrating MFA at each of the three required points: a standard user connecting to a CUI application or VPN, an administrator authenticating remotely, and an administrator logging in locally at a server or workstation console.
They’ll ask what MFA method is in use and whether it’s phishing-resistant. They’ll ask whether any accounts or access paths are excluded from MFA enforcement, and if so, why, and whether that exclusion is documented and risk-accepted rather than simply overlooked. A policy that says “MFA is required for all users” without naming the enforcement mechanism, the identity platform, and the accounts it covers reads as aspirational rather than implemented, and assessors are trained to draw that distinction.
Common Implementation Gaps That Generate Findings
A handful of patterns account for most of the MFA findings that show up in CMMC Level 2 assessments. Cloud applications get MFA enforced through the identity provider, but the on-premises VPN was configured separately and never brought into the same policy. Local administrator accounts on servers and network devices are protected by a shared or well-known password with no MFA layer at all, on the assumption that physical or network access controls are sufficient, which the control doesn’t recognize as an exception. Service accounts with elevated privileges authenticate with a static credential and no MFA equivalent, because service accounts don’t fit neatly into a human-centered MFA rollout and get quietly excluded.
SMS-based one-time codes are technically a second factor, but assessors increasingly scrutinize them because SMS is vulnerable to SIM-swapping and interception, and an organization relying on SMS as its only MFA method for privileged accounts should expect questions about why a stronger method wasn’t chosen. And perhaps most common: organizations that rolled out MFA in stages, covering new employees or new systems first, without ever completing a full inventory to confirm every privileged account and every network access path is actually covered. An assessor’s request for a Conditional Access report showing enforcement coverage, or the equivalent from whatever identity platform is in use, tends to surface these gaps immediately.
Phishing-Resistant MFA: Where the Bar Is Moving
The control text doesn’t mandate a specific MFA method, and it doesn’t require a government-grade credential like a PIV or CAC card. A password paired with an authenticator app, a hardware token, or biometric verification all satisfy the letter of the requirement. But the direction of both federal guidance and assessor expectations is moving toward phishing-resistant methods for the accounts that matter most.
NIST’s guidance on multi-factor authentication specifically recommends phishing-resistant authenticators for users with elevated privileges, and organizations that rely on SMS or basic push notifications for their administrator accounts are increasingly likely to face follow-up questions about why a stronger method wasn’t used, even where the control technically scores as met.
For most contractors, that translates into a practical hierarchy: hardware security keys or platform authenticators like Windows Hello for Business on privileged and administrative accounts, authenticator apps as the standard for everyday user access, and SMS phased out wherever the identity platform allows it. This isn’t a scored requirement on its own, but it’s the kind of detail that shapes how an assessor characterizes an organization’s overall security maturity during interviews, and that characterization carries weight beyond the single control being tested.
Building MFA Enforcement That Survives an Assessment
The organizations that pass this requirement cleanly tend to treat it as an enforcement and evidence problem, not a deployment problem. Deployment means MFA is available. Enforcement means it’s mandatory, applied through policy at the identity provider level, and impossible to bypass without a documented, risk-accepted exception. For contractors running Microsoft 365 and Entra ID, that means Conditional Access policies scoped to cover privileged roles, all network-based access, and local admin authentication through tools like Microsoft Entra ID and Intune, rather than relying on default settings that only cover a subset of the required scenarios.
The evidence side matters just as much as the technical configuration. A current, accurate inventory of privileged accounts, a Conditional Access or equivalent policy export showing enforcement scope, and a documented exception process for any account that isn’t covered are the artifacts an assessor expects to see alongside the live demonstration.
This is the kind of control-specific evidence discipline that a broader CMMC gap assessment should surface well before a formal C3PAO assessment, and it’s a common area where organizations that manage identity internally, without a partner who has actually sat through CMMC assessments, discover gaps too late. A managed IT partner with direct CMMC experience configures MFA enforcement with the specific assessment objectives in mind from the start, rather than applying general security best practices and hoping they satisfy a framework they weren’t built against.
For subcontractors responding to a prime’s flow-down security questionnaire, the same specificity applies before a formal assessment ever happens. Our guide to what prime contractors are actually requiring from subcontractors covers how vague answers about MFA coverage read as a red flag to primes long before a C3PAO ever gets involved. And for organizations still working through which CMMC level applies to their contracts and what’s in scope, our explanation of what CUI is and why it matters for compliance is a useful starting point for understanding why a control like this one carries so much weight in the first place.
Stealth Technology Group configures and verifies multi-factor authentication enforcement to meet CMMC Level 2 assessment objectives, not just general security best practices. If you’re preparing for a CMMC Level 2 assessment and want to confirm your MFA implementation will hold up, contact Stealth Technology Group today at (617) 903-5559 to talk with a specialist.
