808bits

FIPS 140-3 levels 1 to 4: what each level actually requires

2026-09-01 · 9 min

Every custody RFP I have seen in the last six years contains some version of the same sentence: “keys shall be protected by an HSM validated to FIPS 140-2 Level 3 or higher.” Here is what the people writing that sentence usually do not know: of the 773 FIPS 140-3 certificates issued as of this writing, the number validated at Level 4 is zero. “Or higher” is an empty set. The sentence means Level 3, has always meant Level 3, and would keep meaning Level 3 even if the author wrote Level 4, because nothing you can buy would satisfy it.

That is worth knowing before September 21, when every remaining FIPS 140-2 certificate moves to the historical list and procurement teams start rewriting these sentences for 140-3. So this is the guide for the rewrite: what each level actually requires, what the distribution of real certificates looks like, and which words to put in the requirement so you get the property you wanted instead of the number you asked for.

The levels are a minimum function, not a grade

FIPS 140-3 is ISO/IEC 19790:2012 adopted as a US federal standard, with NIST’s modifications published in the SP 800-140 series. The standard defines eleven requirement areas: module specification, interfaces, roles and authentication, software/firmware security, operational environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks. Each area is rated 1 through 4 independently, and the overall level is the lowest rating across all areas.

Two consequences follow. First, a module can carry Level 4 physical security and still be an overall Level 3 certificate because one other area tested at 3. Second, the headline number on a datasheet compresses eleven ratings into one, and the interesting information is in the per-area table on the certificate itself, not in the compression. When a vendor says “Level 3,” the correct follow-up is “in which areas.”

Here is how the 773 FIPS 140-3 validations issued so far distribute (shares rounded):

Overall levelCertificatesShare
Level 156974%
Level 214419%
Level 3608%
Level 400%

Three quarters of everything validated is Level 1, the level with no physical security requirements at all. Keep that in mind when a compliance matrix treats “FIPS validated” as one checkbox.

Level 1: the algorithms are implemented correctly

Level 1 requires that the module implement at least one approved security function, use production-grade components, run its self-tests, zeroize keys on demand, and have a defined cryptographic boundary. There is no tamper protection beyond production-grade parts, no requirement to authenticate operators, and the module may run on an ordinary modifiable operating system.

