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

FIPS 140-3 is not a security guarantee, and auditors know it 2026-08-05 · 14 min 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 says FIPS 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 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