The FIPS 140-2 Sunset in September 2026: What Procurement and Vendors Need to Check Now

The CMVP moves every active FIPS 140-2 certificate to the historical list on 21 September 2026. After that date, FIPS 140-3 is the only active cryptographic module standard at NIST and CCCS. The date is not new. It was set in 2021 when CMVP stopped accepting new FIPS 140-2 submissions, and the five-year sunset window for existing 140-2 certificates was published at the same time.

What is new, as the date approaches, is how visible the gap has become. A meaningful share of FIPS 140-2 certificates on the active list today belong to modules whose vendors have not yet submitted a FIPS 140-3 successor, or have submitted one that is still sitting in the CMVP review queue. The procurement-side consequence is concrete: an RFP issued in late 2026 that calls for “a FIPS 140 validated module” needs to make a choice about how to handle a market where some vendors have a clean 140-3 certificate, some have only a historical 140-2 certificate, and some are in the queue between the two.

This post walks through what changes on the sunset date, the language to write into procurement specs ahead of it, and the lead times vendors and buyers should plan against. It is intentionally focused on the cryptographic module side. If you also need the broader picture of how Common Criteria and FIPS relate, start with Common Criteria vs FIPS 140-3.

The CMVP timeline in one place

The Cryptographic Module Validation Program (CMVP), run jointly by NIST and CCCS, has used the same lifecycle structure for FIPS 140-2 since the standard was published in 2001. The transition to FIPS 140-3 follows a defined path:

1. 22 September 2020: FIPS 140-3 takes effect. CMVP begins accepting FIPS 140-3 submissions in parallel with 140-2.
2. 22 September 2021: CMVP stops accepting new FIPS 140-2 submissions. From this date forward, every new validation must be against FIPS 140-3, which aligns with ISO/IEC 19790:2012 and ISO/IEC 24759:2017.
3. 21 September 2026: All remaining FIPS 140-2 certificates that are still on the active list are moved to the historical list. This is the sunset date this post is about.
4. After 21 September 2026: FIPS 140-3 is the only standard on the active list. FIPS 140-2 records remain publicly readable under “Historical”.

The framing on CMVP’s site distinguishes three states for any module certificate. Active means the certificate is current and the module is treated as compliant for federal procurement that references FIPS 140. Historical means the certificate is still valid as a public record but is no longer recognised as compliant for new procurement against current federal requirements. Revoked is a separate state used when CMVP withdraws a certificate for cause, and is rare.

The September 2026 move is not a revocation. The certificates are not deleted. The lookup at csrc.nist.gov will still resolve them. What changes is the bucket they appear in, and how federal regulations and procurement policies treat that bucket.

Active, historical, revoked: what each means for procurement

The three lifecycle states map directly onto procurement decisions, and the mapping is worth being precise about.

Active certificates are the only ones that satisfy a federal procurement requirement of the form “the product must be FIPS 140 validated” at time of award. NIST publishes the active list as the authoritative source. After 21 September 2026, every certificate on this list will be a FIPS 140-3 certificate.

Historical certificates record a validation that was once active. For federal procurement purposes, the position published by NIST and reinforced by CISA and OMB guidance is that historical certificates do not satisfy new requirements that call for FIPS validation. The certificate still exists, the validation record is still public, and the vendor can still cite the certificate number, but a procurement that requires an active validation will read the historical bucket as non-compliant.

This is the point where the language used in older RFPs starts to break. “FIPS 140 validated” without further qualification was a workable shorthand when active and historical were rarely distinguished, because most agencies dealt with currently-active certificates. After September 2026, every FIPS 140-2 certificate that has not been re-validated to 140-3 will be in the historical bucket, and “FIPS 140 validated” no longer specifies which bucket the procurement will accept.

Revoked certificates are an unrelated case. CMVP revokes a certificate when it finds, post-validation, that the module does not meet the standard or that the vendor cannot maintain the documented configuration. Revocation is rare and is not what is happening to FIPS 140-2 in September 2026.

The practical takeaway: a procurement spec that wants to be unambiguous needs to name the standard version and the lifecycle state at time of award, not just the program name.

What RFP language should change

A procurement clause that worked in 2024 is unlikely to age well past 21 September 2026 without revision. Three patterns to update.

