FIPS 140-2 Sunsetting Sept 21 2026: What Historical Status Means for Your Stack
The cryptography did not suddenly break. The validation status changed — and that distinction matters for procurement, audits, and migration plans.
On September 21, 2026, the U.S. National Institute of Standards and Technology (NIST) moved every remaining active FIPS 140-2 validation to the Historical list in its Cryptographic Module Validation Program (CMVP). It is not an emergency — the date had been on the calendar for seven years ever since FIPS 140-3 was approved in March 2019 — but it quietly reshapes compliance in a way most security teams haven't fully absorbed yet. Here's what actually changed and what to do about it.
What FIPS 140-2 is
FIPS 140-2 is NIST's standard defining minimum cryptographic security requirements for federal deployments. Products — operating systems, cryptography libraries, HSMs, payment modules — earn a FIPS 140-2 validation by passing laboratory testing of their cryptographic module. A valid certificate has historically been the proof-of-compliance token that federal buyers, FedRAMP assessors, CMMC auditors, and CJIS and payment-card auditors check. FIPS 140-3 is its successor, tightening security-level definitions and adding a cleaner post-quantum path.
What "Historical" actually means — and doesn't
Historical status does not mean the product is insecure or defective. The cryptography still works; a SHA-256 or AES module isn't suddenly broken on September 22. What changes is standing in the procurement and audit world:
- New federal acquisitions can no longer be supported with an old FIPS 140-2 certificate — vendors need a FIPS 140-3 validation going forward.
- Compliance frameworks that reference an "Active" FIPS validation (FedRAMP, CMMC, CJIS, payment HSMs) begin receiving questions from assessors. Legacy contracts that only reference "FIPS 140-2" without specifying active versus historical are the risk zone — those often need legal counsel.
- New procurements should require FIPS 140-3 validation from here on out.
The practical rule: a certificate on the Historical list is a past validation, not an active one.
The post-quantum overlay
The sunset matters most as a launch-ramp into the post-quantum era. In the same window, the first validated post-quantum cryptography modules are landing under FIPS 140-3 — at least five active FIPS 140-3 certificates already list post-quantum algorithms as approved services, and more can appear on any given CMVP search. And the whole push arrives just 102 days before the CNSA 2.0 acquisition gate on January 1, 2027. In other words: the FIPS 140-2 sunset and the move to FIPS 140-3-validated, post-quantum-capable modules are the same transition, seen from two dates.
What to check in your stack
- Audit every FIPS-validated module you ship or depend on, and confirm its exact CMVP status (active 140-3, active 140-2 legacy, or Historical) — not just "FIPS compliant" on a vendor's marketing page.
- Map compliance frameworks you're held to (FedRAMP, CMMC, CJIS, PCI) against whether they call for an Active validation or merely a FIPS 140-2 mention, and flag the ambiguous ones for legal review.
- Plan the FIPS 140-3 swap for any product line sold into federal, defense, or critical-infrastructure customers — including embedded systems and cloud containers, where the multi-year lab queues bite hardest.
- Watch the PQC gap: if your federal path requires CNSA 2.0 readiness, you may need FIPS 140-3 validated modules with post-quantum approved services by the January 1, 2027 gate — a schedule that will not move.
If you've built a FIPS 140-2 compliance claim into a product or a report, today is the day that claim starts aging. The cryptography did not break on September 21 — your ability to prove it for a new buyer is what changed. Confirm your modules' status, close the gap to FIPS 140-3, and get the post-quantum overlay into the roadmap before the CNSA 2.0 gate does the deciding for you.
Inventory the exact cryptographic modules your products and services use, verify their current CMVP status, and separate technical security from procurement eligibility. A historical certificate is not proof of a new vulnerability, but it may no longer satisfy a buyer or assessor that requires active validation.
Sources: NIST Cryptographic Module Validation Program transition materials and validated-module listings, plus published FIPS 140-2 historical-status transition analyses.