On September 21, 2026, every cryptographic module holding a FIPS 140-2 validation moves to the Historical List in NIST’s Cryptographic Module Validation Program database. The date is fixed, it applies to all remaining 140-2 certificates at once regardless of when they were issued, and there is no extension mechanism for individual vendors.
What that transition means for buying decisions is more qualified than most of the coverage suggests — and the qualification comes from NIST itself.
What the deadline actually is
The CMVP has run a two-part sunset rule through the 140-3 transition. A FIPS 140-2 validation stays active for five years from its validation date or until September 21, 2026, whichever comes first. In NIST’s own wording on the FIPS 140-3 transition effort, on that date “all FIPS 140-2 certificates are placed on the Historical List.”
Because 140-2 validations stopped being issued some time ago, September 21 is the terminal date for the entire remaining population. There is no staggered tail.
What NIST says Historical status does not mean
This is where a lot of secondary commentary overreaches, and where a procurement team can make an expensive mistake in either direction.
NIST is explicit that “even on the historical list, CMVP supports the purchase and use of these modules for existing systems.” Historical status is a statement about the currency of the validation record, not a revocation, not a finding that the module is broken, and not a blanket prohibition on purchase.
NIST goes further, and this is the sentence most worth reading twice before you write a 140-3-only clause into a specification. The transition guidance reminds purchasers that “for several years there may be a limited selection of FIPS 140-3 modules,” and recommends that purchasers “consider all modules that appear on the Validated Modules Search Page and meet their requirements for the best selection of cryptographic modules, regardless of whether the modules are validated against FIPS 140-2 or FIPS 140-3.”
That is NIST advising buyers not to filter on 140-3 alone. It sits awkwardly next to the framing that 140-2 certificates “stop counting” after September — a framing that circulates widely and is not what the program says.
So where does the real constraint come from?
The binding constraint is usually not CMVP. It is the agency, the contract, or the framework sitting on top of it.
A federal procurement requirement, a DoD contractual clause, a FedRAMP baseline, or an internal policy can each specify a validation posture stricter than CMVP’s own guidance — and frequently does. The practical question for a vendor-selection decision is therefore not “what does the Historical List mean in general,” but:
- Which specific authority governs this purchase? Agency policy, contract clause, or accreditation baseline. Name it.
- What does that authority say about Historical-status modules — for new procurement, and separately for systems already in production?
- When does that authority’s own position change? Many organizations will tighten their language on their own schedule, which may be well after September 2026.
The failure mode is treating a general-purpose calendar date as if it were your governing requirement. The date is real; whether it disqualifies a product for your purchase is a question about your compliance regime, and answering it requires reading your regime rather than the headlines.
What to ask vendors now
Regardless of how your governing authority lands, these questions separate a vendor with a plan from one without:
“Is the module you are selling me validated under 140-2 or 140-3 today?” Ask for the certificate number and check it on the CMVP Validated Modules Search page yourself. Vendor marketing routinely says “FIPS validated” without specifying the standard, and occasionally means “uses a validated module somewhere in the product” rather than “the component you are buying is the validated boundary.”
“If it is 140-2, where is the 140-3 submission?” There is a meaningful difference between in the CMVP queue with a submission date, in testing with a lab, and on the roadmap. The CMVP queue has run long; a vendor who has not yet entered it is further out than a slide might imply.
“What is the module boundary?” This is the question that catches the most problems. A validation covers a specific cryptographic module, not a whole product. Two vendors can both claim validation while drawing the boundary in places that give you materially different assurance.
“What is your plan for the modules already deployed in my environment?” Existing deployments are explicitly supported by CMVP after the transition, but you still want to know whether the vendor intends to ship a 140-3-validated replacement into your existing installs, and on what timeline.
The post-quantum overlay
The FIPS 140-3 transition is running alongside the migration to post-quantum algorithms, and the two get conflated in vendor messaging because both involve a cryptographic refresh. They are separate programs with separate timelines. A 140-3 validation is not a statement about post-quantum readiness, and a vendor’s PQC roadmap is not a substitute for a current validation.
Worth handling them as two independent lines in a vendor assessment, because a product can be strong on one and absent on the other.
The practical read
If you buy cryptographic products for a federal-facing or regulated environment, September 21, 2026 is a date to have on the calendar — but the useful work is not the date itself. It is knowing, in writing, what your governing authority requires of a Historical-status module, and having current certificate numbers and boundary definitions for the modules you already run.
The organizations that will have a bad autumn are not the ones running 140-2 modules. They are the ones that cannot say which modules they run, under which certificates, inside which boundaries.