For three decades, cryptography sat quietly in the background of IT. It was a technical detail few people outside the security team ever discussed. That era is over.
FIPS 140-3 has moved cryptographic validation to the front of every conversation about selling technology to the U.S. and Canadian governments. The reason is a single date. On September 21, 2026, the FIPS 140-2 standard reaches its sunset.
For IT and software vendors, this is not just a technical milestone. It is a hard business deadline that quietly decides who stays eligible to sell to federal agencies.
What FIPS 140-3 actually is
FIPS 140-3 is the U.S. federal standard for validating cryptographic modules, developed and proposed by NIST. Validation runs through the Cryptographic Module Validation Program (CMVP), operated jointly by NIST and Canada’s Cyber Centre, so a single certificate serves both the US and Canadian governments. The Secretary of Commerce approved it in March 2019, and it became effective in September 2019.
It superseded FIPS 140-2 and aligned U.S. validation with the international standards ISO/IEC 19790 and ISO/IEC 24759. In practice, an active CMVP certificate is what tells a federal buyer that your cryptography has been independently tested and approved.
What changed from FIPS 140-2
The new standard keeps the familiar structure but tightens two requirements, one that FIPS 140-2 never demanded, and one where where multiple exceptions were previously tolerated.
- Non-invasive attack mitigation: at higher security levels, modules must be tested against non-invasive attacks such as side-channel analysis.
- Entropy source documentation: vendors must formally document the entropy sources that feed key generation. Under FIPS 140-3, non-conformance can no longer be waived by certificate caveat.
Both additions raise the bar on how a module is built and evidenced, not just how it performs.
The four security levels
The standard defines four security levels, numbered 1 to 4. Each step adds stronger physical and logical protection. Vendors should match the level to the sensitivity of the data a module protects. The overall level reflects the lowest level achieved across the individual security requirement areas, and certificates may list per-area exceptions, so read the certificate, not just the headline number.
- Level 1: basic requirements with approved algorithms and no specific physical protection.
- Level 2: adds tamper-evidence and role-based authentication.
- Level 3: adds tamper detection and response, plus identity-based authentication.
- Level 4: adds robust physical protection designed to resist advanced attack attempts.
For example, an organization protecting high-value keys will typically store them in an HSM validated to the appropriate level.
Why the September 21, 2026 sunset matters
The deadline has a clear endpoint. CMVP stopped accepting new FIPS 140-2 submissions in 2022. On September 21, 2026, every remaining active FIPS 140-2 certificate moves to the CMVP Historical List.
Federal agencies “should not include” modules on the Historical List in new procurements. That single status change is what turns a technical date into a revenue question.
FIPS 140-2 validation remains active through September 21, 2026. After that, modules in the Historical List can stay in use for existing systems, but new federal business depends on an active 140-3 certificate.
Who gets locked out
The change reaches across common product categories. It touches federal IT systems, VPN appliances, HSMs, secure communication platforms, and operating systems.
Vendors without an active certificate are effectively locked out of new federal acquisitions. With 18-30 month validation timelines, the window for starting from scratch has already closed. Vendors not currently in the CMVP queue should plan around the sunset rather than through it. .
The validation timeline problem
Traditional FIPS 140-3 validation runs roughly 18 to 30 months from initiation to certificate issuance. That is why the deadline is closer than it appears on the calendar.
If your timeline assumes a quick turnaround, the queue will correct that assumption. Starting late is the most common way to miss the window.
The post-quantum queue collision
There is a compounding squeeze. The same CMVP queue needed for a standard validation certificate is now also validating post-quantum algorithms.
Standards such as CNSA 2.0 and NIST IR 8547 call for algorithms like ML-KEM and ML-DSA. As a result, a single submission increasingly has to clear both bars at once, which adds pressure to an already crowded pipeline.
How FIPS 140-3 maps to your cryptography
Readiness comes down to a set of interlocking workstreams. Each one describes something you need to prove in practice.
- Validation status tracking: confirm every module in a product boundary carries an active CMVP certificate matched to the exact deployed version, not just the product family.
- PKI on validated modules: issue certificates and manage keys through certificate authorities and HSMs backed by validated modules.
- Module migration planning: track which deployed modules sit on FIPS 140-2 versus 140-3.
- Evidence for assessors: map every certificate and key to its validated module and certificate number (NIST SP 800-53 SC-13, SC-28, IA-7).
- Entropy and operating environment: confirm your deployment runs on an operating environment listed on the certificate, since entropy validation is tied to the tested environment.
- Hardware-backed key protection: store keys in HSMs at the appropriate security level.
Are you audit ready? Questions assessors will ask
Federal examiners and assessors tend to probe the same points. Treat these as a self-check before they become findings.
- Active certificate verification: does every module carry an active CMVP certificate, confirmed through the CMVP validated modules search rather than vendor marketing?
- Version-to-certificate matching: does the deployed version match the version the certificate actually covers?
- Historical List exposure: have you identified every module still validated only under FIPS 140-2, with a documented transition plan?
- FIPS mode enforcement: can you show FIPS mode is enabled at runtime, not just present in the image?
- Entropy documentation: is the entropy source feeding key generation documented to the required standard?
- Migration roadmap: is there a plan of action and milestones for any module approaching Historical status, with named ownership and a realistic timeline?
How Keyfactor can help
The challenges above map cleanly to a small set of capabilities. Keyfactor covers each one so readiness becomes an operational program rather than a scramble.
- Keyfactor AgileSec discovers cryptographic assets across your landscape and tracks validation status, matching certificates to the exact deployed versions.
- EJBCA builds PKI on validated modules and generates keys from documented entropy sources. It also gives you access to Bouncy Castle’s FIPS 140-3 validated module for versatile, secure cryptographic primitives.
- Keyfactor Command orchestrates module migration, re-keying, and centralized evidence reporting.
- Keyfactor SignServer signs build and release artifacts so deployments into the authorization boundary are verifiable.
Next steps:
The direction of travel is clear. Requirements are becoming more explicit, and the window for legacy modules is narrowing.
The vendors who stay eligible will be the ones who move before the queue fills. Three practical steps make the difference:
- Gain visibility into your cryptographic assets.
- Assess them against current FIPS 140-3 requirements.
- Get into the validation queue now rather than later.
Ready to see how Keyfactor supports FIPS 140-3 readiness? Request a Demo.
Got FIPS 140-3 questions? We’ve got answers.
What is FIPS 140-3?
FIPS 140-3 is the standard for validating cryptographic modules followed by the U.S. and Canadian governments. Approved in March 2019, it superseded its previous version FIPS 140-2. It aligns U.S. validation with the international standards ISO/IEC 19790 and ISO/IEC 24759.
When does FIPS 140-2 expire?
FIPS 140-2 validation remains active through September 21, 2026. On that date, remaining active FIPS 140-2 certificates move to the CMVP Historical List. Federal agencies should not include Historical List modules in new procurements.
What happens on the September 21, 2026 sunset?
Modules validated under FIPS 140-2 within the last five years can stay in use for existing systems. However, new federal business depends on an active 140-3 certificate. Without one, a vendor is effectively locked out of new federal acquisitions.
How long does FIPS 140-3 validation take?
Traditional validation runs roughly 18 to 30 months from initiation to certificate issuance. The CMVP queue can extend timelines further. That is why starting early is the safest way to stay eligible.
What changed between FIPS 140-2 and FIPS 140-3?
The newer standard adds two requirements that were either relaxed in FIPS 140-2, or were not included at all. Higher security levels now require non-invasive attack mitigation testing, such as protection against side-channel analysis. Vendors must also formally document the entropy sources that feed key generation.
How does FIPS 140-3 relate to post-quantum cryptography?
The same CMVP queue that validates 140-3 modules is also validating post-quantum algorithms like ML-KEM and ML-DSA. Standards such as CNSA 2.0 and NIST IR 8547 drive that demand. A single submission increasingly has to satisfy both requirements at once.
Who needs FIPS 140-3 validation?
Any vendor selling cryptographic technology into new federal acquisitions needs an active certificate. This includes federal IT systems, VPN appliances, HSMs, secure communication platforms, and operating systems. Vendors that delay risk missing the validation window entirely.
