FIPS 140-2 Sunsets Today. What is FIPS 140-3 and What Does This Mean for Post Quantum Cryptography (PQC)?

September 21, 2026, is the last day before NIST moves FIPS 140-2 certificates to its historical list. This is not a post-quantum cryptography (PQC) deadline. But for federal, state, local, and higher-education organizations refreshing technology or writing requirements, it is a timely prompt to strengthen their understanding of cryptography, cryptographic validation with FIPS 140-3, and the coming PQC transition. 

The transition raises practical questions: What is FIPS 140-3? What is a cryptographic module? What do the new PQC standards – FIPS 203, 204, and 205 – actually do? And when a vendor says a product is “PQC-capable” or “FIPS 140-3 validated,” what evidence should an agency request?

This tutorial answers those questions in plain English. The standards are related, but they are not the same thing – and confusing them can lead to unclear requirements and incomplete acquisition decisions. Post-quantum cryptography (PQC) is becoming a concrete federal modernization priority. For the larger policy context – the quantum threat, the “harvest now, decrypt later” risk, and the federal migration roadmap – see our blog: The Quantum Threat and the Federal Mandate for Post-Quantum Cryptography.  

Why the FIPS 140-2 transition is a reminder right time to ask 

The move of FIPS 140-2 certificates to NIST’s historical list on September 22 does not automatically invalidate deployed products or demand an overnight replacement. NIST notes that historical modules may still be purchased and used in existing systems. But it does make FIPS 140-3 the current validation framework and turns routine refresh, procurement, and modernization decisions into an opportunity to ask better questions. As agencies assess a product, they may hear that it is “FIPS 140-3 validated,” “PQC-capable,” or “FIPS 203 compatible.” Each phrase describes a different type of assurance. This guide starts with the new PQC standards, then explains the module-validation framework that may implement them.

FIPS 140-3 validation	PQC compatibility
Answers the question: Is this cryptographic module (i.e., the bounded, deployable implementation environment for a cryptographic algorithm) validated? The cryptographic algorithm could be a PQC cryptographic modules or could be a traditional (non-PQC) cryptographic module.	Answers the question: Does the cryptography use one of the NIST-standardized post-quantum cryptography algorithms? Or, can the product support the use of one of these PQC algorithms. NIST’s three finalized PQC standards are: FIPS 203: ML-KEM, for key establishment FIPS 204: ML-DSA, for digital signatures FIPS 205: SLH-DSA, for digital signatures

FIPS 203, 204, and 205 define PQC algorithms. FIPS 140-3 validates cryptographic modules that implement cryptography.

An implementation can support a standardized PQC algorithm without being part of a FIPS 140-3-validated module. A FIPS 140-3-validated module can also exist without supporting PQC. For a federal deployment that needs both current module assurance and PQC capability, agencies must verify both claims – separately and for the exact product version and configuration they plan to use.

A plain-English analogy: the recipe, the meal & the taste test, the kitchen, and the kitchen’s inspection 

Think of a cryptographic system as a professional kitchen.

• FIPS 203, 204, and 205 are recipes. They specify precisely how to prepare three new kinds of quantum-resistant cryptographic functions. Anyone claiming to use one of these recipes should follow its instructions exactly.
• An implementation of FIPS 203, 204, or 205 is the meal. It is the implementation of the cryptography defined by the standard.
• NIST’s Cryptographic Algorithm Validation Program (CAVP) tests the recipe implementation (“taste tests the meal”). The Cryptographic Algorithm Validation Program tests whether a particular implementation produces the expected results for the algorithm.
• FIPS 140-3 sets the kitchen’s security requirements. It is the defined hardware, software, firmware, or hybrid component where cryptographic work happens: generating keys, protecting keys, encrypting data, establishing secure connections, or creating and checking digital signatures. It has a defined boundary, approved functions, interfaces, operating conditions, and security controls.
• NIST’s Cryptographic Module Validation Program (CMVP) inspects and validates the kitchen. The Cryptographic Module Validation Program validates that the complete module meets FIPS 140 security requirements in its defined configuration – not only that one recipe works.

In this analogy, successfully preparing one recipe does not prove the kitchen is secure. And a kitchen that has passed its security inspection does not prove it has been equipped to prepare the new PQC recipes. A federal buyer that needs both should ask for proof of both.. 

The three PQC algorithms (ML-KEM, ML-DSA, and SLH-DSA) 

In 2024, NIST finalized the first three PQC Federal Information Processing Standards. They address two different cryptographic jobs: establishing a shared secret and creating digital signatures.

Algorithm (Standard)	Plain-English job	Typical places it appears
ML-KEM (FIPS 203)	Helps two parties establish a shared secret over an untrusted network	TLS, VPNs, secure application connections, key management
ML-DSA (FIPS 204)	Creates and verifies digital signatures	Code signing, documents, identities, certificates, signed API requests
SLH-DSA (FIPS 205)	Creates and verifies digital signatures using a hash-based design	Signature use cases needing a mathematically diverse option

 FIPS 203 / ML-KEM is a key-encapsulation mechanism (KEM). It helps endpoints establish the secret key that will protect a session or data exchange. It is not the same thing as bulk encryption; once a shared secret is established, symmetric algorithms are commonly used for the continuing encryption and authentication work.

FIPS 204 / ML-DSA is a general-purpose digital-signature standard. A signature provides evidence that data or software came from the expected signer and has not been changed.

