FIPS 140-2 Is Now Historical: What Changes
September 21, 2026 was the final day that US and Canadian federal agencies could accept Active FIPS 140-2 modules for new systems. On September 22, the Cryptographic Module Validation Program (CMVP) moved the remaining FIPS 140-2 validations to the Historical list. Only FIPS 140-3 module validations now remain Active.
That change matters for procurement and system design, but it does not invalidate every deployed FIPS 140-2 module overnight. Historical is not the same as Revoked. Existing systems can continue using Historical modules when the responsible agency makes the appropriate risk determination. New systems should select an Active FIPS 140-3 validation.
The transition is also separate from post-quantum cryptography. It does not require ML-KEM or ML-DSA, and a product that implements a NIST post-quantum algorithm is not automatically a FIPS 140-3 validated module.
What changed on September 22, 2026
The CMVP transition schedule sets out the boundary:
- Through September 21, 2026: Active FIPS 140-2 modules could still be accepted for new and existing federal systems.
- From September 22, 2026: only FIPS 140-3 validations remain on the Active list.
- FIPS 140-2 certificates: moved to the Historical list and can be considered for existing systems only.
FIPS 140-3 superseded FIPS 140-2 in 2019. CMVP began accepting FIPS 140-3 submissions in 2020 and stopped accepting FIPS 140-2 submissions for new validation certificates in 2022. The September 2026 date completes the procurement-side transition; it is not the publication date of FIPS 140-3.
Active, Historical and Revoked are different
| CMVP status | What it means | New systems | Existing systems |
|---|---|---|---|
| Active | The module has a current validation under the standard and conditions shown on its CMVP entry | Eligible, subject to the certificate scope and buyer requirements | Eligible |
| Historical | The validation is old or was moved because of a programmatic transition; it has not necessarily been revoked | Do not select for a new system | May continue after an agency risk determination |
| Revoked | The validation is no longer valid and cannot be cited to demonstrate FIPS 140 conformance | No | No |
The CMVP FAQ warns that documentation attached to a Historical certificate may not reflect the latest guidance or how the module should operate in approved mode. Historical status is therefore not a general recommendation to keep deploying the module. It is a controlled path for maintaining an existing system while planning its replacement.
CMVP also states that Historical modules can be procured for legacy systems. That is narrower than buying the same module for a new platform, new application or materially redesigned architecture. Record why the purchase belongs to an existing-system context and obtain the required agency or contract approval.
What counts as an existing system
CMVP provides the validation status and the broad new-versus-existing-system rule. The acquiring organization still has to classify its actual change.
A routine replacement part, supported patch or like-for-like maintenance activity may fit an existing-system decision. A new service, major re-platforming, new appliance generation or expansion into a new security boundary may be treated as a new system by the relevant authority.
Do not turn “existing systems only” into a self-approved exception. Record:
- the system and authorization boundary;
- the module certificate and exact version;
- why the activity is maintenance rather than a new deployment;
- the business and security risk of continued use;
- the FIPS 140-3 replacement plan;
- the approving authority and review date.
Agency policy, acquisition language, FedRAMP requirements, customer contracts or sector rules can be stricter than the baseline CMVP transition language.
Validation attaches to an exact module boundary
A certificate does not validate a vendor, product family or algorithm in the abstract. It applies to the module identified in the CMVP record and security policy, including relevant software or firmware versions, hardware, tested operational environments, approved services and mode of operation.
Before relying on a certificate, verify:
- the certificate number and current status in the validated modules database;
- the exact module and version used by the product;
- the tested or permitted operational environment;
- the approved mode and required configuration;
- the approved algorithms and services actually used;
- any caveats, dependencies and sunset date.
A product may embed a validated library or hardware module. That does not make the whole surrounding product validated. NIST permits language such as “FIPS 140-3 Inside” when the product incorporates a validated module, but CMVP does not assure that the product calls or configures that module correctly.
For the same reason, prefer FIPS 140-3 validated module with a certificate number over a vague claim that a product is “FIPS compliant.” CMVP uses validated for a module that completed accredited testing and received a certificate. Compliant can describe a vendor’s belief about an implementation that has not completed CMVP validation.
How FIPS 140-3 differs from PQC standards
Four related concepts are often collapsed into one claim:
1. FIPS 203, 204 and 205 define algorithms
- FIPS 203 specifies ML-KEM for key encapsulation.
- FIPS 204 specifies ML-DSA for digital signatures.
- FIPS 205 specifies SLH-DSA for stateless hash-based signatures.
These publications standardize the algorithms. They do not issue a module validation to every implementation.
2. CAVP tests algorithm implementations
The Cryptographic Algorithm Validation Program tests whether a particular implementation conforms to an approved algorithm specification. CMVP requires appropriate algorithm validation before an approved algorithm can be included in a module submission.
A CAVP algorithm certificate is necessary evidence, but it is not a substitute for FIPS 140-3 module validation.
3. FIPS 140-3 and CMVP validate modules
CMVP evaluates the defined module boundary, approved services, self-tests, key and sensitive-parameter handling, interfaces, lifecycle controls and other requirements. The security policy determines which algorithms are approved within that module and which operations cause it to leave approved mode.
An Active FIPS 140-3 module can therefore exist without PQC in its approved boundary. Conversely, a library can expose ML-KEM or ML-DSA while those services remain non-approved under its current certificate.
4. CNSA 2.0 is an NSA profile
CNSA 2.0 selects algorithms and migration expectations for US national security systems. It is not a CMVP certificate, and support for its named algorithms does not automatically establish component-level or system-level compliance.
The September 22 transition changes the Active/Historical status of module validations. It does not itself mandate PQC, approve ML-KEM or ML-DSA in a particular product, or establish CNSA 2.0 compliance.
A practical PQC validation example
Suppose a library release implements ML-KEM and also embeds a module with an Active FIPS 140-3 certificate. Procurement still needs to check whether that exact certificate lists ML-KEM as an approved algorithm and whether the deployed operation runs inside the approved module boundary.
Three different answers are possible:
- Validated PQC operation: the exact module certificate and security policy include the required ML-KEM service in approved mode.
- Validated classical module plus non-approved PQC: the module has an Active FIPS 140-3 certificate, but invoking its PQC implementation leaves approved mode.
- PQC implementation without module validation: the algorithm may conform to FIPS 203 or pass CAVP testing, but no applicable Active module certificate exists.
The PQC library comparison matrix tracks these distinctions for common software libraries. Use the PQC vendor support matrix for capability discovery, then request certificate-level evidence rather than treating a product-level PQC badge as validation.
Procurement checklist
Before approving a cryptographic product or renewal, capture:
- Exact product, embedded module and module version
- CMVP certificate number and current status
- FIPS 140-3 rather than Historical FIPS 140-2 for a new system
- Certificate sunset date and any Interim Validation caveat
- Tested or permitted operational environment
- Required approved-mode configuration
- Approved algorithms and services used by the application
- PQC algorithms inside the approved boundary, if PQC is required
- Written evidence when the product embeds another vendor’s module
- New-system or existing-system classification
- Legacy-system risk acceptance and replacement date, where applicable
- Stricter agency, contract or customer requirements
Add these fields to the cryptographic inventory and keep a copy of the certificate entry, security policy and vendor mapping used for the decision. Validation status changes over time, so treat it as maintained evidence rather than a one-time checkbox.
What migration teams should do now
For new systems, specify an Active FIPS 140-3 module and verify the exact approved services required by the design. For existing systems using a now-Historical FIPS 140-2 module, document the risk decision and replacement path rather than assuming indefinite acceptance.
For PQC migration, maintain a separate capability record. Track the algorithm standard, implementation version, CAVP evidence, CMVP module certificate and approved-mode scope independently. The PQC migration checklist can then treat module replacement and algorithm migration as related workstreams without pretending they are the same control.