CMMC Level 2 MFA: Phishing-Resistant Logins With FIDO2 Security Keys

If you’re chasing CMMC Level 2, you already know the ugly truth: phishing is still the easiest way into a DoD contractor. Attackers don’t need zero-days when they can steal a password and a one-time code.

My bottom line is simple: CMMC Level 2 MFA needs to hold up against real phishing, not just checkbox audits. In practice, that pushes most teams toward phishing-resistant MFA using FIDO2 security keys (and, in some cases, device-bound passkeys).

In this guide, I’ll walk through scoping, rollout choices (admins first vs everyone), configuration patterns that work in Microsoft Entra ID or Okta, and what evidence I prepare for assessors.

What CMMC Level 2 actually expects from MFA (and what it doesn’t)

CMMC Level 2 aligns to NIST SP 800-171, and the MFA control most teams trip over is 3.5.3 (CMMC practice IA.L2-3.5.3). The plain-English requirement is: use MFA for local and network access to privileged accounts, and for network access to non-privileged accounts. In addition, remote access MFA expectations show up across related access control requirements, depending on your architecture and boundary.

When I scope this for a small DoD contractor, I start with where CUI is accessed and where admin actions happen:

• Identity provider sign-ins (SSO to email, files, and line-of-business apps)
• Remote access (VPN, VDI, remote admin tools)
• Privileged access paths (cloud admin portals, servers, hypervisors, network gear)
• Any “jump box” used to reach the CUI enclave

For a quick control-oriented refresher, I often point leaders to the DIB SCC’s breakdown of IA.L2-3.5.3 multifactor authentication. For mapping context, the DoD CIO’s CMMC alignment to NIST standards is useful when you need to explain “why this control exists” to non-security executives.

Two boundaries I keep explicit (because over-claiming here can burn you in an assessment):

• CMMC doesn’t “certify a product.” It evaluates your implemented practices and evidence.
• “MFA enabled” isn’t enough. Assessors look for enforced policies, coverage across in-scope systems, and proof it’s actually used.

Why phishing-resistant MFA usually means FIDO2 (and where passkeys fit)

Most MFA fails in the same way: users can be tricked into approving a login on a fake site or a live man-in-the-middle proxy. Phishing-resistant MFA blocks that pattern by binding authentication to the real site and using cryptographic challenge-response instead of reusable secrets.

FIDO2 (via WebAuthn) does this well because the private key stays on the authenticator, and the login is origin-bound. That design lines up with federal direction to move away from phishable factors (OMB M-22-09) and with NIST SP 800-63 digital identity guidance (phishing resistance for higher assurance use cases).

Here’s the quick comparison I use when choosing enforcement levels:

MFA method	Phishing-resistant?	Typical failure mode	Fit for CMMC Level 2
SMS OTP	No	SIM swap, phishing proxy	Avoid for in-scope access
TOTP app codes	No	Real-time phishing proxy	Better than SMS, still phishable
Push approval	Sometimes	Push fatigue, proxy attacks	Risky without number matching and strong controls
FIDO2 security key	Yes	Lost key, poor recovery plan	Strong default for in-scope users
Device-bound passkey	Yes (when device-bound)	Device loss, shared accounts	Good when managed and auditable

If you want a practical walkthrough of the mechanics, this guide on implementing phishing-resistant MFA with FIDO2 does a nice job explaining common rollout snags.

My decision rule is straightforward: if a user can touch CUI or administer systems that protect CUI, I want FIDO2-level resistance. If they can’t, I still prefer it, but I may phase it in.

Implementation guide: rolling out FIDO2 keys without breaking work

Step 1: Draw your “MFA boundary” before you buy keys

First, I inventory identities, not devices. I list human users, admin accounts, service accounts, and shared logins (then I work to eliminate shared ones). Next, I map every interactive login path into the CUI boundary, including browsers and thick clients.

This is where a lot of Small Business IT teams get surprised. CUI access often happens through “normal” tools like email and file sharing after an Office 365 Migration, not just in a labeled enclave. That’s why I treat identity as part of Cloud Infrastructure design, not a bolt-on.