Replace “FIPS 140 validated” with “FIPS 140-3 validated on the CMVP active list at time of award”. The phrase has to do two things: pin the standard version (since 140-2 is moving to historical on the sunset date) and pin the lifecycle state (since both 140-2 and 140-3 records sit on the same CMVP site, distinguished only by their active or historical bucket). Both qualifications are needed. A spec that says only “FIPS 140-3 validated” will, in edge cases, accept a 140-3 certificate that has itself moved to historical, which is not normally what the buyer means.

Require the vendor to name the certificate number and current bucket. A procurement response that asserts compliance without citing a specific CMVP certificate number is a response that cannot be checked against the public record. Ask for the number, ask for the active/historical state at submission time, and ask the vendor to commit to notifying the buyer if the certificate moves to historical during the contract.

Define an interim path for modules where the vendor’s 140-3 certificate is in the CMVP queue. This is the hardest part. The CMVP review queue has run between twelve and eighteen months for most of the last three years, sometimes longer for complex modules. A vendor whose 140-2 certificate moves to historical in September 2026 may have its 140-3 successor sitting in the queue with no public ETA. Procurement teams have three workable options: accept the historical 140-2 certificate as a documented interim posture with a contractually-bound 140-3 milestone; accept a different vendor whose 140-3 certificate is already on the active list; or pause the acquisition until the queue clears. The third option is rarely tenable for mission systems. The first option is the one most agencies have used in past transitions, and it works only if it is written into the contract.

A useful clause shape, in plain prose: “The module shall be FIPS 140-3 validated and on the CMVP active list at time of award. Where the vendor’s FIPS 140-3 validation is in the CMVP review queue at time of award, the vendor shall provide the queue submission record, an active FIPS 140-2 certificate, and a written commitment to deliver an active FIPS 140-3 certificate within twelve months of award.” Adapt to the specific procurement vehicle and the agency’s risk tolerance.

Re-validation lead times: what to plan against

The dominant variable in any 140-3 timeline is the CMVP review queue at NIST. The other components are bounded; the queue is not.

Pre-submission work is the vendor’s responsibility and runs in parallel with whatever development work is happening on the module. Producing the security policy document, the algorithm certificates from CAVP, and the test evidence required by ISO/IEC 24759 typically takes three to six months for a module that previously cleared 140-2 on the same hardware. A module with significant changes (new processor, new tamper enclosure, new key store) can take longer.

Lab testing is performed by an accredited Cryptographic and Security Testing (CST) laboratory. For a module that has previously been validated under 140-2 and is being re-submitted with similar architecture under 140-3, the lab phase is typically two to four months. A fresh module or a substantially redesigned one runs longer. The lab phase produces the validation report that is submitted to CMVP.

CMVP review is the queue. NIST publishes the current queue status on the CMVP “Modules in Process” list, which is updated weekly. Average wait times have been twelve to eighteen months since 2022, with reports of longer queues for complex modules and shorter queues for simpler software-only modules. NIST has publicly worked to reduce the backlog, and recent quarters have shown improvement, but the queue is still the gating constraint.

Total elapsed time from “we decide to start a 140-3 programme” to “we have a certificate on the active list” is therefore eighteen to twenty-four months in the typical case, and longer for complex modules. A vendor that started in early 2025 might land an active certificate in late 2026. A vendor that starts in mid 2026 will not land an active certificate before late 2027 at the earliest, and more realistically mid 2028.

The implication for both sides of the procurement relationship: the sunset is not far enough away to wait. If a vendor has not started, the gap between the 140-2 sunset and the 140-3 certificate is now a contractual exposure that has to be managed with the buyer, not a problem that resolves by itself.

A vendor checklist for the sunset

For a vendor with a FIPS 140-2 certificate currently on the active list, the work breaks down into a small number of explicit items. Most of these are obvious once stated, but the cost of missing one is a procurement-eligibility gap that can run quarters or longer.

