Is FIPS 140-3 Worth It? A Practical Pros and Cons Breakdown
With the retirement of FIPS 140-2 now weeks away, the uncomfortable question is this: how many certificate holders have actually moved to FIPS 140-3?
Far fewer than buyers assume.
NIST stopped accepting new FIPS 140-2 submissions in April 2022. On 21 September 2026, every remaining FIPS 140-2 certificate moves from the CMVP active list to the historical list. Historical certificates remain publicly accessible, but they no longer satisfy procurement requirements that call for FIPS validation. A small set of HSM and core crypto-library vendors have completed the migration. A long tail of "validated" 140-2 modules is still sitting there, unchanged, about to become historical while procurement teams keep treating the badge as current assurance.
FIPS 140-3 exposes who did real engineering and who passed a legacy checkbox.
What changed from FIPS 140-2 to FIPS 140-3
FIPS 140-3 is not a minor revision. It aligns the US standard with ISO/IEC 19790:2012, which means the testing methodology, documentation requirements, and security assertions have all changed structurally. Vendors cannot simply resubmit their 140-2 documentation with a new cover page. The module boundary definitions, self-test requirements, and lifecycle assurance evidence are materially different.
The average validation timeline under FIPS 140-3 is approximately 19 months from submission to active certificate, based on early CMVP data. The fastest module to clear the process took just under 12 months. Combined with the 12-to-18-month CMVP queue backlog reported through 2025, any organisation that has not already begun the process is unlikely to hold an active 140-3 certificate before the September 2026 cut-off.
What the FIPS 140-3 security levels mean
FIPS 140-3 defines four security levels for cryptographic modules. Each level builds on the one below it.
Level 1: software baseline
Basic security requirements. The module uses approved algorithms and passes self-tests, but there is no physical protection requirement. This is the tier for software-only crypto libraries running on general-purpose hardware. It proves the algorithms are correct. It proves nothing about the environment they run in.
Level 2: tamper evidence and role-based access
Adds tamper-evident coatings or seals to physical modules and requires role-based authentication for operators. This is the common tier for rack-mounted HSMs in controlled data centre environments where physical access is already restricted. The tamper evidence is a detection mechanism, not a prevention mechanism.
Level 3: tamper resistance with active zeroisation
Adds active tamper-response circuitry that zeroises plaintext keys on intrusion detection. Requires identity-based authentication rather than role-based. This is the standard enterprise HSM tier for financial services, healthcare, and government deployments. If someone forces the enclosure, the key material is destroyed before it can be extracted.
Level 4: environmental failure protection
The highest assurance tier. Adds a complete tamper-active envelope and protection against environmental fault attacks (voltage, temperature). Designed for physically hostile operating environments. Rarely deployed in commercial settings. Where it appears, the threat model justifies the cost.
The case for FIPS 140-3
Market access is non-negotiable in regulated sectors
If you sell into US federal, defence, regulated finance, healthcare, or critical infrastructure, FIPS 140-3 is a gate, not a preference. No active certificate, no entry. Procurement language is already shifting from generic "FIPS 140 validated" to explicit requirements for "FIPS 140-3 validated and on the CMVP active list at time of award." Historical 140-2 certificates will not satisfy that language.
Independent, evidence-based assurance
FIPS 140-3 forces vendors through a structured validation process that examines boundary integrity, key lifecycle controls, self-tests, error handling, and operational environment constraints. A Cryptographic and Security Testing (CST) laboratory conducts the testing against published criteria. The output is a certificate tied to a specific module, firmware version, and configuration. Less "trust us," more evidence.
Audit efficiency for procurement and compliance
For organisations that consume cryptographic modules rather than build them, an active FIPS 140-3 certificate is an anchor. Compliance teams can validate the certificate number, confirm the module version matches what is deployed, and move on. Without it, they are left conducting their own assessment of cryptographic implementation quality, which is a task few compliance functions are equipped for.
Global alignment through ISO/IEC 19790
FIPS 140-3 is built on ISO/IEC 19790, which is recognised across jurisdictions. For vendors and enterprises operating across the US, Canada, the EU, and Asia-Pacific, a single validation effort carries further than a purely domestic standard. The CMVP is a joint US-Canada programme, and the underlying ISO standard is referenced in procurement frameworks beyond North America.
A governance signal, not just a technical one
Holding an active FIPS 140-3 certificate signals that the organisation's cryptography is engineered, documented, version-controlled, and subject to external scrutiny. For board and C-suite audiences, it is a governance artefact as much as a technical one.
The case against FIPS 140-3
The migration rate is lower than the market assumes
NIST stopped accepting FIPS 140-2 submissions over four years ago. The number of active FIPS 140-3 certificates remains small relative to the installed base of 140-2 modules still in production. Some vendors cannot migrate without a fundamental redesign of their cryptographic module architecture. Their "validated" status is about to expire, and procurement teams that have not checked the CMVP active list recently are exposed.
Version rigidity conflicts with modern release cycles
A FIPS 140-3 certificate is tied to a specific firmware version and configuration. Any meaningful code change risks invalidating the certificate, triggering a re-validation or at minimum a formal change letter process. For SaaS platforms and cloud-native services shipping weekly or daily, that constraint is operationally painful. The choice between "certified but frozen" and "current but uncertified" is not theoretical.
Cost and elapsed time are substantial
Validation is slow and expensive. The CST lab engagement, documentation, testing, CMVP queue time, and coordination cycles add up. With average validation times running to 19 months and the CMVP queue adding further delay, the total elapsed time from decision to active certificate can exceed two years. If your buyers do not mandate FIPS, the commercial return on that investment is often negative.
FIPS validates the module, not the system
This is the limitation that matters and the one that gets ignored. The FIPS certificate covers a specific cryptographic module boundary. It does not cover the application calling the module, the key management policy, the operator procedures, the entropy source feeding the random number generator, or the ceremony that generated the root keys. FIPS does not mandate constant-time code or side-channel resistance at common validation levels. Certified modules have shipped with exploitable flaws, including the ROCA RSA key generation vulnerability and the EUCLEAK non-constant-time modular inversion, both inside functions that validation exists to examine.
The strongest security work happens in the space the certificate does not reach.
The "FIPS-validated" label creates false comfort
Treating a FIPS certificate as a complete answer to cryptographic risk is dangerous. Auditors who understand the standard spend their time on questions the certificate does not address: whether devices actually run validated configurations, whether key generation provenance is documented, whether operator procedures match policy, and whether backup and cloning are secured. A FIPS certificate is one assurance layer. It is not a resilience strategy.
The procurement gap: what to check before the September 2026 deadline
With 140-2 certificates moving to the historical list on 21 September 2026, procurement and vendor management teams should be asking three questions now:
Which cryptographic modules in our environment hold FIPS 140-2 certificates that have not been replaced by FIPS 140-3 equivalents?
For each of those modules, has the vendor submitted for FIPS 140-3, and what is the expected certification date?
Where a vendor has no FIPS 140-3 submission in progress, what is the remediation path, and who owns it?
For modules still in the CMVP validation queue, procurement specifications should include interim pathways: accepting a historical 140-2 certificate with a contractual commitment to deliver a 140-3 certificate within a defined window.
The bottom line
FIPS 140-3 is worth it where it unlocks regulated markets, satisfies mandatory procurement criteria, or materially reduces audit friction. Everywhere else, it is a strategic choice, not a default. The standard validates the cryptographic module boundary. It does not fix entropy collapse, bad key management, weak operational governance, or the assumption that "validated" means "secure."
The September 2026 deadline is not abstract. It is 11 days away. Organisations that have not verified their vendors' FIPS 140-3 status are carrying risk they may not have priced.
How SITG-Consulting can help
At SITG-Consulting, we provide independent FIPS 140-3 gap analysis and readiness assessment, so you know whether a 140-3 path is viable before you commit to the certification process. We work across all four security levels, from software-only Level 1 modules through to Level 4 tamper-active hardware, helping organisations and vendors understand what the validation requires, what it costs, and whether the commercial case supports it.
Comments