CMMC FIPS Requirements: Why FIPS-Validated Cryptography Should Not Be Required

A defense contractor can use modern, strong encryption and still discover that the technology protecting its Controlled Unclassified Information (CUI) does not satisfy the current CMMC requirement. The problem may not be the encryption algorithm itself. It may be the validation status of the cryptographic module implementing it.

That distinction matters.

FIPS validation is more than turning on encryption or choosing AES-256. It is part of a formal testing and validation system involving technology vendors, accredited laboratories, specific module versions and configurations, and the National Institute of Standards and Technology's Cryptographic Module Validation Program.

That system provides real assurance. I am not arguing that cryptographic assurance is unnecessary, and I am certainly not arguing that CUI should be protected with weaker encryption.

My concern is narrower: I don't believe mandatory FIPS module validation should remain the required mechanism for demonstrating acceptable cryptographic protection under CMMC.

For small and midsize defense contractors in particular, the requirement can affect product selection, system architecture, patching, implementation effort and assessment evidence. Those costs deserve to be weighed against the additional assurance the validation requirement provides.

Important: This is a policy position, not today's compliance rule. Contractors subject to the current requirement still need to meet it while it remains applicable.

What Does CMMC Require for FIPS-Validated Cryptography Today?

The current CMMC Level 2 Assessment Guide includes security requirement SC.L2-3.13.11 — CUI Encryption, requiring organizations to employ FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI.

The assessment objective asks whether FIPS-validated cryptography is being employed for that purpose. The guide also identifies evidence assessors may examine, including cryptographic-module validation certificates, lists of FIPS-validated modules, system configurations, design documentation, audit records and the System Security Plan.

SecureITSM's own reference guide to NIST SP 800-171 controls and assessment objectives provides the broader control context.

An equally important qualification appears in the wording of 3.13.11 itself: this is about FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI.

That does not justify the common shortcut that “everything in a CMMC environment has to be FIPS validated.” The correct question is what cryptography is being relied upon to protect CUI and whether that implementation satisfies the applicable requirement.

That distinction is especially important before replacing firewalls, VPN products, operating systems or other infrastructure solely because someone has applied the FIPS requirement too broadly.

FIPS Compliant vs. FIPS Validated: Why the Difference Matters

One of the most common sources of confusion is treating a strong cryptographic algorithm as the same thing as a validated cryptographic implementation.

They are not the same.

A product can implement an approved algorithm and still not meet the FIPS validation requirement. NIST explains through its validated cryptographic modules guidance that implementing an approved security function or obtaining algorithm-validation certificates does not, by itself, make a cryptographic module FIPS 140 validated.

The current CMMC Level 2 Assessment Guide makes the same distinction. Simply using an approved algorithm is insufficient; the software or hardware module implementing that algorithm must itself have the required validation.

NIST manages module validation through the Cryptographic Module Validation Program (CMVP). Vendors use independent accredited Cryptographic and Security Testing Laboratories to test their modules, after which validation material is reviewed through the CMVP process.

That provides greater implementation assurance than merely saying, “We're using AES.” But it also creates the additional process and lifecycle issues at the heart of this debate.

FIPS Validation Is More Than an Encryption Setting

It is easy to think about FIPS as a technical setting inside a firewall, operating system or application. In practice, the validation ecosystem is much larger.

A vendor develops a cryptographic module. An accredited laboratory evaluates the module against the applicable FIPS requirements. The results are submitted through the validation process. NIST reviews the submission, applicable fees are collected, and the module can ultimately receive a validation certificate.

That certificate applies to a specific validated implementation—not automatically to every future version of the product containing it.

NIST's CMVP frequently asked questions also explain that a product can incorporate an already validated module without the entire product itself becoming a validated cryptographic module, as long as the validated module is not altered. NIST also cautions that correct use of the embedded module is outside the scope of the module validation itself.

This is why the simple advice to “buy something with FIPS” is often incomplete.

Contractors need to understand:

• which cryptographic module they are relying on;
• which version and operational environment were validated;
• whether the vendor's security policy imposes specific configuration conditions;
• whether the deployed implementation corresponds to that validation; and
• what evidence will demonstrate that relationship during an assessment.

That is much more than checking a box.

The Real Cost of FIPS Is Bigger Than a License Fee

When people say FIPS is expensive, it is important to be precise about who is paying for what.

Most defense contractors are not submitting their own cryptographic modules to NIST. Technology vendors typically bear the direct cost of validating modules used inside their products.

But those validation costs are real.

NIST's current 2026 CMVP cost-recovery fee schedule lists a full FIPS 140-3 submission at $16,000 for Security Level 1, $17,000 for Level 2, $17,500 for Level 3 and $19,000 for Level 4, before potential extended cost-recovery fees. These are NIST's review fees—not the total cost of building, testing and validating a product.

