TL;DR: CMMC Level 2 and Level 3 expectations push DoD contractors toward phishing-resistant authentication, with NIST SP 800-63B and CISA cited as the practical standard-setters for what auditors will accept, according to Axiad. The real issue is no longer whether MFA exists, but whether it is cryptographically bound enough to withstand verifier impersonation and replay attacks.
NHIMG editorial — based on content published by Axiad: MFA & Russian Dolls: Understanding CMMC Compliance & Phishing Resistant Authentication
Questions worth separating out
Q: How should defence contractors implement phishing-resistant MFA for CMMC?
A: Start by mapping access flows to the assurance level they need, then choose authenticators that bind cryptographically to the relying party.
Q: Why is ordinary MFA not always enough for CMMC compliance?
A: Ordinary MFA can still fail if the authenticator is not verifier impersonation-resistant.
Q: What should teams do when they cannot prove phishing resistance?
A: Treat that gap as an implementation issue, not a documentation issue.
Practitioner guidance
- Inventory every authentication path against its assurance level Map user, admin, and contractor access flows to the relevant CMMC and NIST SP 800-63B assurance expectations, then identify where the current method is only MFA in name.
- Validate phishing resistance at the relying-party level Test whether the authenticator is cryptographically bound to the intended application or website and cannot be replayed through an impostor verifier.
- Collect audit evidence before the assessment window opens Assemble policy, implementation, key storage, and recovery evidence together so auditors can trace the control from design to operation.
What's in the full article
Axiad's full article covers the operational detail this post intentionally leaves for the source:
- The article walks through the specific CMMC assessment references that point auditors toward authentication evidence.
- It details how NIST SP 800-63B maps to AAL2 and AAL3, including the distinction between generic MFA and phishing-resistant methods.
- It explains which cryptographic properties CISA treats as acceptable for phishing-resistant authentication.
- It gives contractors a practical frame for deciding whether their current identity stack will survive CMMC scrutiny.
👉 Read Axiad's analysis of CMMC phishing-resistant authentication requirements →
CMMC and phishing-resistant MFA: are your controls ready?
Explore further
Phishing-resistant MFA has become an assurance problem, not a factor-count problem. The article shows that CMMC compliance is really about whether authentication can survive verifier impersonation and replay, not whether a second factor exists. NIST SP 800-63B and CISA define the technical expectation more tightly than many contractor policies do. For practitioners, the important shift is to stop measuring MFA by adoption and start measuring it by binding strength and attack resistance.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable for authentication design under CMMC?
A: Identity, security, and compliance teams share accountability because the control spans policy, technical configuration, and audit evidence. For regulated contractors, the authentication method must be selected and documented in a way that matches the contract requirement, not just local convenience. If the evidence chain is weak, accountability lands with the programme owner.
👉 Read our full editorial: Phishing-resistant authentication is now a CMMC requirement