FIPS 205 / SLH-DSA is also a digital-signature standard, but it uses a stateless hash-based approach rather than the lattice-based approach used by ML-DSA. That different mathematical foundation can be valuable for diversity, although signature size and performance tradeoffs can be significant.

What NIST’s Cryptographic Algorithm Validation Program (CAVP) Validates

The Cryptographic Algorithm Validation Program (CAVP) answers a focused question: does this specific implementation correctly perform an approved cryptographic algorithm?

For PQC, a vendor may implement ML-KEM according to FIPS 203, ML-DSA according to FIPS 204, or SLH-DSA according to FIPS 205. Through an accredited cryptographic testing laboratory, that implementation is tested using NIST’s Automated Cryptographic Validation Test System (ACVTS). The test system provides inputs; the implementation returns outputs; and the results are checked against the applicable NIST specification.

If the implementation passes, it receives an algorithm validation certificate. That certificate identifies details such as the vendor, implementation, operational environment, and validated algorithm capabilities.

In plain English: CAVP verifies that the the meal (i.e., the cryptography) was implemented correctly (i.e., it followed the recipe).

CAVP validation is an important prerequisite for FIPS 140 module validation, but it does not validate the product or cryptographic module as a whole. It does not, by itself, assess how the product protects keys, controls access, performs self-tests, manages interfaces, or operates securely in its intended environment. Those are among the broader requirements assessed through the Cryptographic Module Validation Program (CMVP) under FIPS 140-3.

What NIST’s Cryptographic Module Validation Program (CMVP) Validates

The Cryptographic Module Validation Program (CMVP) answers a broader question: does this defined cryptographic module meet the security requirements of FIPS 140-3?

A cryptographic module is the bounded hardware, software, firmware—or combination of them—that performs cryptographic functions and protects the keys and other sensitive values those functions use. It might be a software cryptographic library, a hardware security module, a network appliance, or a specifically defined component within a larger product.

CMVP validation evaluates much more than whether an algorithm produces the right answer. Under FIPS 140-3, the assessment addresses the module’s security boundary and interfaces, roles and authentication, key and sensitive-parameter management, self-tests, software or firmware security, operational environment, lifecycle assurance, and—in applicable modules—physical and other attack protections.

In plain English: CMVP evaluates whether the kitchen is designed and operated securely – not just whether the meal is correct.

A FIPS 140-3 validation applies to the specific module, version, operational environment, and configuration identified on its certificate. A product’s marketing claim that it is “FIPS compliant” is not a substitute for confirming the relevant module validation and its approved mode of operation. Likewise, a FIPS 140-3 validated module does not automatically mean it includes or has validated a PQC algorithm; agencies should verify both the module validation and the algorithm capabilities they need.

The comparison agencies should use

Question	FIPS 203 / 204 / 205 compatibility	CAVP algorithm validation	FIPS 140-3 / CMVP validation
What is being evaluated?	Product capability to support a PQC algorithm	A specific algorithm implementation	A defined cryptographic module
What does it tell an agency?	The product may be able to use ML-KEM, ML-DSA, or SLH-DSA	The implementation passed algorithm testing	The module met FIPS 140-3 security requirements in its validated configuration
Does it prove the whole product is FIPS validated?	No	No	No; it validates the module, not necessarily every product feature
Does it prove PQC support?	Yes, if the claim is specific and substantiated	Yes, for the validated algorithm implementation	Only if the certificate and security policy show that PQC capability is included in the validated module and approved mode
What proof should a buyer request?	Version-specific feature documentation and interoperability evidence	CAVP validation reference and matching implementation/version	CMVP certificate number, security policy, approved mode, operating environment, and product-to-module integration statement

A practical acquisition checklist

When evaluating a PQC offering, agencies should ask vendors to provide:

1. The exact FIPS 203, 204, and/or 205 capabilities, including parameter sets and supported protocols.
2. The product version, software/firmware build, hardware platform, and configuration in which those capabilities are available.
3. Any applicable CAVP algorithm-validation references – and confirmation that they apply to the offered implementation.
4. The active FIPS 140-3 CMVP certificate number for the cryptographic module, its security policy, and the approved operational mode.
5. A statement showing how the offered product incorporates and uses the validated module for all required cryptographic services.
6. A PQC migration roadmap covering hybrid support, interoperability, performance testing, key and certificate lifecycle changes, and future algorithm agility.

The most reliable answer is not a marketing phrase such as “PQC-ready” or “FIPS compliant.” It is a set of evidence that connects the algorithm, implementation, module, product version, and deployment configuration.

The bottom line

FIPS 140-2’s sunset is not a PQC deadline. It is, however, a timely reminder that agencies should sharpen their understanding of both cryptographic module security and the transition to post-quantum cryptography.

FIPS 203, FIPS 204, and FIPS 205 define the NIST-standardized PQC algorithms a product may implement. CAVP can provide evidence that a specific implementation of those algorithms was tested and produces results that match the standard. FIPS 140-3 and CMVP provide assurance that the defined cryptographic module containing that implementation was validated against current federal module-security requirements.

These are complementary (not interchangeable) assurances. As agencies prepare for PQC, they should evaluate both and ask vendors to document precisely where the claims meet: which PQC algorithms are implemented, whether those implementations have CAVP validation, and whether the relevant cryptographic module has a current FIPS 140-3 validation.

FRC can help public-sector organizations turn these distinctions into practical requirements, assess vendor evidence, and build acquisition and migration plans that align with mission needs.