Quick Answer
FIPS 140-3 replaced FIPS 140-2 as the U.S. government standard for validating cryptographic modules. It aligns the requirements with ISO/IEC 19790:2012 and ISO/IEC 24759, renames critical security parameters to sensitive security parameters (SSPs), tightens Level 4 authentication to multi-factor, formalizes software and hybrid module types, and replaces power-on self-tests with pre-operational self-tests. The date that matters: on September 22, 2026, CMVP moves every remaining active FIPS 140-2 certificate to the Historical List. After that, a 140-2 certificate no longer satisfies new federal procurements — though existing deployments can keep running.
If you sell into the federal market, run HSMs in a regulated environment, or are planning a post-quantum migration, here is what actually changed and what to do before the deadline.
Watch the Video
The transition timeline
| Date | What happened |
|---|---|
| March 22, 2019 | FIPS 140-3 approved by the Secretary of Commerce |
| September 22, 2019 | FIPS 140-3 became effective |
| September 22, 2020 | CMVP began accepting FIPS 140-3 submissions |
| April 1, 2022 | CMVP stopped accepting FIPS 140-2 submissions for new validation certificates |
| September 21, 2026 | Last day FIPS 140-2 certificates remain on the Active List |
| September 22, 2026 | All remaining FIPS 140-2 certificates move to the Historical List |
The gap between 2019 and the first issued FIPS 140-3 certificates (2023) is why so many products still ship on 140-2 paper today. Validation queues are real: recent FIPS 140-3 validations have averaged roughly 18 months end to end, meaning a vendor who starts today will not have a 140-3 certificate before the 140-2 sunset.
What "Historical List" actually means
Moving to the Historical List is not a revocation and your hardware does not stop working. CMVP's own guidance: agencies may continue purchasing and using Historical-List modules for existing systems. What changes is procurement posture — a Historical certificate should not be used to satisfy new acquisitions. Each agency decides its own migration timeline, and in practice contracting officers increasingly require an Active (i.e., FIPS 140-3) certificate for new awards. If federal revenue depends on your module's certificate, treat September 2026 as a hard sales deadline, not a soft compliance suggestion.
FIPS 140-2 vs 140-3: the technical differences
Standards basis
FIPS 140-2 was a self-contained U.S. standard. FIPS 140-3 is essentially a wrapper: the requirements are ISO/IEC 19790:2012 (security requirements) plus ISO/IEC 24759 (test requirements), with U.S.-specific modifications published in NIST's SP 800-140x series. One consequence: a vendor engineering to 140-3 is most of the way to international recognition of the same evidence.
Terminology: CSP becomes SSP
140-2 protected critical security parameters (CSPs). 140-3 broadens this to sensitive security parameters (SSPs), which covers both CSPs (keys, passwords) and public security parameters (public keys whose integrity matters). If you write key-management procedures, the zeroization and lifecycle requirements now attach to SSPs.
Module types and roles
140-2 was written for hardware and bolted software/firmware/hybrid definitions on through Implementation Guidance; hybrid modules were capped at Level 1. 140-3 defines hardware, firmware, software, hybrid-software, and hybrid-firmware modules in the standard itself, and hybrids are no longer restricted to Level 1. Role requirements also relaxed: only the Crypto Officer role is mandatory (140-2 required both Crypto Officer and User roles).
Authentication per level
Levels 1–3 look familiar (none required / role-based / identity-based). The change is Level 4, which now requires multi-factor identity-based authentication.
Self-tests
140-2's power-on self-tests become pre-operational self-tests in 140-3, and the model shifts: the integrity test runs before the module provides any cryptographic service, while algorithm conditional self-tests (CASTs) can run at first use rather than all at boot. In practice this improves boot time for large modules but requires vendors to re-architect their self-test flow — one of the common re-engineering costs of the transition.
New in 140-3: non-invasive attacks and degraded operation
140-3 adds requirements for non-invasive attack mitigation (think side channels) at the higher levels, and formally allows a degraded mode of operation — a module can continue offering a reduced service set after a failure instead of bricking itself. 140-2 had no degraded-operation concept.
Why post-quantum makes this a one-way door
The PQC algorithms federal buyers are being told to adopt — ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) — are validated under FIPS 140-3 only. There is no path to a 140-2 certificate covering them. So even if the Historical List didn't force the issue, CNSA 2.0 timelines and federal PQC mandates do: a module that needs quantum-resistant algorithms needs a 140-3 validation. If you're sequencing that work, start with our PQC migration checklist and the post-quantum cryptography guide.
How to check what you're actually running
Two checks, five minutes.
1. Look up the certificate. Search the CMVP validated modules list (csrc.nist.gov → Cryptographic Module Validation Program → Validated Modules). Filter by vendor, then check the Standard column (FIPS 140-2 vs FIPS 140-3) and the Status (Active vs Historical). Get the certificate number from your vendor if you can't find it — "FIPS compliant" marketing language without a certificate number is not a validation.
2. Verify what your systems load. For OpenSSL 3.x with the FIPS provider:
# List active providers — you want to see "fips" openssl list -providers
# Confirm the FIPS provider version and status openssl list -providers -verbose
The OpenSSL 3.0/3.1 FIPS providers were validated under FIPS 140-2; OpenSSL's newer provider validations target 140-3. Which one your distro ships matters for the 2026 boundary — we cover the specifics in the OpenSSL FIPS compliance guide.
What to do before September 2026
If you're a vendor selling to the government
Inventory which of your certificates are 140-2, ask your lab for realistic 140-3 timelines now (queues average ~18 months), and if you can't validate in time, get on a lab's schedule and be ready to show procurement officers a submission in process.
If you're a buyer or program office
Existing systems keep running — don't panic-replace working HSMs. But any new acquisition or system going through authorization after September 2026 should require an Active FIPS 140-3 certificate, and your RFP language should say so explicitly.
If you run PKI infrastructure
Check your CA's HSMs, your TLS termination points, and anything doing key generation. The certificate backing your root CA's HSM moving to Historical doesn't invalidate your hierarchy, but auditors (WebTrust, FedRAMP assessors) will start asking about your 140-3 roadmap. Have an answer with dates.
Frequently Asked Questions
Does my FIPS 140-2 hardware stop working on September 22, 2026?
No. Nothing expires operationally. The certificate moves to the Historical List, which affects new federal procurements, not running systems.
Can an agency still buy a 140-2 module after the deadline?
Per CMVP, Historical-List modules may still be purchased and used for existing systems. New systems should specify 140-3.
Is there a FIPS 140-4 coming?
No. Because 140-3 tracks ISO/IEC 19790, future updates arrive by revising the ISO standard and NIST's SP 800-140x documents rather than a new FIPS number.
Does FIPS 140-3 change which algorithms are approved?
Algorithm approval lives in the SP 800-140 annexes and CAVP, not the 140-3 document itself — but note the practical coupling: PQC algorithms (FIPS 203/204/205) only validate under 140-3.
Configuring FIPS mode in OpenSSL?
Read the full guide on OpenSSL 3.x FIPS providers — FIPS capable vs compliant, provider configuration, and audit documentation.
Read the OpenSSL FIPS Compliance Guide