The Certificate Is Not the Product
A sales engineer at a major HSM vendor recently told me that over 90% of customers who buy FIPS-enabled HSMs run them with FIPS mode disabled. They pay a premium for the certificate, then switch off the configuration it describes. By the end of this article, you'll understand why that is often the correct engineering decision.
On September 21, 2026, every remaining FIPS 140-2 certificate moves to NIST's historical list. Procurement teams are spending this summer chasing vendors for FIPS 140-3 paper. A lot of money and attention is flowing toward a certificate.
Here's the quiet part: a FIPS validation is an answer to a narrow question. It attests that a specific cryptographic module, at a specific firmware version, in a specific configuration, implements approved algorithms correctly and meets certain design requirements. It does not attest that the product around the module is secure, that the module will be operated in its validated configuration, or that the keys inside it were generated and managed in a way you could defend to anyone.
None of this is an argument against FIPS. The program killed off a generation of snake-oil crypto. "No validation, no purchase" remains a sensible procurement floor. The argument is about what the certificate covers—the gap between that and what people believe it covers is remarkably consistent and well documented.
What the Certificate Actually Covers
FIPS 140-3 validation applies to the cryptographic module boundary: algorithms are approved and correctly implemented, keys can be zeroized, the module runs power-up self-tests, and at levels 2-4, hardware resists or responds to physical tampering. That's the whole scope.
The application calling the module, access control, key management policy, the humans holding operator cards, and the ceremony that put the first keys inside—all of it is outside the boundary, and none of it is examined.
The validation is also a snapshot. It binds to an exact firmware version and configuration. The moment a device runs different firmware, or runs with non-approved mode enabled because some legacy client needed it, it is no longer the thing on the certificate. Most deployed HSM estates drift from their validated configuration within months, and nobody's dashboard turns red when it happens.
Certified and Broken at the Same Time
The strongest evidence that validation is not a security guarantee is the list of certified modules that shipped exploitable flaws for years, straight through the lab process.
ROCA (2017): A flaw in Infineon's RSA key generation produced primes with a fixed structure that made 1024 and 2048-bit keys practically factorable from the public key alone. The affected library had shipped in chips since at least 2012, in devices holding FIPS 140-2 and Common Criteria EAL5+ certifications. The flaw sat inside the exact function the validation exists to scrutinize—key generation—and the process caught nothing for five years. Estonia suspended its national ID cards over it.
EUCLEAK (2024): A non-constant-time modular inversion in Infineon's ECDSA implementation allowed private key extraction via electromagnetic side channel. NinjaLab's paper notes the flaw went unnoticed for 14 years and roughly 80 highest-level Common Criteria evaluations. Yubico's advisory confirms the YubiKey 5 FIPS Series and YubiHSM 2 FIPS were affected. Because YubiKey firmware is not field-upgradeable, the fix was replacing hardware.
Dual_EC_DRBG (2004-2014): For a decade, a suspected NSA-backdoored random number generator was a NIST-approved algorithm, validated into modules by the same program that validates everything else. It was the default RNG in RSA's FIPS-validated BSAFE library. NIST removed it from SP 800-90A in 2014 after the Snowden documents forced the issue. Every certificate covering those modules was accurate the entire time: the algorithm was approved, and it was implemented correctly.
YubiKey FIPS Series (2019): This one deserves a special place, because the FIPS requirements did not merely fail to catch the flaw—they caused it. In firmware 4.4.2 and 4.4.4, the buffer holding random values after power-up contained predictable content left over from the FIPS power-up self-tests: up to 80 predictable bits in ECDSA operations that use 256-bit nonces, which is well inside practical key-recovery territory. The issue existed only in the FIPS series. The ordinary consumer YubiKey was fine. Yubico recalled and replaced the affected government keys. The FIPS-certified product was measurably less secure than the uncertified one on the same shelf.
Validation Freezes What It Touches
The lab process is a one-time paper exercise against a snapshot, and the snapshot is expensive to retake. The CMVP queue has historically run twelve to eighteen months from submission to certificate. NIST had to invent an interim validation scheme just to work through the backlog, as Ubuntu's FIPS team describes from the inside.
That lag creates a perverse choice every vendor of validated modules eventually faces: ship the security fix now and fall off the validated list for a year or more, or keep shipping the validated build with the known flaw. Customers whose contracts require an active certificate are, in effect, paying the vendor to choose the second option. The 2019 YubiKey incident shows the mechanism plainly: the fixed firmware existed, but replacements could only ship once NIST granted certification for the new version. A certificate can literally hold known-vulnerable code in the field.
Go as a Case Study
Go is the cleanest case study of what the freeze costs. For years, Go had no validated path except Go+BoringCrypto: a cgo binding to BoringSSL's validated module, enabled with GOEXPERIMENT=boringcrypto, never officially supported, and maintained essentially for Google's internal needs. It broke cross-compilation, added foreign-function overhead, and punched a hole through Go's memory safety into C. Red Hat and Microsoft each maintained their own forks binding OpenSSL and Windows CNG instead, so "FIPS-compliant Go" meant three different unofficial toolchains.
Go 1.24 finally shipped a native Go Cryptographic Module, written by Geomys with the Go security team, validated as CMVP certificate #5247 in pure memory-safe Go with no cgo. And then the freeze reasserted itself: the certificate covers module v1.0.0, a snapshot frozen from Go 1.24, while the v1.26.0 module sits on the Modules In Process list. A Go binary built today against the certified module runs cryptography code two major releases old. That is not a Go failure. That is the system working as designed.
What FIPS Actually Dictates, and What It Costs
CAVP testing verifies implementations against known-answer test vectors, so a validated module computes AES and SHA-2 correctly. FIPS 140-3 additionally mandates behavior: an integrity self-check at startup, known-answer self-tests before first use, a pairwise consistency test (PCT) on every generated key pair, randomness drawn from an SP 800-90A DRBG seeded by an assessed entropy source, and parameter floors such as RSA at 2048 bits minimum and HMAC keys of at least 112 bits.
What FIPS does not dictate is the part that fails in practice. Nothing at the common validation levels requires constant-time code or side-channel resistance, which is how EUCLEAK's non-constant-time modular inversion lived inside certified silicon for 14 years. The standard pins down the arithmetic and the ritual around it, not the properties attackers actually exploit.
The one place where FIPS prescribes the how in real depth is randomness. In approved mode, raw hardware RNG output never touches a key: the noise source must pass a formal entropy assessment and run continuous health tests under SP 800-90B, its output may only seed an approved deterministic DRBG, and SP 800-90C, a decade in draft, prescribes how the two may legally be chained. Credit where due: this is the chapter of the standard most worth stealing from, because a mandatory entropy assessment is entropy provenance documentation. It is no accident that the catastrophic entropy failures keep happening in consumer hardware that sits outside any validation program. But the same chapter carries the program's darkest irony: for a decade the approved-DRBG list included Dual_EC_DRBG, and the 2019 YubiKey bug lived inside the mandated self-test machinery itself. The health tests catch a stuck or grossly biased source, not a subtle one.
The mandated ritual has a measurable price. Since Go 1.24 can flip FIPS mode with an environment variable, the same binary on the same machine makes a clean experiment. Numbers from my workstation (Go 1.25.1, GODEBUG=fips140=on versus off); the absolute times wobble with CPU frequency scaling between runs, but the ratios are consistent:
| Operation | Normal | FIPS mode | Cost |
|---|---|---|---|
| ECDSA P-256 keygen | 17 µs | 110 µs | 6-9x slower |
| crypto/rand 32 bytes | 85 ns | 355 ns | 3-6x slower |
| ECDSA P-256 sign | 34 µs | 30 µs | none |
| AES-256-GCM, 16 KiB | 5.8 µs | 5.0 µs | none |
The pattern is exactly what the standard predicts. Bulk symmetric crypto and signing are untouched: same implementation, no per-operation test. Key generation eats the PCT, a full sign-and-verify cycle per generated key (Go's own docs warn about this for ephemeral keys, which means TLS handshakes). Randomness pays for the DRBG construction on every read. None of this buys resistance to any attack; the PCT exists to catch a module that generates corrupt keys, a failure mode with essentially no field history, while the side channels that actually extracted keys from certified devices remain out of scope. There is also a quieter performance tax: approved mode forbids faster modern algorithms outright, so no ChaCha20-Poly1305 on hardware without AES acceleration, no Argon2 for password hashing, regardless of technical merit.
The 90 Percent Who Turn It Off
Back to the statistic this article opened with: nine out of ten buyers of FIPS-enabled HSMs run them with the mode off. It is one anecdote from one vendor, but the mechanism behind it is documented in public product manuals, and in the digital-asset industry it is structural: the algorithms that cryptocurrency runs on are not FIPS-approved and mostly cannot be.
Bitcoin and Ethereum sign with ECDSA over secp256k1, a curve NIST left out of the approved set. When commenters on the FIPS 186-5 draft asked for secp256k1 to be added, the request was denied. So any HSM that needs to sign Bitcoin transactions must run outside FIPS mode. The certificate is irrelevant to the actual security of those keys—the HSM's physical security and key management matter far more.
What You Should Do Now
If you're in procurement, treat FIPS 140-3 as a floor, not a ceiling. Ask your vendor: What firmware version is validated? What configuration? What happens when we need to update? If the answer involves a year-long re-validation, plan for it.
If you're an engineer, don't flip FIPS mode on just because a checkbox exists. Audit your threat model first. If your adversary is a nation-state with side-channel capabilities, FIPS won't save you—constant-time code and hardware security will. If your adversary is a compliance auditor, FIPS is exactly what you need.
And if you're using Go, know that GODEBUG=fips140=on gives you the certified module, but you're running crypto code two releases old. Weigh the performance cost and the freeze against your actual risk. The certificate is not the product.
