Marin Ivezic
On September 21, 2026, every remaining FIPS 140-2 certificate moves to NIST’s historical list, the final stage of the Cryptographic Module Validation Program (CMVP) transition schedule. Nothing about those modules changes that day. What changes is that an architecture document reading “encryption provided by a FIPS 140-2 validated module” stops describing a current validation and starts describing a lapsed one, and the auditor asking about it in 2027 will want to know which certificate replaced it.
That deadline is forcing a lot of architects to look properly at certificates they had previously taken on trust.
The recurring problem in design reviews isn’t that vendors lie. It’s that “our product is FIPS 140-3 certified” is a sentence with no error bars on it, and three follow-up questions usually take it apart. Which module holds the certificate? Which version of that module, and is it the version you’re shipping? Which operating system and hardware was it tested on, and is that yours? A validation certifies one named module, at one named version, tested in one or more named environments, running in one defined mode. It does not certify the product wrapped around the module, it does not certify your deployment, and it says nothing about whether the code path your application actually takes goes through the validated component at all.
This piece is about reading that certificate.
What FIPS 140 Actually Covers
FIPS 140 is a U.S. federal standard that sets security requirements for cryptographic modules. A cryptographic module is the specific piece of hardware, firmware or software that performs the cryptographic work: generating keys, encrypting, signing, hashing, producing random numbers. It’s a component, not a product. A VPN appliance is a product; the chip or firmware library inside it that does the AES is the module.
The standard is old and has been revised twice; it is now in its third version. FIPS 140-1 was issued in January 1994, FIPS 140-2 in May 2001, and FIPS 140-3 was approved in March 2019 and took effect that September. NIST develops it, and the validation programme behind it is run jointly with Canada, which is why a single certificate carries weight on both sides of the border.
What the standard demands is broader than most people expect, and this is the part worth internalising. It is not a list of approved algorithms with a test suite attached. Under FIPS 140-2 the requirements were organised into eleven areas, and FIPS 140-3 reorganised rather than replaced them. The areas cover the module’s own specification and documentation, its ports and interfaces, the roles and services it offers and how it authenticates the people or processes using them, the physical protections around it, the operating environment it runs in, the full lifecycle of its keys from generation to destruction, its electromagnetic behaviour, the self-tests it runs at startup and during operation, the discipline of its development process, and any countermeasures it carries against attacks the standard doesn’t otherwise address.
Read that list again with an architect’s eye and the shape of the thing becomes clear. Roughly two of the eleven areas concern the algorithms. The rest concern whether the module is built, documented, operated and defended in a way that lets the algorithms do their job. That emphasis matches where cryptographic failures actually come from. AES has not been broken. Key material sitting in a swap file, a random number generator seeded from a predictable source, a signature verification routine that returns success on a parse error, a firmware update path with no integrity check: those are the failures, and they are what the other nine areas are pointed at.
The Four Levels, and What Each One Buys
FIPS 140 defines four security levels, and each area of the standard has requirements at each level. A module’s certificate can show different levels in different areas, though it is normally summarised by the lowest one it meets overall.
Level 1 requires approved algorithms, correct implementation and the self-tests, with no physical security requirements beyond production-grade components. Almost every validated software library sits here. A Level 1 software module running on a general-purpose server assumes the server itself is protected by other means, which is a reasonable assumption in a data centre and a poor one in a field-deployed cabinet.
Level 2 adds role-based authentication and tamper evidence: coatings, seals, an enclosure that shows when it’s been opened. It tells you nothing was quietly extracted without leaving a mark. It does not stop the extraction.
Level 3 requires identity-based authentication, requires logical or physical separation between the interfaces carrying plaintext keys and the module’s other interfaces, and requires the module to actively respond to tampering by zeroising its keys. This is the level most dedicated hardware security modules target. Level 2 tells you the case was opened; a Level 3 module zeroises its keys before the extraction succeeds.
Level 4 assumes a determined attacker with the device in hand and a laboratory behind them. It requires detection and response across the full physical envelope, including environmental attacks that push voltage or temperature outside the module’s stated operating range to induce faults.
The practical guidance we give architects is to pick the level from the threat model rather than from the procurement template. A Level 3 HSM protecting a root signing key that never leaves a locked cage is proportionate. A Level 3 requirement written into a specification for a service running in a cloud region you don’t control is a requirement that will be met on paper and defeated by the deployment.
Who Actually Does the Testing
NIST does not test modules. That single fact explains most of the terminology confusion around FIPS.
Testing is done by independent commercial laboratories, accredited as Cryptographic and Security Testing laboratories (CSTLs) under NIST’s laboratory accreditation programme. A vendor contracts a lab, hands over source code, design documentation and hardware, and the lab works through every applicable requirement area, running the module against NIST’s test vectors, reading the code, inspecting the enclosure and watching the self-tests fire.
Underneath module validation sits algorithm validation, and the two are separate programmes. The Cryptographic Algorithm Validation Program (CAVP) tests individual algorithm implementations against known-answer vectors and issues its own certificates. A module can hold CAVP certificates for its AES and its SHA-2 and still have no module validation at all, which is a distinction some vendor datasheets are happy to blur. Algorithm certificates say the mathematics is right. Module validation says the mathematics is wrapped in something that keeps the keys safe.
There’s a third piece under FIPS 140-3 that catches people out. Entropy sources now need their own validation, assessed against NIST’s guidance on random bit generation. A module that generates keys needs to demonstrate where its randomness comes from and how much of it there is. Modules have been held up in the queue for months on entropy alone.
When the lab is satisfied it submits a report to NIST and to the Canadian Centre for Cyber Security, part of the Communications Security Establishment. Both review it. If the review passes, a certificate is issued and the module appears on the public validated modules list, which is searchable at the CMVP project pages on csrc.nist.gov. That list is the only authoritative record. A logo on a datasheet is not evidence, a letter from a lab is not evidence, and “validation in progress” is a real programme status with real stages but it is not a certificate.
This is also the origin of the word validated. NIST validates the lab’s findings and issues a certificate; it does not certify the product. In casual speech “FIPS certified” and “FIPS validated” mean the same thing, and nobody will correct you in a meeting. In a contract they are not the same thing, and the word that matters is the certificate number.
The Boundary Is the Whole Question
Every validated module has a cryptographic boundary: an explicitly defined perimeter, drawn by the vendor and accepted by the lab, that separates what was tested from what wasn’t. Everything inside is validated. Everything outside is your problem.
The boundary is where most misunderstandings live, and it can be drawn tightly or loosely. A vendor can validate a small, stable core of algorithm implementations and key handling, leave the protocol logic and the network stack outside, and then ship a large product around that core. Nothing about that is improper. It’s the normal engineering trade, because a small boundary is cheaper to validate and far cheaper to revalidate when the product changes. But it means the certificate covers a slice of the product, and the interesting security questions often live in the slice that isn’t covered.
Two consequences follow for anyone doing design review.
First, ask what’s inside. The security policy document, which we’ll come to in a moment, states the boundary in plain terms and usually includes a block diagram of it. Read that diagram before you accept the claim.
Second, ask how the rest of the product reaches the module. A product can contain a perfectly good validated module and still perform some of its cryptography elsewhere: a convenience library used by one subsystem, a hash function implemented inline because it was faster, a legacy protocol path that predates the module. The certificate cannot tell you about any of that. Only the vendor’s own documentation of which operations go through the module can, and that is a fair question to put in writing during procurement.
Reading a Certificate
The validated modules list is public and every entry has the same fields. Working through them in order takes about five minutes and settles most arguments.
Module name and version. The version is the binding part. Validation attaches to a specific build, so “OpenSSL FIPS Provider” is not an answer and a version string is. If the vendor has shipped a later version than the validated one, they are shipping something that was not validated, regardless of how minor the change was.
Module type and embodiment. Software, firmware, hardware, or hybrid, and whether it’s a single chip, a multi-chip embedded component or a standalone appliance. This tells you what the physical security requirements were actually applied to.
Overall level, and level by area. Look for the per-area breakdown rather than the headline. A module can be overall Level 1 while meeting Level 3 in roles and authentication, and a module described as “Level 3” in a datasheet may have that level in physical security and nothing else.
Operational environments tested. For software and firmware modules, this is the field that catches people. Validation was performed on named operating systems and named hardware. Running the same module on a different platform puts you in vendor-affirmed territory: the vendor asserts the module still behaves correctly, no lab tested it there, and the affirmation carries no certificate. Some federal buyers accept vendor affirmation and some don’t. If your target platform isn’t in that field, you need to know your customer’s position before you commit to the architecture.
Approved algorithms. The certificate lists exactly which algorithms were validated and, importantly, in which modes and key sizes. A module validated for AES-256 in GCM was not thereby validated for AES-256 in XTS. If your design depends on a specific mode, check that the mode is on the list.
Caveats. A short line, easy to skip, that carries conditions on the validation. It’s the place where a restriction like “no assurance of the minimum strength of generated keys” appears, and that restriction changes what the module can be relied on for.
Security policy. A public document, written by the vendor to a prescribed structure and reviewed as part of the validation, describing how the module meets each requirement, where the boundary sits, what roles and services exist, and how to place the module in its approved mode of operation. It is the single most useful artefact in the entire process and it is free. Anyone specifying a validated module in an architecture should have read the security policy for that module.
FIPS Mode Is a Deployment Decision
Most validated software modules can run in more than one way. FIPS mode is a configuration state in which the module restricts itself to approved algorithms and services, runs its startup self-tests, and refuses operations that fall outside the validated set. Outside FIPS mode, the same code will happily do things the certificate doesn’t cover.
So the certificate is necessary and it isn’t sufficient. A system built on a validated module, deployed with FIPS mode off, is using unvalidated cryptography from a validated module. That is a configuration failure rather than a procurement failure, which is precisely why it survives procurement.
Turning FIPS mode on has consequences worth planning for, and they’re the reason it gets turned off again. Non-approved algorithms stop working, which breaks integrations with anything still using MD5 for a checksum or a legacy cipher suite for backward compatibility. Self-tests add startup latency. Some applications call cryptographic functions directly rather than through the platform’s provider interface and simply bypass the mode entirely. Each of these is manageable if it’s discovered in design and painful if it’s discovered in a compliance audit.
Three questions belong in the design record for any system with a FIPS requirement: which module, configured in which mode, and how do we test that the mode is actually in effect at runtime.
What Changed Between 140-2 and 140-3
FIPS 140-3 is best understood as an alignment rather than a rewrite. Where 140-2 was a self-contained U.S. document, 140-3 adopts the international standards ISO/IEC 19790:2012 for the security requirements and ISO/IEC 24759:2017 for the testing, with a series of NIST special publications layered on top to specify the U.S. and Canadian additions. A module built to 140-3 is, broadly, a module built to the international baseline.
The substantive changes are incremental and pointed in sensible directions. Non-invasive attacks, meaning side-channel techniques such as power analysis and timing analysis, get their own treatment. Software and firmware integrity requirements are tightened. Key management is generalised into the handling of sensitive security parameters, which covers keys and also the other secret and public values a module has to protect, such as authentication data and seeds. The finite state model, which under 140-2 was its own requirement area, is folded into the specification requirements.
The programme mechanics matter more than the technical delta for most organisations. Testing against 140-3 opened in September 2020, the programme stopped accepting new 140-2 submissions in September 2021, and the remaining 140-2 certificates go historical on September 21, 2026. A module that never gets revalidated doesn’t stop working and doesn’t become insecure. It stops being citable.
The planning question that follows is a supply chain question. If your product inherits its validation from someone else’s module, your compliance status depends on their revalidation schedule and their commercial appetite for paying for it. That is worth asking about explicitly, in writing, before the answer becomes urgent.
Where Validated Modules Come From
Architects have three sourcing patterns available, and the choice has long consequences.
Validate your own module. Full control over the boundary, the certificate carries your organisation’s name, and you set the revalidation schedule. It is also expensive, slow, and a permanent commitment: every change inside the boundary triggers a change-management process with the lab, and organisations that take this route learn to draw the boundary around code they intend not to touch.
Use a validated third-party module. The common case, and the reason a small number of libraries sit underneath an enormous amount of software. Widely used cryptographic libraries in the open-source and commercial worlds maintain validated builds, operating system vendors validate the platform cryptography their applications call into, and cloud providers validate the modules behind their key management services. You get a validated core without running a validation programme. The certificate stays in the module owner’s name, which is usually fine and occasionally isn’t, because some government procurements want the certificate held by the product vendor.
Use the platform. Where the operating system provides validated cryptography and your application calls it through the platform’s provider interface, enabling the platform’s FIPS mode covers your application too. This is the cheapest route and the most fragile, because it holds only for as long as every code path goes through the platform provider. One dependency bundling its own crypto library breaks it silently.
A note on the libraries that aren’t validated. Several well-regarded modern cryptographic libraries have never gone through the process, and it’s a mistake to read that as a quality signal. Validation is expensive, slow and version-bound, and plenty of maintainers reasonably decline. What it means for an architect is narrower and firmer: if the requirement is FIPS compliance, an unvalidated library disqualifies itself no matter how good the cryptography is, and that constraint needs to be visible at design time rather than discovered at audit.
What Post-Quantum Does to All of This
NIST published the first post-quantum standards in August 2024: FIPS 203 for ML-KEM (formerly Kyber), the key encapsulation mechanism, FIPS 204 for ML-DSA (formerly Dilithium), the primary signature scheme, and FIPS 205 for SLH-DSA (formerly SPHINCS+), the hash-based signature alternative. A fourth signature standard, FN-DSA, has not been finalised. NSA’s Commercial National Security Algorithm Suite (CNSA) 2.0 names ML-KEM and ML-DSA for national security systems, which means federal demand for validated implementations is real and dated.
For anyone planning a migration, the FIPS 140 process is the constraint that determines when the algorithms become usable rather than merely available, and the sequencing is worth understanding.
An algorithm being standardised is the first step, not the last. Algorithm testing has to exist before implementations can be validated against it, and module validation follows algorithm validation. Then each module owner has to decide to add the new algorithms, submit for validation, and get through a queue that has been long for years. Every one of those steps sits between publication of the standard and the moment your architecture can cite a certificate listing ML-KEM.
Three implications for migration planning follow directly.
A library implementing ML-KEM is not the same as a module validated for ML-KEM. Implementations appeared well before standardisation, some of them against draft parameters that changed. The certificate’s approved-algorithm list is the only place the distinction is recorded.
Hybrid key establishment, combining a classical algorithm with a post-quantum one so the result is at least as strong as either, raises its own validation question, because what gets validated is the specific construction rather than the general idea. If your design depends on a particular hybrid scheme, the question of whether that construction is covered by an approved certificate is a question to ask early.
And the timing of your migration is partly outside your control. If you inherit cryptography from a platform or a third-party module, your earliest possible date for validated post-quantum cryptography is your supplier’s date, not yours. That belongs in the migration plan as a dependency with a named owner, alongside the inventory and discovery work that precedes it.
The architects who will handle this well are the ones who already know how to read a certificate, because the post-quantum transition asks the same questions the FIPS process has always asked, about boundaries, versions, environments and modes, against a moving set of algorithms and a compressed timeline.
Where to Take This Next
The skills in this article are the entry point rather than the whole job. Reading a certificate is a five-minute task once you know the fields. Deciding which level a system needs, writing the FIPS requirement into a specification so that it constrains the deployment and not just the purchase, tracing which code paths in a real architecture reach the validated module, and sequencing a post-quantum migration around suppliers’ revalidation schedules: those take structured work.
That is the ground our post-quantum cryptography certification program covers, and it’s built for architects and engineers who have to turn standards documents into deployable designs. You can see the current programs, the syllabus and the assessment format at quantumacademy.com/. For deeper technical background on the algorithms themselves, PostQuantum.com carries the long-form analysis, and the migration methodology sits at pqcframework.org.