This is where software lives. The Go Cryptographic Module (#5247), Apple’s corecrypto (#4391), and Ubuntu’s OpenSSL module (#4794) are all overall Level 1, and correctly so: a shared library on a general-purpose OS has no enclosure to seal and no door to alarm. A Level 1 validation is not nothing. It means the algorithms passed CAVP known-answer testing, the RNG chain follows SP 800-90, and a lab confirmed the boundary and self-test behavior. What it does not mean is any resistance whatsoever to someone with access to the machine.

The practical reading: for a software product, Level 1 is the norm and the ceiling worth demanding. A procurement rule that requires Level 2 or higher from a software vendor is really a rule requiring hardware, and it should say so directly.

Level 2: evidence of tampering, and roles

Level 2 adds two things. Physically, the module must show tamper evidence: seals, coatings, or an opaque enclosure such that opening it leaves a visible trace. Note the verb. Nothing at Level 2 resists or reacts to the intrusion. The requirement is that you can tell afterwards, if you look. Operationally, the module must support role-based authentication: an operator authenticates as a role, typically crypto officer or user, before using protected services.

Under 140-2, software essentially could not reach Level 2 because the operational environment had to be a Common Criteria evaluated OS in a specific configuration nobody ran. 140-3 relaxed that, so overall Level 2 software certificates now exist, though the population is small.

Level 2 is also where the dataset teaches its best lesson about what a level is. The YubiKey 5 holds two FIPS 140-2 certificates for the same module: #3907 at overall Level 1 and #3914 at overall Level 2. Same hardware, same firmware family, two levels. The level is not a property of the metal. It is a claim the vendor chose to have tested, scoped and priced accordingly. The AWS KMS HSM tells the same story over time: it carried Level 2 certificates for six years while holding a meaningful share of the world’s regulated keys, then revalidated at 140-2 Level 3 (#4523) and now 140-3 Level 3 (#4884). The hardware did not transform in 2023. The scope of what was tested did.

Level 3: the HSM tier

Level 3 is where the requirements start describing what most people picture when they say “HSM,” and it adds substance in four places:

  1. Tamper resistance and response. The enclosure must be strong or the circuitry embedded in hard potting material, and removable covers and doors must trigger tamper response: the module detects opening and zeroizes its keys. Detection and destruction, not evidence after the fact.
  2. Identity-based authentication. The module authenticates the individual operator, not just the role. This is the requirement behind operator cards and per-person credentials, and it is what makes M-of-N quorum enforcement meaningful: the module knows there are N distinct identities, not one shared password used by N people.
  3. Protected key entry and output. Plaintext secret keys may only cross the module boundary through a trusted channel or using split-knowledge procedures. This single requirement is why key ceremonies at Level 3 involve smartcards and component holders instead of someone pasting a hex string into a console.
  4. Environmental protection. New in 140-3 at this level: the module needs environmental failure protection or testing (EFP/EFT) for voltage and temperature, so an attacker cannot glitch it outside its operating envelope to bypass protections. Under 140-2 this was Level 4 material.

The Level 3 population is exactly who you would expect: Thales Luna K7 (#4684), Entrust nShield 5s (#4745), YubiHSM 2 (#5302), and the cloud HSMs built on similar silicon. Sixty certificates out of 773. When an RFP says Level 3, this shelf is the entire market it is selecting from.

Level 4: the tier nobody ships

Level 4 requires a tamper detection and response envelope around the whole module: penetration from any direction, not just through covers and doors, must be detected and answered with immediate zeroization. EFP becomes mandatory rather than an EFT alternative, protection against fault induction attacks is required, and 140-3 added a requirement that operator authentication be multi-factor identity-based.

And then there is the market’s answer: zero FIPS 140-3 certificates. In the entire history of the program the tracker shows 19 overall Level 4 certificates under 140-2 and 9 under 140-1, and the active 140-2 entries are essentially one product line, IBM’s cryptographic coprocessors for its mainframes, such as the IBM 4769 (#4079) and IBM 4770 (#4558). Those certificates are 140-2, so they move to the historical list with everything else on September 21, and from that day on there will be zero active Level 4 certificates under any standard. The economics are straightforward: a Level 4 validation costs dramatically more to design and test, no regulatory framework requires it, so outside one captive mainframe ecosystem nobody pays for it. If your policy says “Level 3 or higher,” you have written a poetic way of saying Level 3.

What no level requires

The levels ladder measures physical and procedural robustness of the module. It is worth being precise about what is absent from every rung.

Side-channel resistance is effectively untested at every level. Non-invasive security is one of the eleven areas, and the standard points at test metrics (ISO 17825) that CMVP has not put into force, so in practice the area carries documentation rather than laboratory attack testing. Timing and electromagnetic leakage extracted keys from certified silicon for years, at every level buyers actually use, and EUCLEAK went unnoticed through roughly 80 Common Criteria evaluations. A Level 3 certificate does not mean the ECDSA implementation is constant-time. It has never meant that.

The level does not certify your randomness is good, only that the plumbing is approved. The YubiKey 4 FIPS module was an overall Level 2 certificate, #3204, one of only 25 certificates in the dataset marked revoked, pulled in the wake of the 2019 incident where the FIPS-mandated self-tests themselves left predictable bits in the RNG buffer. The level described the enclosure and the roles accurately the whole time.

And nothing at any level covers the world outside the boundary: the application calling the module, the people holding the cards, the backup in the safe, the ceremony that loaded the first key. I have written a separate article on that gap, because it is where the actual incidents live.

The four levels on one screen

Level 1Level 2Level 3Level 4
Physical securityProduction-grade partsTamper evidence (seals, opacity)Tamper response: covers and doors zeroize keysDetection envelope: any penetration zeroizes
AuthenticationNone requiredRole-basedIdentity-basedMulti-factor identity-based
Plaintext key I/OAllowedAllowedTrusted channel or split knowledge onlyTrusted channel or split knowledge only
Environmental (voltage/temp)No requirementNo requirementEFP or EFTEFP mandatory, plus fault induction protection
Who actually lives hereSoftware librariesTokens, appliances, some softwareHSMsIBM mainframe coprocessors, ~nothing else

What to write in the requirement

  • For software, require Level 1 and stop. Demand the certificate be active and the version you deploy be the version on it, which is the harder and more valuable check.
  • For hardware key storage, require overall Level 3. Drop “or higher,” it buys nothing and signals the author has not looked at the certificate population. If you care about a specific property, name the area: “physical security tested at Level 3” or “identity-based operator authentication” says what you mean even when the overall number cannot.
  • Read the actual certificate, not the datasheet. The per-area levels, the exact firmware versions, and the caveats are all on the NIST entry, and the caveat line is where claims quietly narrow. “When operated in approved mode” is doing a lot of work on most certificates.
  • Check the standard and the date. After September 21, a 140-2 certificate at any level is a historical document. Level 3 on the historical list is not “almost as good” for new procurement, it is the thing your own RFP language probably excludes.

The levels are real, and the jump from 2 to 3 in particular buys concrete, physical properties that matter for custody: keys that die when the box is opened, operators the module can tell apart, key material that cannot legally cross the boundary in the clear. Just read the number as what it is, the floor across eleven separate ratings, attached to one firmware version, silent about side channels and about everything outside the boundary. It is a fine floor. It was never the building.