I also align the rollout to business realities. As a Business Technology Partner, I’m usually balancing Technology Consulting with operations, including Data Center Technology needs and Secure Cloud Architecture decisions. Even clients who call me for Restaurant POS Support or Kitchen Technology Solutions benefit from the same disciplined access model, because identity sprawl doesn’t stay in one department.

Step 2: Decide how hard to enforce, admins first or everyone

I use this decision point to keep progress moving:

• If you have fewer than 25 in-scope users, I usually require keys for all in-scope users within 30 days.
• If you have multiple locations, heavy travel, or many contractors, I enforce admins first, then expand in waves.

A good “Wave 1” target set is: global admins, server admins, firewall/VPN admins, and anyone with access to CUI repositories.

Gotcha: if you allow a weak fallback factor “just in case,” people will use it under pressure. Your policy has to match your intent.

Step 3: Configure your IdP to require phishing-resistant methods

I keep this vendor-neutral in principle: enable FIDO2/WebAuthn, scope it to groups, require it with conditional access (or sign-on policies), then remove weaker factors for in-scope apps.

Concrete patterns that translate well:

• Entra ID: Enable FIDO2 security keys for a pilot group, then create Conditional Access policies that require phishing-resistant MFA for CUI apps and admin portals. Block legacy authentication. Require compliant devices where possible.
• Okta: Enable the FIDO2 (WebAuthn) authenticator, then update sign-on policies so the CUI app group requires FIDO2. Limit or disable SMS and email OTP for those apps.

In parallel, I tighten Endpoint Security, because keys don’t fix a compromised endpoint. That includes Device Hardening (local admin control, patching, disk encryption) and browser protections, since most phishing starts there. If you need a Microsoft 365-focused checklist to compare against, I like this Microsoft 365 security best practices guide as a sanity check.

Step 4: Enrollment, backups, and recovery (the part auditors ask about)

My baseline is “two authenticators per user”:

1. Issue two physical keys, or one key plus a managed device-bound passkey (if your platform supports it cleanly).
2. Require PIN (and allow biometrics where supported) so the key can’t be used if stolen.
3. Lock down self-service resets so users can’t bypass phishing-resistant MFA with email links.

For travelers, I issue at least one NFC-capable key. For contractors, I either provide a company-owned key or require them to use a key under a written access agreement, then I document it.

Step 5: Evidence I prepare for a CMMC assessment

I don’t rely on screenshots alone. I build an evidence packet that shows intent and enforcement:

• Policy stating where phishing-resistant MFA is required
• Group membership for in-scope users and admins
• IdP policy exports (or admin screenshots plus change tickets)
• Authentication logs proving FIDO2 usage for CUI apps
• Key issuance records and break-glass procedure
• Training acknowledgement

This is also where I tie the work back to Innovative IT Solutions that support Infrastructure Optimization and Digital Transformation, without weakening Business Continuity & Security.

FAQ: FIDO2 security keys for CMMC Level 2

Will FIDO2 work on Mac, Windows, and Chrome?
Yes, in most environments. WebAuthn support is broad in modern browsers and OS builds, but I still pilot first.

Do users need biometrics?
No. A PIN on the key is common. Biometrics can be used when the authenticator supports it.

Should I require two keys per person?
For in-scope users, I do. One key gets lost at the worst time.

What about mobile sign-ins?
Choose keys with NFC or USB-C. Test the exact device mix your team uses.

Can I start with admins only?
Yes, if you document the phased plan and keep the timeline tight. I still protect any CUI access path early.

How do I handle contractors and temporary staff?
I issue company-controlled keys when possible, and I time-box access. I also avoid weak recovery channels.

Conclusion

Phishing-resistant authentication isn’t a luxury in 2026, it’s basic hygiene for DoD contractors. When I implement CMMC Level 2 MFA with FIDO2 security keys, I focus on scope first, enforcement second, and evidence throughout. If you want this to stick, pair strong MFA with Cloud Management discipline and Managed IT for Small Business operations. The best time to fix access is before the next “urgent” login prompt shows up.