1. Inventory every certificate. List the module name, certificate number, current lifecycle state, and the embedded modules (sub-chips, firmware libraries) that the certificate references. Cross-check this list against your sales record. Modules that look retired internally are sometimes still cited in active customer contracts.
2. Identify which of those modules has a FIPS 140-3 successor on the active list, which has one in the CMVP queue, and which has nothing in process. The third bucket is the urgent one.
3. For each module in the third bucket, decide whether it will be re-validated, replaced by a different module, or quietly retired. The cost of re-validation is substantial; the cost of letting a customer-cited module move to historical with no successor is higher if customers depend on it.
4. For modules in the queue, monitor the CMVP “Modules in Process” status weekly and keep customers informed. A vendor who proactively communicates queue position to its procurement counterparts buys substantial goodwill versus one who waits for the buyer to ask.
5. Update sales collateral and any procurement-facing language that quotes “FIPS 140 validated” without a version. After September 2026, that language reads as ambiguous at best and misleading at worst.
6. For modules that are also part of a Common Criteria evaluation, coordinate with the CC scheme on whether the underlying module’s lifecycle change triggers an assurance continuity review. Some Security Targets reference the FIPS certificate number explicitly, and a move to historical can be relevant to the CC body even if the CC certificate itself is not directly affected.

Common Criteria cross-reference

Common Criteria and FIPS are independent programmes, but procurement decisions routinely require both. The clearest case is the NIAP Protection Profile family for US government network devices, mobile platforms, and operating systems, which typically requires that the cryptographic module be FIPS validated as a prerequisite for the CC evaluation. After the September 2026 sunset, those PPs effectively require FIPS 140-3 validation, because a FIPS 140-2 certificate on the historical list will not satisfy the active-validation prerequisite.

The implication for a vendor running both programmes at the same product:

• If your CC evaluation cites a specific FIPS certificate number in the Security Target, check whether that certificate is 140-2 or 140-3. A Security Target that cites a historical certificate may not pass an assurance continuity review.
• If your CC evaluation defers to “a FIPS-validated cryptographic module” without naming a certificate, the new module you certify under 140-3 has to be the one your CC-certified product actually ships with, which is sometimes a non-trivial coordination exercise across product lines.
• High-assurance pairings (HSMs at FIPS 140-3 Level 3 or Level 4 alongside a CC certificate at EAL 4+ or higher) need both programmes calendared together. EAL 6+ vs FIPS 140-3 covers the high-end pairing in more depth.

The cross-reference matters even when the procurement explicitly asks for only one of the two. Buyers who today specify only Common Criteria sometimes inherit the FIPS prerequisite through the chosen Protection Profile, and discover that on contract award rather than at spec-writing time.

What NenkinTracker shows you

NenkinTracker today focuses on Common Criteria certification tracking across all CCRA member schemes and the adjacent non-CC schemes (SESIP, PSA, EMVCo, ESA, MIFARE). We do not currently ingest the CMVP validated modules list directly, so a FIPS 140-3 certificate is not visible to the tracker as a first-class object the way a CC certificate is.

Where the tracker does help on the FIPS sunset specifically:

• CVE feed for the same products. A vendor’s FIPS-validated cryptographic module is almost always inside a product that also has a CC certificate or is otherwise tracked. NenkinTracker surfaces NVD CVE entries against the product, so you can see when a vulnerability affects a module that procurement has flagged as historical-only. That is a useful pre-renewal signal: a historical FIPS 140-2 module with a fresh CVE against it is a stronger trigger to push the vendor on the 140-3 timeline than a clean one.
• Document change tracking on the Common Criteria side. Security Targets, Certification Reports, and Maintenance documents on CC certificates get republished when the underlying module’s lifecycle status changes. NenkinTracker watches those PDFs and notifies you when a new version goes up. For a product that pairs CC and FIPS, the CC-side document change is often the earliest indicator that something on the FIPS side has moved.
• Notifications across the CC scheme landscape. If your procurement spec relies on a CC certificate that itself references a FIPS module, watching the CC certificate for any change is the cheapest way to catch a knock-on effect from the FIPS sunset before it propagates into your supply chain.

The authoritative source for FIPS 140-3 active and historical certificates remains the CMVP validated modules list maintained by NIST. Cross-reference CMVP for the FIPS bucket, and use NenkinTracker for the CC certificate, document, and CVE signals on the same products.

To start monitoring CC certificates and CVEs across BSI, ANSSI, NIAP, EUCC, and the wider scheme landscape, you can start a free trial.