If your product does cryptography and your customers include US federal agencies — or anyone who copies their procurement rules — your crypto module needs CMVP validation. The 140-2 era ends in September 2026; the queue for 140-3 is the planning problem.
At a glance
Owner
US–Canada programme; testing by accredited CST laboratories
Basis
FIPS 140-3 aligned the US programme with the international standard
Levels
From algorithm correctness to tamper-responsive physical security
Scope
Hardware, firmware, software and hybrid — not whole products
Hot date
FIPS 140-2 certificates move to the historical list — procurement impact follows
Regulatory hooks
Also referenced in payment, healthcare and some EU national requirements
What it is
FIPS 140-3 validates a cryptographic module — a defined boundary containing approved algorithms, key management and self-tests — against ISO/IEC 19790 requirements, tested by an accredited lab and validated by the CMVP. Four security levels grade the demands, from correct algorithm implementation at Level 1 to tamper-responsive hardware with environmental protections at Levels 3–4. The certificate lists precisely what was validated: module version, operational environments, approved modes. Step outside any of them and you are, formally, no longer FIPS-validated.
The programme’s practical reality is the queue. CMVP review times have historically stretched to many months beyond lab testing, which makes validation timing a product-roadmap decision, not a compliance afterthought. The September 2026 move of FIPS 140-2 certificates to the historical list sharpens this: procurement frameworks that require an active validation will stop accepting 140-2-validated modules, and vendors who did not re-validate under 140-3 inherit the full queue at its most congested.
For European vendors, FIPS is rarely the whole answer but often a required ingredient: it validates the crypto boundary, while CC/EUCC, SESIP or scheme-specific evaluations cover the surrounding product security. The efficient strategies design one module boundary and one set of evidence that feeds both worlds.
When it's the right tool
Federal procurement, FedRAMP-hosted services, defence supply chains and the many private-sector buyers who mirror federal rules — an active CMVP certificate is a binary gate.
A validated module inside a CC-evaluated product or a certified cloud service answers the “is the cryptography sound” question once, reusably, in a vocabulary auditors worldwide accept.
FIPS says nothing about the application around the module, the protocol design or the update mechanism. A validated module in an insecure product is exactly that.
Every module change can trigger revalidation. Define the boundary so routine product releases don’t touch it — or budget for a validation treadmill you did not need.
Where it matters
Secure elements and crypto accelerators sold into US markets pair EUCC evaluation with CMVP validation — one boundary design serving both.
FedRAMP-adjacent deals and financial customers expect FIPS-validated key management under the service — alongside C5, SecNumCloud or ISO evidence.
Transport encryption and key management in network equipment increasingly reference validated modules in operator procurement.
Industrial vendors serving US utilities and federal facilities meet FIPS requirements layered on top of IEC 62443 programmes.
Expert notes
The September 2026 historical-listing of 140-2 certificates is a procurement event, not a technical one: modules keep working, but contracts requiring active validation quietly break. The transition planning question is whether your module needs full 140-3 validation, whether an embedded validated module (a common OEM strategy) covers you, or whether your customers’ frameworks accept modules “in process” on the CMVP list — many do, some don’t, and the difference is worth checking per contract rather than assuming.
Our position: inventory which revenue actually depends on active validation before buying lab time. We regularly find half the panic is contracts that accept “in process” status — and one contract that needed action a year ago.
FIPS validation and CC evaluation answer different questions with overlapping evidence: design documentation, algorithm testing and physical security analysis can be produced once and consumed twice if planned. European schemes generally do not require FIPS, but a validated module strengthens CRA files, cloud attestations and payment evaluations wherever cryptographic strength must be evidenced rather than asserted.
Our position: if you serve both markets, write the crypto module’s documentation to ISO/IEC 19790 structure from the start — it is the format both worlds can consume, and retrofitting it is the most avoidable cost in this domain.
Boundary design, level selection, lab and queue strategy, transatlantic evidence reuse — thirty minutes to a plan.
We’ll send you access by email.