NIST also states that accredited cryptographic testing laboratories and NIST each charge fees for their respective portions of the validation effort. Laboratory fees are determined separately by the testing laboratories.

A contractor generally does not receive an invoice for those validation costs. The downstream burden shows up differently.

It can appear through narrower product choices, special government or validated configurations, engineering time required to confirm validation status, architecture changes, additional assessment evidence, delays in adopting newer versions and, in some cases, replacing otherwise functional technology.

That is why I consider FIPS fundamentally a cost and technology-choice issue, not simply a line item on a licensing quote.

SecureITSM has discussed the same broader dynamic in our analysis of why CMMC assessments are so difficult and expensive. The cost of CMMC rarely comes from one control alone. It comes from the cumulative architecture, tooling, documentation, engineering and evidence requirements needed to satisfy the program.

Validation Can Become a Technology Lifecycle Problem

Cybersecurity technology changes quickly.

Vulnerabilities are discovered. Operating systems are updated. Vendors patch cryptographic libraries. Firmware changes. Products reach end of support.

A formal validation process follows a different lifecycle.

The CMMC regulation itself recognizes that those two timelines can collide. The definition of a temporary deficiency in 32 CFR § 170.5 gives the specific example of FIPS-validated cryptography that requires a patch where the patched version is no longer the validated version.

That does not mean FIPS prevents patching.

It means there can be situations in which doing the right operational-security thing—moving to a patched version—changes the exact implementation that had the validation status your compliance evidence relied upon.

That is not merely theoretical compliance trivia. It creates a real lifecycle-management problem: Do you stay with an older validated implementation, move to the security update, document the resulting temporary deficiency, or wait for the vendor's updated validation?

A well-run security program should favor rapid vulnerability remediation. Any compliance mechanism that can create tension with that objective deserves periodic review.

DoD Has Already Acknowledged Validation Timing Problems

Industry concerns about FIPS validation did not begin with CMMC implementation in 2026.

During CMMC rulemaking, commenters raised concerns about FIPS, including requests involving POA&M treatment, waivers and alternatives to strict validation.

DoD did not remove the requirement. But in its response, the Department explicitly acknowledged that FIPS module validation can exceed the 180-day CMMC assessment POA&M threshold. The Department still declined to change the underlying requirement, explaining that limitations in the validation process did not alter the implementation status of the FIPS requirement.

The relevant discussion is available in the CMMC final rule published in the Federal Register.

That distinction is important.

The current requirement remains the current requirement.

But when the agency administering the cybersecurity framework acknowledges that the technology-validation process can take longer than the framework's remediation window, I think it is reasonable to ask whether the compliance mechanism is keeping pace with the technology it governs.

The Cryptographic Validation Community Is Also Focused on Time, Effort and Cost

Concerns about validation burden are not unique to defense contractors.

The Cryptographic Module User Forum (CMUF) exists as a forum for cryptographic-module developers, vendors, laboratories, users, policymakers and other participants in the validation ecosystem. One of CMUF's stated objectives is specifically to assess the validation process from the perspective of the time, effort and cost required to complete validations and certifications while still achieving appropriate levels of security.

NIST itself links to CMUF for Requests for Guidance and CMVP resolutions. NIST's current FIPS 140-3 Implementation Guidance and Request for Guidance page shows that implementation guidance continues to be actively maintained.

That active stream of guidance is another reminder that cryptographic-module validation is not a static certification stamp. It is a living technical program that has to evolve alongside modern hardware, software and cryptography.

Contractors Are Running Into the Complexity in Real Environments

Practitioner discussions are not regulatory authority, but they are useful for seeing what implementation problems organizations are actually encountering.

Recent discussions in the CMMC community have included questions from organizations whose existing firewall designs became problematic when FIPS mode was enabled. One r/CMMC discussion about a FIPS-mode firewall architecture problem described a production network where turning on the vendor's FIPS mode required zeroizing the firewalls and would affect the network's existing architecture. The organization was trying to understand whether manually restricting cryptographic settings could satisfy the requirement instead.

Another discussion about FIPS-validated firewall and endpoint VPN options included practitioners discussing FIPS-mode restrictions, performance implications and specific configuration dependencies. These are practitioner experiences, not official determinations, but they demonstrate the kind of operational questions contractors are having to solve.

Even a later r/CMMC discussion about FIPS 140-3 certificates showed continuing confusion about whether a defense contractor needs to obtain its own validation certificate or instead deploy products that use appropriately validated cryptographic modules.

For most contractors purchasing commercial technology, the goal is not to become a cryptographic-module vendor and obtain their own FIPS certificate. The goal is to identify the cryptographic implementation actually protecting CUI and verify that it satisfies the applicable requirement.

