If you're pursuing CMMC certification, you've probably run into FIPS 140-3 in a control description and wondered how deep you actually need to go. This guide walks through what FIPS 140-3 is, how it differs from FIPS 140-2, and what it means for defense contractors working toward CMMC Level 2 compliance.

What is FIPS 140-3?

FIPS stands for Federal Information Processing Standards. 140-3 is the current U.S. and Canadian government standard for cryptographic modules: the hardware, software, or firmware components that perform encryption, decryption, key generation, and other cryptographic functions. The National Institute of Standards and Technology (NIST) publishes the standard, and the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security, tests and validates modules against it.

Essentially, FIPS 140-3 sets the standard, and CMVP is the process that checks whether a given product meets it. Pass, and you get a numbered certificate and a spot on the public CMVP Validated Modules Search page.

FIPS 140-3 went into effect in September 2019, and CMVP stopped accepting new submissions under the previous standard, FIPS 140-2, in 2022. NIST has set a Historical List transition date in September 2026, after which all remaining FIPS 140-2 certificates move to historical status. 

Why FIPS 140-3 exists

FIPS 140-2 was published in 2001. Cryptographic standards, attack techniques, and global testing practices changed substantially over the two decades that followed, and FIPS 140-2 became harder to reconcile with modern hardware, software, and threat models. 

FIPS 140-3 is essentially a rewrite of 140-2 around an international standard (ISO/IEC 19790:2012, along with the associated testing methodology in ISO/IEC 24759) instead of a U.S.-only framework. That shift makes validated modules portable across government and regulated markets globally, and it modernizes how the standard handles things like non-invasive attack mitigation, software and firmware security, and the lifecycle of a cryptographic module over time.

FIPS 140-3 levels

Like its predecessor, FIPS 140-3 defines four security levels that describe how rigorous a module's physical security, key management, authentication, and tamper resistance need to be. 

• Level 1: Requires at least one approved algorithm or security function, but imposes no specific physical security mechanisms beyond production-grade components. This is the level most commercial software-based cryptographic modules target.
• Level 2: Adds requirements for tamper-evidence (such as tamper-evident coatings or seals) and role-based authentication, where the module verifies the role of an operator before granting access to certain operations.
• Level 3: Requires tamper-detection and response mechanisms, not just evidence after the fact, identity-based authentication, and physical or logical separation between interfaces that handle sensitive security parameters (like keys) and those that don't. This is the level typically associated with hardware security modules (HSMs) and similar dedicated cryptographic hardware.
• Level 4: The highest level. Requires a complete envelope of protection that can detect and respond to physical penetration attempts from any direction, along with protection against environmental attacks like extreme voltage or temperature manipulation intended to compromise the module.

If you’re evaluating vendors, it’s important to note that a module's certificate specifies the level it achieved, and different aspects of the same module can be validated at different levels. Check the actual CMVP certificate rather than taking a vendor's "FIPS 140-3 Level X compliant" claim at face value.

FIPS 140-2 vs FIPS 140-3: What changed?

The core difference is the underlying framework: FIPS 140-2 was a homegrown NIST standard, while FIPS 140-3 adopts the international ISO/IEC 19790 and 24759 standards as its foundation. From there, a handful of practical differences matter if you're evaluating products or planning a migration:

• Stricter testing and longer validation timelines. FIPS 140-3 validation involves more rigorous documentation and lab procedures, which makes validation timelines significantly longer than 140-2. Current 140-3 timelines average 1.5 - 2 years for full certification.
• New ground on non-invasive attacks. FIPS 140-3 added explicit requirements for non-invasive attacks like power analysis and electromagnetic emission analysis, areas 140-2 didn't fully address.
• Tighter software and firmware load requirements. FIPS 140-3 is more strict about how software and firmware get loaded into a validated module and how that process gets authenticated.
• More structured lifecycle requirements. FIPS 140-3 gives vendors a clearer framework for managing updates to a module over time, including which changes do and don't trigger a full revalidation.
• Algorithms move independently of the standard. Approved algorithms (AES, SHA-2, RSA at certain key lengths, and so on) aren't locked permanently to either standard. NIST periodically retires older algorithms and adds new ones, including post-quantum algorithms like FIPS 203, 204, and 205. So a module's approved algorithm list depends on when it was submitted and validated, not simply on whether it's a 140-2 or 140-3 certificate.

FIPS 140-2 Level 3 vs FIPS 140-3

This question comes up a lot with contractors who already have FIPS 140-2 Level 3 hardware in place and want to know if that’s sufficient. 

If you're weighing FIPS 140-2 Level 3 against its FIPS 140-3 counterpart, the underlying requirements at that tier (tamper detection and response, identity-based authentication, separation of sensitive interfaces) carry over. What changes is the testing methodology behind them, and in some cases, the algorithms a module can use going forward. 

