FIPS 140-3:
Cryptographic Module Validation for IT and Software Vendors
| Region | United States and Canada (federal cryptographic module validation standard; drives eligibility for U.S. federal and defense procurement worldwide, since the validated module list is a global gate for any vendor selling into those markets) |
| Applicability | Vendors of Cryptographic Modules: software libraries, operating system crypto providers, hardware security modules, and cloud cryptographic services embedded in products sold into U.S. or Canadian government-adjacent markets Federal Agencies and Contractors: required to procure only FIPS 140-validated modules to protect federal data and Controlled Unclassified Information, enforced through FedRAMP, CMMC, and DoD acquisition rules CMVP-Accredited Testing Laboratories: third-party Cryptographic and Security Testing Laboratories (CSTLs) performing conformance testing against the standard |
| Relevant sections | FIPS 140-3: Security Requirements for Cryptographic Modules, aligned with ISO/IEC 19790:2012 and ISO/IEC 24759:2017 CMVP Active and Historical Lists: the validation status that determines whether a module is eligible for new federal procurement NIST SP 800-53 SC-13, SC-28, IA-7: controls requiring cryptography to come from a validated module |
Overview
FIPS 140-3 was approved by the Secretary of Commerce in March 2019 and became effective in September 2019, superseding FIPS 140-2 and aligning U.S. cryptographic module validation with the international ISO/IEC 19790 and ISO/IEC 24759 standards. It introduces non-invasive attack mitigation testing at higher security levels and formal entropy source documentation requirements that FIPS 140-2 did not require.
The transition has a hard endpoint. CMVP stopped accepting new FIPS 140-2 submissions in 2021, and on September 21, 2026, every remaining active FIPS 140-2 certificate moves to the CMVP Historical List, a status the program defines as one federal agencies “should not include” in new procurements. FIPS 140-2 modules validated within the last five years can remain in use for existing systems, but new federal business depends on an active FIPS 140-3 certificate.
Why it matters
Traditional FIPS 140-3 validation runs 18 to 30 months from initiation to certificate issuance. Vendors whose products are embedded in federal IT systems, VPN appliances, HSMs, secure communication platforms, operating systems, are effectively locked out of new federal acquisitions after September 21, 2026, if they have not already secured an active certificate; vendors who had not started the process by early 2025 face a high probability of missing the window entirely.
The squeeze is compounding rather than isolated: the same CMVP queue that vendors need for a standard FIPS 140-3 certificate is also the queue for validating the post-quantum algorithms (ML-KEM, ML-DSA) that CNSA 2.0 and NIST IR 8547 are simultaneously requiring, so a single validation submission increasingly has to clear both bars at once.
How this maps to cryptography
FIPS 140-3 addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:
| Section | Function | What it says | Supporting Products |
| FIPS 140-3; CMVP Active and Historical Lists | Cryptographic Module Validation Status Tracking | Confirm every cryptographic module in a product’s boundary carries an Active CMVP certificate matched to the exact software or firmware version deployed, not just the product family. | AgileSec |
| FIPS 140-3, Security Levels 1–4 | PKI Built on Validated Modules | Issue certificates and manage keys through certificate authorities and HSMs backed by FIPS 140-3 validated cryptographic modules. | EJBCA |
| CMVP Historical List transition, September 21, 2026 | Module Migration Planning | Track which deployed modules sit on FIPS 140-2 versus 140-3, and orchestrate re-keying or certificate reissuance once a dependent module moves to Historical status. | Keyfactor Command |
| NIST SP 800-53 SC-13, SC-28, IA-7 | Evidence for Federal Assessors | Centralized reporting that maps every certificate and key to its underlying validated module and certificate number, supporting System Security Plan and audit evidence. | Command / AgileSec |
| FIPS 140-3 entropy source documentation | Randomness and Key Generation Assurance | Generate keys using validated, adequately documented entropy sources within a FIPS-validated module boundary. | EJBCA |
| FIPS 140-3 non-invasive attack mitigation (higher security levels) | Hardware-Backed Key Protection | Store keys in HSMs validated to the FIPS 140-3 security level appropriate to the sensitivity of the data they protect. | EJBCA |
Audit readiness
Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:
- Active Certificate Verification: Does every cryptographic module in the product boundary carry an Active CMVP certificate, confirmed through the CMVP validated modules search rather than vendor marketing claims?
- Version-to-Certificate Matching: Does the specific software or firmware version deployed in production match the version covered by the certificate?
- Historical List Exposure: Has the organization identified every module still validated only under FIPS 140-2, and does it have a documented plan for the September 21, 2026 transition?
- FIPS Mode Enforcement Evidence: Can the organization demonstrate that FIPS mode is actually enabled at runtime, not merely present in the deployed image?
- Entropy Source Documentation: Is the entropy source feeding key generation documented to the standard FIPS 140-3 now requires?
- Module Migration Roadmap: Is there a POA&M-style roadmap for any module approaching Historical status, with named ownership and a realistic validation timeline?
TAKE THIS TO MANAGEMENT
September 21, 2026 is a hard procurement deadline, not a soft recommendation. Every FIPS 140-2 certificate we rely on moves to the CMVP Historical List that day, and federal agencies are instructed not to use Historical-status modules for new business. Validation takes 18 to 30 months, so if we have not already started, or confirmed our vendors have, we are already behind the window.
This is not only our problem to solve internally. Every embedded library, OS crypto provider, and HSM in our product needs its own current certificate, and we need to be able to prove it with a certificate number and matching version, not a vendor’s compliance claim. The same validation queue is now also the bottleneck for post-quantum algorithm validation, so getting in line now buys us leverage on both fronts.
Related Compliances
Federal Risk and Authorization Management Program (FedRAMP)
