FIPS 140-3 is not a security guarantee, and auditors know it

A sales engineer at one of the major HSM vendors told me recently that over 90 percent of their 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 will 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, and modules on that list should no longer be included in new federal procurements. Procurement teams are spending this summer chasing vendors for FIPS 140-3 paper, and vendors are spending it in a validation queue. A lot of money and attention is flowing toward a certificate.So it is a good moment to say the quiet part out loud: a FIPS validation is an answer to a narrow question, and it is not the question most people think they are asking. The certificate 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. Treating the certificate as a proxy for those things is where real incidents live.None of this is an argument against FIPS. The program killed off a generation of snake-oil crypto, and “no validation, no purchase” remains a sensible procurement floor. The argument is about what the certificate covers, because the gap between what it covers and what people believe it covers is remarkably consistent, and remarkably well documented. Along the way: a certified YubiKey that was weaker than the consumer model on the same shelf, a benchmark of what FIPS mode actually costs, and a four-line Go program that cannot derive a Bitcoin wallet without panicking.What the certificate actually saysFIPS 140-3 validation applies to the cryptographic module boundary: the algorithms are approved and correctly implemented, keys can be zeroized, the module runs power-up self-tests, and, at levels 2 through 4, the hardware resists or responds to physical tampering. That is the whole scope. The application calling the module, the access control around it, the key management policy, the humans holding the 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 an exact 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. In my experience 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 timeThe 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, and 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, and 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 touchesThe 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, long enough that 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 is the cleanest case study of what the freeze costs, because the whole history is public. 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, all to satisfy a certificate. 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.This is also why “FIPS mode” on an operating system or appliance deserves less reverence than it gets. Flipping it typically restricts the algorithm set and swaps in the validated (older) crypto provider. It changes which box an auditor ticks. Whether it changes your actual risk depends entirely on what your threat model was, and for most estates the honest answer is that nobody checked.What FIPS actually dictates, and what it costsA fair question at this point: does FIPS at least force algorithms to be implemented well? Partly. 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. Hold that last number; it returns below.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, and a silent fallback to a weak generator, the failure that emptied Coldcard wallets this summer, is exactly what that regime exists to surface. 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, because prescribing the how only helps when the prescription is sound: 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, and no amount of paperwork substitutes for knowing where