FIPS Validated Cryptography in Practice: Where It Meets CMMC Identification and Authentication

This post looks at where the Identification and Authentication (IA) family and FIPS validated cryptography overlap, the points that are still open to interpretation, and how to collect evidence that will hold up in an assessment.

Does the CMMC Phase II pause change anything about FIPS requirements?

No. Recent coverage of the Phase II pause, including BPM's analysis this week, makes a point worth repeating: contractors and subcontractors who handle covered defense information are still contractually required to protect it under DFARS 252.204-7012, and NIST SP 800-171 Rev 2 is still the governing standard. Requirement 3.13.11 of SP 800-171 Rev 2 is where the FIPS validated cryptography obligation comes from. That obligation existed before CMMC and it does not depend on the phased rollout.

The pause affects when certain assessment requirements appear in solicitations. It does not affect what you are already required to implement. We are not going to guess when Phase II requirements will resume, because nothing about that is settled. A contractor who uses the pause to finish a cryptographic module inventory will be in a much better position than one who treats it as time off.

Where does FIPS validated cryptography actually touch Identification and Authentication?

The IA family in SP 800-171 Rev 2 does not use the word FIPS. The overlap appears because several IA requirements are cryptographic by nature, and the cryptography involved usually protects sessions or systems that carry CUI. These are the main touchpoints:

• IA.L2-3.5.3 Multifactor Authentication. One-time password generators, FIDO2 keys and smart cards all depend on cryptographic operations. Smart cards and hardware security keys often carry their own validation certificates, so check them individually and do not assume.
• IA.L2-3.5.4 Replay-Resistant Authentication. NIST's discussion of this requirement names mechanisms such as TLS, nonces, challenge and response, and time synchronous one-time authenticators. Each of these is cryptography, and when it protects a channel carrying CUI, the module behind it falls under the scope of SC.L2-3.13.11.
• IA.L2-3.5.10 Cryptographically-Protected Passwords. Passwords must be stored and transmitted only in cryptographically protected form. NIST's discussion refers to salted one-way cryptographic hashes for storage. Transmission normally depends on an encrypted channel.
• AC.L2-3.1.13 Remote Access Confidentiality. This one sits in a different family, but remote access is where most authentication happens. The VPN or TLS session that carries a user's login and then their CUI is a classic SC.L2-3.13.11 scoping question.

At Level 1, IA.L1-B.1.V (identify users) and IA.L1-B.1.VI (authenticate users) carry no FIPS requirement. Level 1 protects Federal Contract Information under FAR 52.204-21, and none of its fifteen requirements requires validated cryptography.

One thing is truly unsettled: whether cryptography that protects credentials, as opposed to CUI itself, needs to be FIPS validated. A password hash protects a password. It does not directly protect CUI. Some assessors read SC.L2-3.13.11 narrowly. Others argue that credentials guarding a CUI system are part of protecting CUI confidentiality. The safe approach is to use FIPS validated modules for authentication wherever you can, and to agree on the interpretation with your C3PAO before the assessment rather than during it.

What is the difference between FIPS validated and FIPS compliant?

This distinction is the cause of most cryptography findings. FIPS compliant, FIPS ready and FIPS capable are marketing terms. FIPS validated has a specific meaning: the cryptographic module was tested by an accredited laboratory and received a certificate from the Cryptographic Module Validation Program (CMVP), which NIST runs together with the Canadian Centre for Cyber Security.

A certificate covers a specific module, a specific version and specific operating environments. It comes with a security policy document that defines the approved mode of operation. Your implementation satisfies the requirement only if all of these conditions hold:

1. The module in your environment matches a version listed on an active CMVP certificate.
2. The module runs on an operating environment covered by that certificate, or one the security policy allows.
3. The module is configured to operate in its approved mode, which usually means enabling the operating system's or application's FIPS mode setting.
4. The algorithms in use are approved ones listed in the security policy.

Watch certificate status too. Under the CMVP's published transition schedule, the remaining FIPS 140-2 certificates moved to the Historical list in September 2026, and FIPS 140-3 is now the current standard. Check the CMVP site for each module you depend on. DoD has not published clear, CMMC-specific guidance on how assessors should treat modules that rely on historical certificates, so that question is also not settled. Find out whether your vendors have a FIPS 140-3 validation or one in process, and record their answer.

How do you prove FIPS validated cryptography to a C3PAO?

A C3PAO evaluates SC.L2-3.13.11 and the related IA objectives against evidence, not claims. The following approach produces an evidence package that can be defended:

1. Map every place cryptography protects CUI or the credentials that unlock it. That covers remote access, email, file transfer, web applications, endpoint storage, removable media under MP.L2-3.8.6, wireless under AC.L2-3.1.17, and the authentication paths described above.
2. For each location, identify the actual cryptographic module. The application name is not enough. The module might be the operating system's cryptographic library, a VPN appliance's firmware, or a library bundled inside a third-party product.
3. Record the CMVP certificate number, the module name and version, the certificate status and a link to the security policy.
4. Capture configuration evidence that approved mode is turned on. Examples include the operating system policy setting for FIPS algorithms, the Linux kernel FIPS flag, or the appliance setting that enforces FIPS mode.
5. Confirm the deployed version matches the certified version. Vendor updates can move a module outside its validated version until a new certificate is issued.
6. Record the results in your System Security Plan under SC.L2-3.13.11, and cross-reference the IA requirements that rely on those modules.

Test FIPS mode before you enforce it across the environment. Turning it on can break legacy applications and protocols that use algorithms outside the approved set. It is better to find those breakages in a pilot than in production. While you are inventorying, look closely at legacy authentication protocols. Some older protocols still in use in Windows environments depend on algorithms that are not FIPS approved.

What happens if a cryptographic module is not FIPS validated?

The CMMC scoring rules in 32 CFR Part 170 handle this situation specifically. SC.L2-3.13.11 is a 5 point requirement. Under 32 CFR 170.24, if encryption is in use but is not FIPS validated, the deduction is 3 points, not the full 5. Under 32 CFR 170.21, that partial condition is one of the few higher-value items allowed on a POA&M for a Conditional status, and the POA&M must be closed out within the time the rule allows.

That treatment is narrow. If no encryption is in place, the full deduction applies and the item cannot go on a POA&M. IA.L2-3.5.3 Multifactor Authentication has a value above 1 point and has no comparable exception, so a gap there cannot be deferred through a POA&M. Treat the 3.13.11 exception as a narrow safety valve, not as a plan.

Frequently Asked Questions

Sources

• NIST SP 800-171 Rev 2, Protecting CUI in Nonfederal Systems (csrc.nist.gov)
• NIST SP 800-171A, Assessing Security Requirements for CUI (csrc.nist.gov)
• 32 CFR Part 170, CMMC Program (ecfr.gov)
• NIST Cryptographic Module Validation Program (csrc.nist.gov)
• FIPS 140-3, Security Requirements for Cryptographic Modules (csrc.nist.gov)
• DoD CIO, Cybersecurity Maturity Model Certification (dodcio.defense.gov)
• BPM, CMMC Phase II Pause: What Contractors Should Do (bpm.com)