Want to learn more about services? Book a free introductory call - "Here"
Multi-Factor Authentication Sounds Simple
MFA on your email isn't enough for CMMC Level 2. Here's what IA.L2-3.5.3 actually requires, why the gap keeps showing up, and what evidence assessors expect.
CMMC BLOG
Daniel McLain
8/28/20266 min read
Multi-Factor Authentication Sounds Simple.
It's the Practice Most Companies Fail Anyway
If you've already rolled out multi-factor authentication (MFA) and you're still failing the identification and authentication practice in a Cybersecurity Maturity Model Certification (CMMC) readiness review, you're not imagining it, and you're not alone. This is one of the practices practitioners and assessors most consistently flag as a source of findings, precisely because most companies think they've already handled it.
The short version: the requirement is broader than "we turned on MFA somewhere." It covers specific account types and specific access paths, and missing even one of them is enough to score the practice as not met.
What the requirement actually says
The practice is IA.L2-3.5.3, in the Identification and Authentication (IA) domain of NIST SP 800-171 (the National Institute of Standards and Technology's Special Publication 800-171, Revision 2), which is the security requirement set that CMMC Level 2 is built on. The requirement text is:
"Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts."
That's one sentence, but it describes three separate scenarios, and all three have to be covered:
Local access to privileged accounts (an administrator logging directly into a server, workstation, or piece of network equipment, not over a network)
Network access to privileged accounts (an administrator connecting remotely, over a Virtual Private Network (VPN), Remote Desktop Protocol (RDP), Secure Shell (SSH), or similar)
Network access to non-privileged accounts (a regular user connecting to a system that's in scope for Controlled Unclassified Information, or CUI)
"Privileged" here means administrator-level or elevated access: domain admin accounts, local admin accounts on servers and workstations, firewall and switch management accounts, and similar. MFA (multi-factor authentication, meaning two or more independent factors, such as a password plus a hardware token, authenticator app, or biometric) has to cover all of those, not just the ones that happen to be easy to configure. (DIB SCC CyberAssist; NIST SP 800-171 Rev 2, full text)
Why "we have MFA" isn't the same as meeting the practice
Here's the pattern we see over and over, and it's echoed in practitioner writing on this exact control: an organization enforces MFA on its cloud email and productivity suite (Microsoft 365, Google Workspace) through the identity provider, calls it done, and moves on. That's a real security improvement. It's also not the same thing as meeting IA.L2-3.5.3, because that cloud login is usually a non-privileged, network-access scenario. It doesn't touch local admin logins on servers, VPN access for IT staff, or the management interface on a firewall.
One industry writeup on this control put it directly: cloud applications get MFA through the identity provider, but the on-premises VPN was set up separately and never brought under the same policy, and local administrator accounts on servers often get treated as exempt because organizations assume physical access or network segmentation is protection enough. It isn't, as far as this requirement is concerned. Elevated-privilege service accounts that authenticate with static credentials are another common blind spot, since they don't fit a typical human-user MFA rollout and get skipped. (StealthTech365)
That framing (fragmented coverage across cloud and on-premises systems, local admin accounts left out, service accounts overlooked) is a description of a common real-world implementation gap based on how these environments actually get built over time, not an official government-published statistic. But it lines up with what we see in practice: partial MFA coverage, not absent MFA, is usually the problem.
A concrete example
Picture a 40-person engineering subcontractor with an on-premises Windows Server domain and a Microsoft 365 tenant for email and file collaboration. They enabled MFA on Microsoft 365 two years ago after a phishing scare and consider authentication "handled." When they go through a readiness review for a Level 2 self-assessment, three gaps show up:
The domain administrator account used to manage the file server holding CUI has no MFA. IT logs into the server console directly with a password only.
The VPN that field engineers use to reach the internal network has password-only authentication.
The management interface on the perimeter firewall is accessible with a single admin password, no second factor.
Each of those is a privileged-account access path (two local, one network) that the Microsoft 365 rollout never touched. None of it was intentional negligence. It's what happens when MFA gets deployed system by system instead of mapped against every privileged account and access path in the environment.
How common is this, really
We're not aware of a published Department of Defense (DoD) or Cyber AB (the accreditation body that oversees the CMMC Ecosystem) statistic naming IA.L2-3.5.3 as the single most-failed practice across all assessments, and you should be skeptical of any source that cites one without a traceable source. What we can say, based on practitioner and assessor commentary, is that this control is consistently described as one of the most frequently misinterpreted and most frequently cited requirements in Level 2 work, for the exact scope reasons above. One practitioner resource on preparing evidence for this control opens by calling it "one of the most frequently misinterpreted controls" in the whole 800-171 set. (Ascera) Treat "commonly failed" as a well-supported pattern reported across the practitioner community, not a formal DoD ranking.
Where this fits given the current state of CMMC
As of this writing, the Department of Defense (DoD), which has also been using "Department of War" as a secondary title in some official communications since a September 2025 executive order, has suspended the CMMC Phase 2 requirements that would have made third-party C3PAO (Certified Third-Party Assessment Organization) certification assessments mandatory, pending a reform review that opened July 13, 2026. That pause affects the third-party assessment mechanism. It does not touch the underlying NIST SP 800-171 Rev 2 requirements, ongoing self-assessment obligations, or your Supplier Performance Risk System (SPRS) score submissions if your contract includes DFARS (Defense Federal Acquisition Regulation Supplement) clause 252.204-7012 or the related self-assessment clauses. (We cover the Phase 2 pause in more detail in a separate post: [link: CMMC Phase 2 pause article].)
Practically, that means IA.L2-3.5.3 doesn't stop mattering just because a formal C3PAO assessment isn't currently required on your contract. If you're self-assessing and submitting a score to SPRS, you're still scoring yourself against this practice, and an inaccurate self-assessment carries its own risk under the False Claims Act if it's later found not to reflect reality. MFA scope is also not the kind of requirement we'd expect a reform effort to loosen. It's a foundational control, not a paperwork burden.
What good evidence looks like
Whether you're preparing for a self-assessment, a future certification assessment, or just want a clean answer the next time someone asks "are we covered here," the practical evidence for this practice generally falls into a few buckets:
Configuration exports or screenshots from your identity provider, Active Directory, VPN concentrator, and network device management interfaces showing MFA enforcement policies applied to privileged and non-privileged accounts
Policy documentation describing your identification and authentication requirements, including which accounts are classified as privileged
Enforcement records showing that MFA can't be bypassed or disabled by the end user
Access or authentication logs that show MFA actually being used on privileged local access, privileged network access, and non-privileged network access, not just the policy that says it should be
An assessor (or an internal reviewer doing the same job before one shows up) isn't just looking for a policy statement that says "we use MFA." They're looking for proof that maps to all three access scenarios in the requirement. This is our recommendation on how to document the practice well, not a guarantee that any particular evidence set will satisfy a given assessor or produce a specific score.
What to do next
Start by inventorying every privileged account in your environment, not just the ones tied to your primary identity provider: local server admin accounts, network device management accounts, VPN administrative access, and any service accounts with elevated rights. Map each one against the three scenarios in IA.L2-3.5.3 and note where MFA is enforced today versus where it's assumed. That inventory alone usually surfaces the gap before anyone else has to point it out.
This is general informational guidance, not legal advice, and it isn't a substitute for a compliance determination specific to your environment. For that, work with a Registered Practitioner Organization (RPO) or, when a certification assessment is required, a C3PAO.
Before investing in tools, documentation, or an assessment, make sure you understand what the contract requires and which parts of your environment are actually in scope. ICTS USA can help you evaluate the opportunity, identify the gaps, and determine a practical next step.