MFA for CMMC: Why SMS Fails 3.5.3 and What Hardware Passes

Read the requirement in two pieces. The first is coverage: multifactor authentication for network access and for privileged accounts. Multifactor means two of the three classic factor types — something you know, something you have, something you are — and two passwords are not two factors. The second piece is quality: on that same network and privileged access, 3.5.3 asks for authenticators that resist replay — meaning an attacker who captures or relays the authentication exchange cannot reuse it.

Coverage is the part most contractors scope correctly and implement incompletely. Quality is the part that gets skipped, because the tooling that fails it is also the tooling that is easiest to roll out on a Friday.

Both sit inside CMMC Level 2, which is 110 requirements mapped one-to-one to NIST SP 800-171 Rev 2 and assessed against 320 objectives. Level 1 — the 15 requirements from FAR 52.204-21 that apply to contractors handling only Federal Contract Information — does not include multifactor authentication. That is worth confirming before you buy an authenticator program you are not required to have: the information type you actually handle drives everything downstream.

NIST has been explicit about this for a long time. SP 800-63B has treated out-of-band authenticators delivered over the public switched telephone network — SMS and voice one-time codes — as RESTRICTED since 2017, with a documented set of risks and an expectation that organizations relying on them assess and disclose that risk. The guidance predates CMMC and has not softened since.

The mechanics behind the classification are why assessors flag it. A texted code can be intercepted at the carrier layer through SIM-swap fraud or signaling-network abuse, which defeats the 'something you have' assumption entirely — the phone number, not the phone, turns out to be the factor. More common today: a real-time phishing proxy sits between the user and the genuine login page, relays the code the instant the user types it, and completes the authentication. The code was valid, the user was real, and the attacker is inside. Nothing in that exchange resisted replay.

Push-approval prompts are a partial improvement and a partial repeat of the same problem. They take the code off the wire but keep a human in the approval loop, which is exactly what MFA-fatigue attacks target. Number matching and context display make push materially harder to abuse and are worth enabling, but they are a mitigation rather than a cryptographic answer.

The practical consequence at assessment: an environment where privileged administrators authenticate with a password and a texted code should expect that path to be examined closely, and should not expect a policy document to resolve it.

The most expensive way to deploy MFA for CMMC is to deploy it everywhere because nobody drew a boundary. Level 2 applies to the environment where CUI lives, and the scope you define — and document in your SSP — determines how many users, endpoints and administrative paths the requirement has to reach.

For a mid-size contractor, a defined CUI enclave is usually the difference between outfitting a whole company and outfitting a department. The enclave holds the systems that store, process or transmit CUI plus the systems that protect them, with a documented boundary and controlled paths in and out. What sits outside it is outside the scope of these requirements — provided the boundary is real, enforced and evidenced rather than a line on a diagram.

The trade is that the enclave has to be enforced by infrastructure: segmentation on the switching, boundary protection at the interfaces, and authentication at every entry point into it. That is why scoping and hardware get planned in the same meeting. A tighter scope shrinks the authenticator count and grows the segmentation requirement, and the cheapest honest answer usually sits somewhere between the two.

Support for PIV, CAC or FIDO2 is a technical-compatibility fact about a device. It tells you the reader will talk to the card, or that the key will complete a WebAuthn ceremony with your identity provider. It is not a government endorsement of the product, of your program, or of the company selling it, and no vendor should present it as one.

The same boundary applies to everything else on the quote. No purchase — hardware, license or service — confers certification on its own; what a supplier can do is make the controls implementable. We can quote readers, keys where they can be sourced, the multifactor licensing that runs alongside them, and the segmentation and boundary gear an enclave needs, against the scope you have already defined. What ships is the capability behind the control, never a Uniqcli certification, and we quote against the SSP you already have rather than a generic bundle.