Those are very different tasks.

There Is a Strong Argument for Keeping FIPS Validation

A fair argument against mandatory FIPS validation has to acknowledge why validation exists in the first place.

Choosing a strong algorithm does not guarantee that software implements that algorithm securely.

Cryptographic weaknesses can arise from implementation errors, key handling, entropy generation, operational modes, interfaces or other parts of the cryptographic module.

Formal validation therefore provides something meaningful: independent testing against defined functional and assurance requirements.

NIST's CMVP program guidance explains that accredited laboratories test cryptographic modules and validation authorities review the results. Applicable approved algorithms also complete cryptographic algorithm validation before the module proceeds through CMVP validation.

So my argument is not: “AES is strong, therefore validation is useless.”

That would be far too simplistic.

The better question is: Does every applicable CMMC implementation need full FIPS module validation as the mandatory assurance mechanism, or can the government define strong cryptographic requirements that preserve security assurance without creating the same validation dependency?

That is the policy question I believe deserves reconsideration.

NIST SP 800-171 Rev. 3 Has Already Changed the Approach

There is another reason this conversation matters now.

NIST changed requirement 03.13.11 in NIST SP 800-171 Rev. 3.

Rather than directly requiring FIPS-validated cryptography in the requirement itself, Rev. 3 says organizations should implement specified organization-defined types of cryptography when protecting the confidentiality of CUI.

Then, in the accompanying discussion, NIST states that FIPS-validated cryptography is recommended for protecting CUI.

This is a meaningful change in approach.

It recognizes that a security requirement can define the cryptographic protection expected without necessarily hard-coding FIPS validation into the normative requirement itself.

But there is an equally important warning for defense contractors: NIST publishing Rev. 3 did not automatically replace the current CMMC Level 2 baseline.

As of August 31, 2026, the Department's official CMMC program information states that current Phase I Level 2 self-assessment activity continues against the 110 NIST SP 800-171 Rev. 2 requirements. Contractors should therefore treat Rev. 3 as an important direction of travel—not as permission to disregard today's applicable Rev. 2 requirement.

The FIPS 140-2 to FIPS 140-3 Transition Shows Why Lifecycle Matters

The timing of this debate is particularly relevant in 2026.

NIST's FIPS 140-3 transition guidance says that on September 22, 2026, all remaining FIPS 140-2 validation certificates are placed on the Historical List. After that date, active module validations will be FIPS 140-3 validations.

Moving a certificate to the Historical List does not mean every existing deployment suddenly becomes insecure. But it does affect how organizations evaluate new systems and procurements, and it reinforces the importance of understanding which specific module and version an implementation relies upon.

Practitioners are already discussing how to manage new deployments during the transition, including products whose older validation is approaching historical status while successor validations remain in process. Those discussions do not decide compliance, but they illustrate the same operational problem: security technology moves continuously, while formal validation has its own schedule.

Why This Burden Hits Small Defense Contractors Hardest

A large defense enterprise can absorb another architecture review, specialist engineering project or product migration more easily than a 25- or 50-person contractor.

For a small contractor, the cost of FIPS rarely arrives as a single invoice labeled “FIPS compliance.”

It appears in the hours an engineer spends researching CMVP certificates. It appears when a preferred firewall or VPN product must be configured differently. It appears when a newer product version does not yet align cleanly with the validation being relied upon. It appears when the organization has to gather certificates, screenshots, configuration evidence and SSP language for assessment. And it appears again when upgrades require someone to determine whether the evidence is still valid.

One decision may be manageable.

Across endpoints, operating systems, VPNs, firewalls, applications, cryptographic libraries and cloud services, the cumulative effect becomes significant.

This is part of the larger reason CMMC becomes expensive for small organizations. SecureITSM's guide on how to reduce CMMC Level 2 certification costs discusses why reducing unnecessary scope and avoiding unnecessary technology replacement are so important.

The goal should be to spend security dollars where they create the most security—not where complexity exists only because an implementation has to maintain a particular validation status.

What I Think CMMC Should Require Instead

I would keep the security objective and reconsider the mandatory validation mechanism.

CMMC should continue requiring organizations to protect CUI with strong cryptography.

The government should also continue requiring contractors to demonstrate that cryptographic protection is implemented correctly. A requirement without evidence is not much of a requirement.

Where I think the program can improve is in allowing a more risk-based and technologically flexible way of demonstrating that assurance.

A better model could focus on:

