What is FIPS 140-3 validation?

FIPS 140-3 is the US and Canadian government standard for validating that a cryptographic module correctly implements approved algorithms and meets a defined security bar. It exists to give buyers, originally federal agencies, assurance before they procure. It is widely referenced, expensive and slow to obtain, and frequently misunderstood. This site reads the public validation record for a near-census of modules to make what a certificate does and does not cover concrete.

What FIPS 140-3 validates

The standard (aligned with ISO/IEC 19790) is run by the CMVP, jointly operated by NIST in the US and the CCCS in Canada. A validation covers a defined cryptographic module: a specific boundary of hardware, software, or firmware, at one of four security levels. Within that boundary it confirms the module implements NIST-approved algorithms correctly (through the separate CAVP program), enforces an approved mode of operation, protects its keys, and runs its self-tests. Every validation names a specific module version, configuration, and operational environment.

Two things temper this. The boundary is the vendor's to draw: they decide what sits inside it, and can draw it wider to bring more of the product under validation, at the cost of a larger and more expensive evaluation. And what is examined inside the boundary is more than the algorithms. The validation grades the module across roughly a dozen requirement areas, and as the security level rises the scope expands outward from the mathematics into physical protection, tamper detection and response, and the controls around the keys, the areas the levels below describe.

The four security levels roughly escalate from “the cryptography is implemented correctly” to increasingly strong physical protection:

Who it was built for

FIPS validation is a procurement instrument. US federal agencies are required to use validated cryptography, so a certificate is largely the gate for selling cryptographic products into government, and into the regulated industries that inherit the requirement. It was designed as a purchasing bar and a point-in-time assurance record, not as a vulnerability-hunting tool. That origin explains much of its shape, and much of what people get wrong about it.

What it is commonly misunderstood to mean

Further reading on how these labels get conflated: TPMs, TEEs, and Everything In Between; and on what an HSM actually protects: HSMs Largely Protect Keys from Theft Rather Than Abuse.

What it costs

Validation is a multi-year, multi-party process, and much of the elapsed time is spent before a package reaches the review queue and after CMVP returns comments, not only in the government queue. The one relatively clean public benchmark is post-submission: KeyPair's 2024 analysis found an average of 579 days from CMVP receipt of the validation report to certificate issuance, roughly 366 days of review plus 213 of coordination. The phases below are best read as estimated elapsed time; only the post-submission rows are anchored to that benchmark.

The controllable areas are pre-submission readiness, documentation quality, evidence traceability, and comment-response speed; the least controllable is the CMVP pending-review queue itself. NIST's Modules in Process status definitions describe the same states, where the current action may sit with NIST, the lab, or the vendor. Money tracks time: accredited-lab fees plus the internal engineering to scope, remediate, and evidence a module make validation a substantial investment well before the certificate is posted.

This lag is now a live constraint on the post-quantum transition. Google has said it wants to be post-quantum ready by 2029, and a recent White House executive order set a 2030 federal target, five years earlier than the prior goal. Yet at the time of writing (July 2026) not a single FIPS certificate has been issued for the core post-quantum algorithms, apart from ML-KEM used in TLS and SLH-DSA, whose utility so far is narrow and targeted. The time and cost of validation are themselves holding the rollout back. It is a bit like waiting on a permit in a big city: for months the answer has been “any day now,” with no firm date anyone can point to.

Certified once, attacked continuously

Validation is slow and static; the threat landscape is neither. For decades Patch Tuesday has delivered a steady stream of fixes, and the pace only accelerates as automated and AI-assisted discovery lowers the cost of finding bugs. The number of vulnerabilities disclosed each year keeps climbing, and attackers do not care whether a module holds a FIPS certificate; they care whether the deployed system can be broken into. A certificate frozen at a 2024 version says nothing about the patches that shipped after it.

The public CVE count also understates the churn. A single CVE can cover many distinct issues, and many issues are fixed quietly, in a release or a firmware update, with no CVE ever assigned. So “no CVEs against the certified version” is not the same as “nothing changed that a reviewer should reconcile.”

The code under that pressure is rarely memory-safe. These modules, including the parts that parse messages from the outside world, are typically written in C, so a single mistake in handling a malformed input can put an attacker inside the security perimeter. Parsers are a classic way in; so are forgotten capabilities left enabled and never tightened down. The larger and more complicated the module's inner workings, the more surface there is for one of these to hide in.

The modules where this matters most are often the hardest to inspect. Much of the assurance around HSMs rests on obscurity rather than transparency: firmware is obfuscated, binaries and documentation sit behind paywalls and support licenses, and access to the devices is gated by cost. Independent review is difficult, which is part of why the public CMVP record, what this corpus reads, is often all an outsider has to work with.

And under the hood many of these devices are modest: a Linux server with a PCI-e cryptographic card, where only a small surface of that card sits inside the validated envelope. The certificate covers that envelope. The operating system, the drivers, the management plane, and everything else around it are not what was validated, which is exactly the boundary shown above.

What is actually being protected

The cryptography is rarely what breaks. What gets attacked is how the keys are held and how they can be used, and physical theft of a rack-mounted HSM is rarely the real vector. The datacenter around it, with its own access, personnel, and monitoring controls, is usually the true physical protection. Physical theft matters far more for the small devices you can pocket, such as smart cards and cryptocurrency wallets.

The objective security an HSM buys is getting the key material out of the application's process and into a separate protection domain, so compromising the application does not directly hand over the key. Just as often, the reason to introduce one is the administrative boundary it creates. The device runs its own identity and authentication subsystem, frequently built on smart cards, with its own operators and roles, so using or managing the keys means crossing into a separate domain of control. That is as much a defense against insider misuse, and a way to enforce separation of duties, as it is a barrier to an outside attacker. But that only helps if the device is not simply a signing oracle. If an attacker who reaches the application can ask the HSM to sign arbitrary data, the key never has to leave. In the DigiNotar compromise, reportedly the work of Iran-affiliated attackers targeting dissidents, the intruder used a certificate authority's signing capability to mint hundreds of fraudulent, publicly trusted certificates and, according to Fox-IT's investigation, intercept the encrypted traffic of Iranian internet users, simply by asking the device to sign.

Stronger designs move production of the signed object inside the device and constrain what it will do: a single-purpose transaction model rather than a general oracle. Cryptocurrency hardware wallets are the clearest example. A sign-transaction API where the device enforces the amount, the destination address, and other parameters means an online attacker cannot pull out arbitrary signatures, which the oracle model cannot prevent. A FIPS certificate speaks to the module's cryptography and physical protection, not to which of these usage models it implements, and that choice is often where the real security lives.

Where this corpus fits

A FIPS certificate is an unexpectedly rich source of architectural intelligence.

If you read enough Security Policies, you can start to understand how the industry actually builds cryptographic systems.

This static site reads the public CMVP certificates and Security Policies for the FIPS 140-3 modules validated in a certificate-number sweep of FIPS 140-3 modules. It turns the abstractions above into something you can inspect: what a given module actually had validated, how long its certified state has stood, and where the public record stops and vendor or deployment evidence would have to take over.

What we observed across the corpus

Findings across the FIPS 140-3 modules validated in cert window #4650 to #5159, a near-census rather than the complete FIPS 140-3 population. Absence of a successor or update entry does not prove none exists.

The timeline is estimated elapsed time, strongest for the post-submission phases and industry-estimate elsewhere. Corpus figures are deterministic extractions from public CMVP and NVD data; they are review prompts, not vulnerability findings.