Don't assume equivalence just because the level number matches. A product validated at FIPS 140-2 Level 3 needs its own FIPS 140-3 Level 3 certificate, and one doesn't automatically transfer to the other.

The FIPS 140-3 compliant list

There's no single master "FIPS 140-3 compliant" list you can bookmark and trust forever. The most authoritative source is the CMVP Validated Modules Search page, which lists every module that has received a FIPS 140-3 certificate, along with the vendor, module name, validation level, and approved algorithm scope. 

Because certificates get added and moved to historical status on an ongoing basis, you should always check the current CMVP database yourself rather than relying on a "compliant list" published elsewhere.

Why FIPS 140-3 matters for CMMC compliance

CMMC inherits encryption requirements from NIST SP 800-171, which CMMC Level 2 is built on. Several controls within NIST 800-171, particularly within the System and Communications Protection (SC) family, require that cryptography used to protect the confidentiality of Controlled Unclassified Information (CUI) be FIPS-validated.

That means if your organization handles CUI and encrypts it at rest or in transit, the cryptographic modules doing that work need an active CMVP validation. Using the right algorithms isn't enough if nobody's validated the module doing the work.

This is the distinction between "FIPS compliant" and "FIPS validated" that can trip up a lot of contractors. “Compliant” generally means a vendor believes their implementation follows FIPS-approved algorithms without going through formal CMVP testing, while “validated” means the module passed independent lab testing and holds a certificate. CMMC assessors and contract requirements generally expect validation, not a vendor's self-assessment of their compliance.

The FIPS 140-2 sunset adds a tangible deadline to this. Once those certificates move to historical status, federal guidance says agencies shouldn't rely on them for new procurements or deployments. So if you're building or refreshing any system that will touch CUI, what you acquire going forward should carry an active FIPS 140-3 certificate, not a 140-2 certificate that's nearing or past its sunset. Systems already running validated FIPS 140-2 modules will generally keep functioning, but the certificate itself loses standing for new acquisitions and may draw extra scrutiny during a C3PAO assessment.

How to meet FIPS encryption requirements for CMMC

Meeting these requirements can feel like a lot once you start digging into modules and certificates, especially when you’re elbow-deep in control requirements and implementation statements. 

Follow these concrete steps to make meeting CMMC encryption requirements more manageable: 

1. Find where CUI is encrypted. Map every system, application, and storage location where CUI is encrypted at rest or in transit. You can't validate what you haven't inventoried first.

2. Identify the actual cryptographic module behind each one. This is the step people skip most often. Saying "we use AES-256" doesn't tell you whether the module behind it is FIPS validated. Pin down the specific library, OS-level crypto provider, or hardware module doing the work: OpenSSL's FIPS provider, a particular HSM model, your cloud provider's FIPS-enabled endpoints, whatever it is in your stack.

3. Check each module on the CMVP Validated Modules Search page. Confirm the certificate is active, not historical, and that it actually covers the algorithms and modes you're using.

4. Flag anything riding on a FIPS 140-2 certificate near sunset. Build a remediation timeline now for replacing or upgrading these. Vendor validation lead times can run well over a year, so this isn't something to start the month before an assessment.

5. Turn FIPS mode on, don't just buy FIPS-capable products. A lot of products ship with FIPS mode available but switched off by default. Confirm it's actually enabled in your deployed configuration; FIPS-capable software running outside FIPS mode doesn't satisfy CMMC requirements.

6. Document everything. Your System Security Plan (SSP) should name which modules protect CUI, their certificate numbers, and their validation status. This is exactly what a C3PAO will ask for during a CMMC Level 2 assessment.

What this means for your CMMC assessment

FIPS 140-3 isn't a separate hoop to jump through alongside CMMC. It's the mechanism that satisfies the encryption requirements already baked into NIST SP 800-171, and by extension, CMMC Level 2. The real work is identifying which cryptographic modules protect your CUI, confirming their CMVP validation status, and building a plan now for any FIPS 140-2 modules that will lose standing once they move to historical status.

That said, FIPS validation is one piece of a much larger compliance puzzle, and most contractors find that out the hard way: somewhere between mapping SC family controls, writing an SSP, and figuring out what a C3PAO wants to see in an assessment. You don't have to work through all of it alone. Secureframe's team includes CMMC Registered Practitioners (RPs) and federal compliance experts who help contractors navigate exactly this kind of control-by-control detail.

To get started, download our free CMMC Compliance Kit. It includes a CMMC fundamentals ebook, customizable documentation templates, compliance checklists, and ready-to-use SSP, POA&M, Risk Mitigation Plan, and Incident Response Plan templates, everything you need to get your documentation in shape before an assessor asks for it.