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

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 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 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, 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 costs

A 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 your randomness came from.

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:

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, running 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 it, NIST responded that it “does not believe that the secp256k1 curve offers compelling advantages over the NIST-recommended curves,” while conceding SP 800-186 would allow its use “for blockchain and DLT-related applications.” Allowed-for-blockchain is not approved, and vendors implement accordingly: AWS CloudHSM offers secp256k1 and Ed25519 signing only on non-FIPS-mode clusters, and the mode is fixed at cluster creation. The rest of the stack is no better off. Ethereum’s Keccak-256 predates the padding change that became standardized SHA-3, so it is not the approved FIPS 202 function despite the family name. RIPEMD-160, in every Bitcoin address, was never approved. A custody operator who flips their HSM into approved mode locks themselves out of the assets they exist to hold. So they buy the FIPS-enabled SKU for the procurement checkbox and run it with the mode off, at which point the certificate describes a configuration they do not operate.

The incompatibility runs deeper than curve selection, down into constants chosen years before anyone thought about compliance. BIP32, the standard for hierarchical key derivation behind effectively every wallet, derives its master key as HMAC-SHA512 with the literal string "Bitcoin seed" as the key. That string is 12 ASCII characters: 96 bits, below the 112-bit HMAC floor. I hit this trying to implement BIP32 under Go’s FIPS mode, and it reproduces in four lines:

// BIP32 master key derivation (test vector 1)
seed, _ := hex.DecodeString("000102030405060708090a0b0c0d0e0f")
mac := hmac.New(sha512.New, []byte("Bitcoin seed"))
mac.Write(seed)
I := mac.Sum(nil) // left half: master key, right half: chain code

$ GODEBUG=fips140=only go run bip32.go
panic: crypto/hmac: use of keys shorter than 112 bits is not
allowed in FIPS 140-only mode

In the default fips140=on mode the code still runs, because Go only guarantees approved behavior for approved operations; the strict only mode is what surfaces every non-approved call, and it fails on the first step of the first derivation. There is no workaround, because the “key” is a protocol constant: change it and you derive different wallets. The entire BIP32 tree, and everything above it (BIP39, BIP44, every hardware wallet and custody platform), is unimplementable as an approved service. Not because the construction is weak: HMAC-SHA512 with a public constant key is being used as a KDF here, and the seed provides the actual entropy. It fails because a rule written for secret authentication keys is being applied to a constant that was never one. The compliance framework cannot see the difference, and that, in miniature, is the whole argument of this article.

Where auditors actually spend their time

Here is the part the title promises. Sit through enough custody and key-management audits and a pattern emerges: a competent auditor accepts the FIPS certificate in about thirty seconds. It is one line in the evidence request, satisfied by a certificate number they can look up themselves. Then they spend hours on questions the certificate cannot answer:

1. Configuration versus certificate. Is the module running the validated firmware version, in approved mode? Can you show attestation output proving it, or is the answer “it was when we installed it”?

2. Key provenance. Who generated the keys, when, witnessed by whom, and can you demonstrate the private key never existed outside the module boundary? A validated HSM holding a key that was generated on someone’s laptop and imported is a very expensive way to store a compromised key.

3. The humans around the box. Where are the operator cards, who holds quorum shares, what is the dual-control procedure, and what happened to the shares held by the engineer who left in March? The module enforces M-of-N; it has no opinion on whether N people still work here.

4. Backup and cloning. Key backup, replication, and cloning procedures live largely outside the FIPS boundary, and they are where keys actually leak. The certificate is silent on the tamper-evident bag in the safe.

5. Policy versus logs. The written key management policy says ceremonies are witnessed and logged. Do the logs from the last ceremony actually show that, or does the record consist of a Word document, a camcorder file nobody can locate, and the memory of whoever was in the room?

Notice what that list has in common: every item is about process and evidence, not about the module. The auditors are not being contrarian. They have simply read the same incident history as everyone else and drawn the obvious conclusion about where failures happen. The module is the strongest link in the chain. Auditing the strongest link is a poor use of a day rate.

What to do with this

Treat the certificate as what it is: a hardware selection floor and one line of evidence, not a conclusion. Then put your effort where the audit findings and the incident history point:

• Buy validated, then know what you actually run. The certificate covers one firmware and one mode, and your fleet will drift from both. Attest against your intended configuration on a schedule, not once at install, whether that intended configuration is the validated one or a documented departure from it.
• Make ceremonies produce evidence, not folklore. Generation-time records of who did what, witnessed by whom, with what entropy, on which firmware. A property you cannot verify after the fact must be evidenced at creation, and key provenance is exactly such a property.
• Track the lifecycle, not the purchase. Quorum composition, share custody, departures, backup locations, rotation history. This is the material an auditor will actually read, and the material that determines whether a compromise is an incident or a catastrophe.
• If you run FIPS mode off, say so in writing. For digital-asset workloads that is usually the only workable choice, and it is defensible: document which non-approved algorithms you depend on and why, and stop citing the certificate as if it still applied. An auditor who finds the mode disabled next to a policy that brags about FIPS validation has learned something worse than either fact alone.
• Watch the transition dates with detachment. The September 21 cutover moves certificates between lists. It moves nothing else. If your security posture changes meaningfully that day, the certificate was carrying more weight than it could bear.

FIPS validation answers one question well: is this module a competent implementation of approved cryptography? Every incident in this article happened in the space that question does not reach, and the auditors’ checklist is a map of that space. The certificate belongs in the evidence folder. It just should not be the only thing in it.