How Multi-Factor Authentication Works for CMMC: A Deep Dive

How Multi-Factor Authentication Works for CMMC: A Deep Dive

Multi-factor authentication (MFA) appears across multiple CMMC practices and is one of the most frequently assessed controls. Getting it right matters. Getting it wrong is one of the fastest ways to a NOT MET finding.

Multi-factor authentication (MFA) is a core expectation across several CMMC Level 2 practices and is one of the most scrutinized controls during assessments.

Practices That Require or Depend on MFA

• IA.L2-3.5.3 – Use MFA for privileged accounts

Requires MFA for:

• Local access to privileged accounts (e.g., admin logons at the console)

How Multi-Factor Authentication Works for CMMC: A Deep Dive

Multi-factor authentication is one of the most frequently assessed — and most frequently failed — practices in CMMC Level 2. Not because organizations don't have MFA, but because they don't have it everywhere CMMC requires it.

This guide covers exactly what CMMC demands for MFA, where organizations get caught, and how to verify your implementation before an assessor does.

What CMMC Actually Requires for MFA

CMMC Level 2 maps to NIST SP 800-171 practice IA.L2-3.5.3: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

That single sentence contains three distinct requirements:

1. MFA for local access to privileged accounts — Admin logging in at the console
2. MFA for network access to privileged accounts — Admin logging in remotely (RDP, SSH, VPN)
3. MFA for network access to non-privileged accounts — Regular users logging in remotely

Most organizations nail requirement #2 (remote admin access) and partially cover #3 (remote user access). Requirement #1 — local privileged access — is where assessors find gaps.

The Three Authentication Factors

MFA requires at least two of three factor categories:

Something you know — Passwords, PINs, security questions

Something you have — Hardware tokens, smart cards, mobile authenticator apps, FIDO2 security keys

Something you are — Fingerprint, facial recognition, iris scan

Two items from the same category do not count. A password plus a PIN is still single-factor (both are "something you know"). A password plus a FIDO2 key is valid MFA (know + have).

Where Organizations Fail MFA Assessments

Gap 1: Service Accounts Without MFA

Service accounts that run automated processes are privileged accounts. If a human can log in with those credentials, MFA must be enforced. The workaround: ensure service accounts are configured as non-interactive — meaning they cannot be used for console or remote login. Document this explicitly.

Gap 2: Local Admin Access Bypasses MFA

Windows local administrator accounts accessed at the physical console often bypass MFA. Solutions include:

• Windows Hello for Business with biometric or PIN-as-second-factor
• LAPS (Local Administrator Password Solution) with MFA-gated retrieval
• CyberArk or Thycotic privileged access management with session recording

Gap 3: Legacy Systems That Can't Support MFA

Some older systems (legacy manufacturing equipment, embedded controllers) cannot support modern MFA. For these:

• Document the system in your SSP as a legacy exception
• Implement compensating controls (network segmentation, enhanced monitoring, restricted physical access)
• Include a migration plan with target dates

Gap 4: MFA Fatigue and Push Notification Attacks

Assessors are increasingly aware of MFA fatigue attacks. If you use push-based MFA (like Microsoft Authenticator), demonstrate that you have:

• Number matching enabled (user must type the number shown on screen)
• Additional context shown in push notifications (app name, location)
• Anomalous login detection that blocks rapid-fire push attempts

MFA Implementation by Access Type