• approved, modern cryptographic algorithms and protocols;
• secure implementation and key management;
• documented configuration and operating conditions;
• evidence showing that cryptography actually protects the applicable CUI;
• timely vulnerability remediation and supported software versions;
• stronger validation requirements where the risk or use case justifies them; and
• organization-defined cryptographic requirements similar in concept to the flexibility introduced in NIST SP 800-171 Rev. 3.

That does not mean letting every contractor decide that whatever encryption they happen to use is good enough.

The alternative still needs objective technical requirements and assessable evidence.

My point is that FIPS module-validation status should not automatically be the deciding factor between acceptable and unacceptable cryptographic protection in every applicable CMMC implementation.

Security assurance matters.

But so do maintainability, vulnerability remediation, technology availability, implementation cost and the ability of small businesses to operate securely without unnecessary architectural constraints.

What Should Defense Contractors Do Today?

Until the requirement changes, contractors should build around the rule that exists—not the rule they hope will exist later.

Start with your CUI and architecture rather than starting with a shopping list of “CMMC-compliant” products.

A practical review should determine:

1. Where does CUI actually live? Identify the systems that process, store or transmit it.
2. Where is cryptography being relied upon to protect CUI confidentiality? Separate those use cases from unrelated uses of encryption elsewhere in the environment.
3. Which cryptographic module provides that protection? Identify the actual module rather than relying only on a product marketing claim.
4. What validation applies? Confirm the relevant FIPS certificate, module version, operational environment and security policy.
5. Is the technology configured consistently with that validation? A product having access to a validated module does not automatically prove your deployment is using it correctly.
6. Can you produce evidence? Preserve validation information, configuration records, design documentation and SSP language supporting the implementation.
7. What happens when the product changes? Revisit the evidence when operating systems, firmware, cryptographic modules or major configurations are updated.

That is a much safer approach than assuming every system needs FIPS or, at the opposite extreme, assuming strong encryption automatically meets 3.13.11.

Before replacing technology solely because of FIPS, make sure you understand exactly where the requirement applies and what mechanism is protecting the CUI.

If that is unclear, SecureITSM's AgileDefend Assessment service can help review the CUI boundary, NIST SP 800-171 implementation and assessment evidence before unnecessary infrastructure changes are made.

Conclusion

CUI should be protected with strong cryptography. I am not arguing otherwise.

FIPS validation also provides real assurance. Independent testing is more meaningful than simply trusting a vendor that says its product uses strong encryption.

What I question is whether mandatory FIPS module validation should remain the only acceptable assurance mechanism for applicable CMMC cryptography.

When the requirement restricts technology choices, creates lifecycle problems, adds engineering effort and increases the burden on small defense contractors, we should be willing to ask whether the same security objective can be achieved more efficiently.

NIST SP 800-171 Rev. 3 has already moved toward a more flexible cryptographic requirement.

I think CMMC should eventually do the same.

Until it does, contractors still need to satisfy the requirement that applies today.

Frequently Asked Questions 

1. Does CMMC require FIPS-validated cryptography?

Under the current CMMC Level 2 baseline, NIST SP 800-171 Rev. 2 requirement 3.13.11 requires FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI. The current CMMC Level 2 Assessment Guide retains that requirement.

2. Is AES-256 automatically FIPS validated?

No. An approved algorithm such as AES and a FIPS-validated cryptographic module are not the same thing. NIST's validated modules guidance explains that simply implementing an approved security function does not make a module FIPS validated.

3. Does every firewall in a CMMC environment have to be FIPS validated?

Not simply because the firewall exists inside a CMMC environment. The analysis depends on what security function the device performs and whether its cryptography is being relied upon to protect the confidentiality of CUI. Organizations should evaluate the actual CUI flow, architecture and applicable security requirement rather than applying “FIPS everywhere” as a blanket rule.

4. Does a defense contractor need its own FIPS 140-3 certificate?

Usually not if the contractor is simply purchasing and deploying commercial technology. Vendors that develop cryptographic modules generally take those modules through CMVP validation. Contractors typically need to identify and correctly deploy technology using the appropriately validated cryptographic implementation. NIST's CMVP FAQs explain the vendor, laboratory and validation process.

5. Did NIST SP 800-171 Rev. 3 remove the current CMMC FIPS requirement?

No. Rev. 3 changed requirement 03.13.11 to use organization-defined types of cryptography and recommends FIPS-validated cryptography in the accompanying discussion. But the current CMMC Level 2 baseline continues to use the 110 requirements of NIST SP 800-171 Rev. 2 until DoD formally changes the applicable framework.

Not Sure Where FIPS Validation Actually Applies in Your CUI Environment?

Before replacing firewalls, VPNs, endpoints or other technology, SecureITSM can help review your CUI boundary, cryptographic protections and NIST SP 800-171 evidence to identify what actually needs to change.

Review Your CMMC Environment With SecureITSM