Table of contents
When organizations prepare for CMMC Level 2, one control consistently creates last-minute risk: multi-factor authentication (MFA) or two-factor authentication (2FA). The issue isn’t whether MFA is important—it’s that CMMC MFA requirements apply broadly across accounts and access methods, while many real-world applications were never designed to support modern MFA.
If you support the DoD as a prime contractor, subcontractor, supplier, or manufacturer, the relationship between CMMC and MFA is unavoidable. You need a practical way to enforce MFA consistently—especially for systems that can’t be rewritten before an assessment.
This guide explains what CMMC requires, where MFA typically gets missed, and how to meet CMMC MFA requirements across legacy, custom-built, and commercial off-the-shelf (COTS) applications and systems—without writing code.
What are the CMMC MFA requirements?
For CMMC Level 2, the MFA practice (IA.L2-3.5.3) aligns to NIST SP 800-171 Rev.2 requirement 3.5.3, which states:
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
In practice, CMMC MFA requirements mean MFA must be enforced for:
- Privileged accounts (local + network access) Admins, operators, system maintainers, database owners, and application administrators.
- Non-privileged accounts (network access) Regular users accessing any system over a network (internal or external).
- Remote access paths VPN, RDP, SSH, remote browser access, and other remote access sessions are commonly where “network access” shows up in audits (and where MFA must be provable).
Where MFA applies under CMMC (and why many organizations miss it)
Many teams interpret CMMC MFA requirements as “MFA for admins” or “MFA for VPN.” That’s necessary—but often not sufficient.
The common miss: MFA coverage stops at your most modern apps (or your IdP-integrated apps), while older or non-standard apps remain password-only. In most environments, “network access” includes:
- Internal web apps (intranet portals, HR systems, ERP/CRM, dashboards)
- Legacy applications running on-prem
- Custom line-of-business portals
- Customer/partner/supplier access portals (when hosted by your organization)
- COTS applications that don’t integrate cleanly with your chosen IdP
- API endpoints that require user authentication
If traffic travels over IP and authentication is happening over a network, MFA enforcement needs to be consistent and auditable—this is where CMMC MFA gaps typically appear.
Why CMMC MFA is difficult for legacy, custom-built, and COTS applications
Even if your organization already bought an MFA solution, CMMC readiness often hits these blockers:
- The most business-critical apps are often the oldest
- Some apps don’t support SAML/OIDC (or any modern auth standard)
- Rewriting apps is expensive, risky, and slow
- Teams don’t have the dev bandwidth to retrofit authentication
- COTS apps may not support your MFA provider (or only support limited options)
- MFA ends up inconsistent across different portals and systems
So the “rule” is straightforward, but achieving full coverage for CMMC MFA requirements across every in-scope system is not.
Fast-track compliance: enforce MFA outside the application (no code changes)
The fastest and most reliable way to meet CMMC MFA requirements is to enforce MFA without modifying the underlying application—especially when you’re dealing with legacy and COTS systems.
That’s what Datawiza is designed for.
- Datawiza No-Code MFA: Add MFA/2FA to any web application with no code modifications—use Datawiza built-in MFA or integrate with leading identity providers.
Because enforcement happens in front of the application, the application doesn’t need to support MFA, SAML, or OIDC to meet the control intent.
What this looks like for CMMC Level 2 assessment readiness
A no-code MFA enforcement approach helps you:
- Apply MFA consistently across in-scope applications and systems
- Eliminate MFA “holes” created by legacy, custom-built, or COTS apps
- Avoid costly app rewrites and authentication refactors
- Use your existing IdP MFA—or Datawiza built-in MFA—based on your environment
- Generate audit-friendly evidence (policy + logs) that assessors can validate
A practical roadmap to meet CMMC MFA requirements
Use this checklist to reduce surprises:
- Inventory all applications tied to CUI workflows (include internal portals and externally accessed portals you host)
- Identify which systems are still password-only or inconsistent in MFA enforcement
- Enforce MFA in front of those apps (fastest path when you can’t modify the app)
- Integrate MFA with your existing provider (or use built-in MFA where appropriate)
- Centralize logging/evidence so assessors can validate MFA enforcement
FAQ: CMMC MFA requirements
Is MFA required only for administrators under CMMC Level 2? No. IA.L2-3.5.3 requires MFA for local and network access to privileged accounts and for network access to non-privileged accounts.
Does MFA apply to internal applications? If users access a system over the network (common for internal web apps and portals), MFA coverage needs to be addressed and defensible during assessment.
What if a legacy or COTS app can’t integrate with Entra ID / Okta / Ping? That’s a common situation. A proxy-based, no-code approach can enforce MFA in front of the app so the app doesn’t need to be rewritten to “speak” modern identity protocols.
Conclusion: CMMC MFA requirements don’t have to slow you down
The relationship between CMMC and MFA is straightforward. The hard part is executing MFA consistently across legacy, custom-built, and commercial off-the-shelf (COTS) applications and systems—without disrupting your environment or launching risky rewrite projects.
If you want the fastest path to closing MFA gaps for IA.L2-3.5.3, Datawiza can help.
