up:: In the Protocols MOC

FIPS 140-3

FIPS 140-3 is the U.S. federal standard, titled “Security Requirements for Cryptographic Modules,” that sets the security requirements a cryptographic module must meet in a federal system, enforced through the Cryptographic Module Validation Program (CMVP), the NIST program that validates whole modules against it. The standard incorporates ISO/IEC 19790:2012 (security requirements) and ISO/IEC 24759:2017 (test requirements), so a FIPS 140-3 validation is an ISO/IEC 19790 validation with U.S. federal parameters. It matters for the post-quantum transition because federal and regulated deployments must run a FIPS 140-3-validated module, so a correct ML-KEM implementation in open-source code is not automatically deployable, and the lag between an algorithm shipping and its module being validated is a real migration bottleneck.

Source: NIST, “Security Requirements for Cryptographic Modules,” FIPS 140-3, approved March 22, 2019, effective September 22, 2019, FIPS 140-3.

The short version:

1. FIPS 140-3 is the NIST standard for cryptographic module security. The CMVP is the joint NIST and Canadian Centre for Cyber Security program that validates modules against it.
2. It’s built on ISO/IEC 19790:2012 and ISO/IEC 24759:2017, so it aligns U.S. federal validation with the international module-security standard.
3. It defines four increasing security levels, from Level 1 (basic, one approved algorithm, no physical protection required) to Level 4 (a full tamper-responsive envelope that zeroizes keys and resists environmental attack).
4. Algorithm-correctness testing (CAVP) and full-module validation (CMVP) are two different things, and conflating them is the most common mistake. CAVP proves one algorithm is implemented correctly; CMVP validates the whole module that ships it, and CAVP is a prerequisite for CMVP.
5. For a post-quantum migration this is load-bearing. A regulated system reaches ML-KEM only through a CMVP-validated module, so “the library supports it” and “we’re compliant” are separate dates, often years apart.

Think of a car’s crash-safety rating. An engineer can prove that one airbag inflates correctly on a test bench, and that’s real, useful evidence about that one part. It’s a different thing from the whole car passing its full crash certification, where the entire vehicle is tested as an assembled system before it’s road-legal for sale. Algorithm testing is the airbag on the bench. FIPS 140-3 validation is the whole-vehicle crash certification. A federal buyer isn’t allowed to drive the car just because one component passed its own test; the assembled module has to clear the full program first.

What is FIPS 140-3?

FIPS 140-3 is a Federal Information Processing Standard that specifies what a cryptographic module has to do to protect the sensitive information inside it, covering everything from the algorithms it runs to the physical enclosure around its keys. NIST developed it, the Secretary of Commerce approved it on March 22, 2019, and it took effect on September 22, 2019, superseding the long-running FIPS 140-2 (which dated to 2002). A “cryptographic module” here is the set of hardware, software, or firmware that implements approved security functions inside a defined boundary, so the standard governs the container that holds and uses cryptographic keys.

The defining change in the 140-3 generation is that it stopped being a standalone U.S. document and instead incorporated two international standards by reference:

1. ISO/IEC 19790:2012 supplies the security requirements themselves (the eleven requirement areas below).
2. ISO/IEC 24759:2017 supplies the derived test requirements, the procedures a lab uses to check a module against those requirements.

Because of that, a FIPS 140-3 validation is an ISO/IEC 19790 validation with U.S.-specific approved-algorithm choices layered on top, which is why the same lab work increasingly serves multiple national schemes.

Source: NIST, “Security Requirements for Cryptographic Modules,” FIPS 140-3, March 22, 2019, FIPS 140-3.

What does FIPS 140-3 actually require?

FIPS 140-3 requires a module to satisfy eleven areas of security requirements, each graded against the security level the vendor is targeting. The areas span the full lifecycle of a module, from how it’s specified on paper to how it wipes its own keys when someone pries it open. NIST lists them as:

1. Cryptographic module specification.
2. Cryptographic module interfaces.
3. Roles, services, and authentication.
4. Software/firmware security.
5. Operating environment.
6. Physical security.
7. Non-invasive security.
8. Sensitive security parameter management.
9. Self-tests.
10. Life-cycle assurance.
11. Mitigation of other attacks.

A module is graded in each area, and its overall rating is the lowest level it achieves across all eleven, so a module can’t claim Level 3 overall while scoring Level 1 on physical security. The approved algorithms a module is allowed to use (the AES, SHA, RSA, ECDSA, ML-KEM, and ML-DSA of the world) are governed by the separate FIPS and NIST algorithm standards, and FIPS 140-3 is the frame that says how those algorithms must be packaged, protected, and self-checked inside a real product.

Source: NIST, FIPS 140-3, FIPS 140-3; NIST CMVP, “Cryptographic Module Validation Program,” csrc.nist.gov.

What are the four FIPS 140-3 security levels?

FIPS 140-3, through ISO/IEC 19790, defines four increasing, qualitative security levels, each one adding protection over the one below so a buyer can match the module to how exposed it is. The levels are the same four-tier structure that FIPS 140-2 articulated, and the descriptions below are drawn from that standard’s plain-language definitions of what each tier demands.

Level	Physical protection	Operator authentication	Illustrative use
Level 1	None required beyond production-grade components; at least one approved algorithm	None required	A software crypto library or a PC encryption board
Level 2	Tamper-evidence: coatings, seals, or pick-resistant locks that show a break-in	Role-based (authenticates the role, not the individual)	A module where evidence of tampering is enough
Level 3	Tamper detection and response that zeroizes plaintext keys when the enclosure is opened	Identity-based (authenticates the specific operator)	A hardware security module guarding high-value keys
Level 4	A complete protective envelope that detects intrusion from any direction plus environmental (voltage and temperature) attack, with immediate key zeroization	Identity-based	A module operating in a physically unprotected or hostile location

The jump that matters most for key custody is from Level 2 to Level 3. Level 2 only proves that tampering leaves a mark; Level 3 actively destroys the keys the moment the box is breached, and it separates the ports that carry plaintext keys from everything else. Level 4 adds defense against an attacker who manipulates the module’s environment, freezing or spiking its power to force an error, so it’s the tier built for hardware that has to survive with no guards around it. Most software modules, including the crypto libraries carrying post-quantum key exchange, validate at Level 1, which is why a Level 1 certificate is the common bar for a FIPS-compliant TLS deployment.

Source: NIST, “Security Requirements for Cryptographic Modules,” FIPS 140-2, Section 1, FIPS 140-2 (the four-level definitions retained under ISO/IEC 19790 for FIPS 140-3).

What’s the difference between CAVP and CMVP?

CAVP and CMVP are two separate NIST validation programs, and the whole compliance story turns on keeping them distinct. The Cryptographic Algorithm Validation Program (CAVP) tests that a single algorithm implementation produces correct outputs in isolation, using an automated test system that feeds it known inputs and checks the answers. The Cryptographic Module Validation Program (CMVP) validates the entire cryptographic module against FIPS 140-3, the whole assembled package of algorithms, interfaces, key management, self-tests, and physical protection.

The relationship between them is a dependency, stated plainly by NIST: “Cryptographic algorithm validation is a prerequisite of cryptographic module validation.” A module can’t earn a CMVP certificate until the algorithms inside it hold CAVP certificates, but the reverse doesn’t hold at all. An algorithm can pass CAVP and still sit in a product that has never been through CMVP, and in that case the product is not FIPS 140-3 validated.

	CAVP	CMVP
Full name	Cryptographic Algorithm Validation Program	Cryptographic Module Validation Program
What it tests	One algorithm implementation, in isolation	The whole cryptographic module, as an assembled system
What it proves	The algorithm computes correct outputs	The module meets all of FIPS 140-3
Governing standard	The algorithm’s own FIPS/NIST standard (e.g. FIPS 203)	FIPS 140-3 / ISO/IEC 19790
Dependency	Prerequisite for CMVP	Requires CAVP-validated algorithms first
The compliance gate	Necessary, not sufficient	This is the certificate a federal buyer checks

The practical read is that a CAVP algorithm certificate is a building block, and the CMVP module certificate is the thing a procurement officer or auditor actually accepts. When a vendor says “our ML-KEM is CAVP-tested,” that’s true and useful, and it doesn’t by itself make the product deployable in a FIPS-bound estate.

Source: NIST CAVP, “Cryptographic Algorithm Validation Program,” csrc.nist.gov; NIST CMVP, csrc.nist.gov.

What’s the difference between a validated module and a reference implementation?

A validated module is a specific, versioned cryptographic module that holds a CMVP certificate, and a reference implementation is source code that implements an algorithm correctly with no validation attached. Both can compute ML-KEM perfectly. Only one satisfies a federal compliance gate, and the gap between them trips up a lot of migration plans.

The clearest example is the liboqs reference library. Its own maintainers state it should not be used to protect sensitive data in production, precisely because it carries no validation, and its role is to be the broad, correct reference that the ecosystem builds against. A regulated system reaches ML-KEM instead through a validated build such as AWS-LC, whose FIPS module holds a completed CMVP certificate. The distinction is worth stating in three points:

1. Correct code is a precondition, not a certificate. An implementation can match the standard byte-for-byte and still fail the compliance test, because the test is whether the module carrying it went through CMVP, not whether the math is right.
2. The validation is pinned to a version and a boundary. A CMVP certificate names a specific module version, so upgrading past the validated version can move a deployment off its validated state until the new version is validated in turn.
3. A capability date and a compliance date are different dates. The day an algorithm appears in a shipping library is a feature date; the day a module carrying it earns a certificate is the compliance date. In fast-moving PQC libraries those two can be years apart.

Source: liboqs repository, github.com/open-quantum-safe/liboqs; NIST CMVP validated modules list, csrc.nist.gov.

Why does FIPS 140-3 matter for a post-quantum migration?

FIPS 140-3 matters because it’s the gate that decides whether a post-quantum algorithm is actually usable in a federal or regulated system, and that gate moves on its own clock, separate from the standards and the open-source code. NIST finalized ML-KEM and ML-DSA in August 2024, and libraries shipped them quickly, and none of that makes them deployable in a FIPS-bound estate until a CMVP-validated module carries them. So the migration has a hidden dependency: the validated-module timeline.

The live evidence is the split between two of the most-deployed libraries:

1. OpenSSL shipped native hybrid post-quantum TLS in version 3.5 on April 8, 2025, and yet the CMVP-validated OpenSSL module was still the pre-quantum 3.1.2. OpenSSL submitted 3.5.4 for FIPS 140-3 validation on October 9, 2025, with the CMVP certificate pending, so a FIPS-bound OpenSSL estate had a working PQC feature and no validated path to use it compliantly, at the same time.
2. AWS-LC took the other route, getting ML-KEM into a validation early. AWS reported its FIPS 3.0 module as the first open-source cryptographic module to include ML-KEM in a FIPS 140-3 validation, and the AWS-LC 3 module now holds CMVP certificates (numbers 5314 and 5298), both FIPS 140-3 Level 1, listing ML-KEM as an approved algorithm.

That contrast is the whole point. Two capable libraries, the same standardized algorithm, and completely different compliance postures, because validation lag is a real and uneven thing. A post-quantum roadmap that tracks only the algorithm standards and the library release notes will misjudge when its regulated systems can actually turn PQC on. The date to track is the validated-module date, per vendor, per module.

Source: OpenSSL, “OpenSSL 3.5 Final Release,” openssl-library.org and “OpenSSL 3.5.4 FIPS submission,” openssl-library.org.

AWS Security Blog, “AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation,” aws.amazon.com.

How long does FIPS 140-3 validation take?

FIPS 140-3 validation runs through a multi-stage queue managed by the CMVP, and it’s measured in many months to well over a year in practice, which is what makes validation lag a planning problem rather than a footnote. A module doesn’t get a certificate the moment a lab finishes testing; it moves through a documented series of states, and NIST publishes the queue so anyone can see where a given module sits.

NIST’s Modules In Process (MIP) list shows the states a module passes through, including “Pending Review,” “Review,” “Comment Resolution - Lab,” “Comment Resolution - CMVP,” “Pending Resubmission,” “Finalization,” and “Cost Recovery,” plus a “Hold” state for modules paused mid-process. A module also spends time earlier as an “Implementation Under Test” before it reaches that list. Each stage can take weeks to months, and the queue depth varies, so the total wait is genuinely hard to predict in advance.

The consequence for a migration plan is concrete. When a vendor submits a PQC-capable module for validation, the certificate can be a year or more out, and the deployment can’t rely on it until it lands. The OpenSSL case shows the shape of it directly: a submission in October 2025 with the certificate still pending afterward. Building the validated-module wait into the schedule, rather than assuming validation is instant once code ships, is what keeps a compliance date honest.

Source: NIST CMVP, “Modules In Process List,” csrc.nist.gov.

When did FIPS 140-3 replace FIPS 140-2?

FIPS 140-3 became effective on September 22, 2019, but the changeover from FIPS 140-2 was a multi-year phased transition rather than a single switch, because thousands of already-validated 140-2 modules stay valid for a defined period. The CMVP published the schedule, and the dates are load-bearing for anyone reading a module certificate today.

Milestone	Date	What it means
FIPS 140-3 effective	September 22, 2019	The standard takes effect; testing infrastructure ramps up
CMVP accepts 140-3 submissions	September 22, 2020	Labs can submit modules for FIPS 140-3 validation
CMVP stops new 140-2 submissions	September 22, 2021	New modules must go through 140-3
Last 140-2 report acceptance window	April 1, 2022	Only 140-2 reports maintaining existing sunset dates are accepted after this
140-2 modules usable for new systems until	September 21, 2026	After this, remaining FIPS 140-2 certificates move to the Historical List

The date that’s live right now is the last one. Existing FIPS 140-2 validated modules can be procured for new systems only through September 21, 2026, after which they move to the CMVP Historical List, remaining usable in fielded systems but unsuitable for new procurements without a documented risk decision. For any estate still leaning on 140-2 modules, that boundary and the post-quantum validation timeline are converging at the same moment, which is worth sequencing around.

Source: NIST CMVP, “Cryptographic Module Validation Program” and FIPS 140-3 transition schedule, csrc.nist.gov.

Common misconceptions

1. “FIPS 140-3 validates an algorithm.” It validates a module, the whole assembled package. Algorithm-level correctness is the CAVP program’s job, and CAVP is a prerequisite for a FIPS 140-3 module validation rather than a substitute for it.
2. “Our library implements ML-KEM correctly, so we’re FIPS compliant.” Correct code is a precondition. Compliance turns on whether the module carrying that code holds a CMVP certificate, which is a separate event that can lag the code by a long stretch.
3. “FIPS 140-3 is a purely American standard.” It incorporates ISO/IEC 19790:2012 and ISO/IEC 24759:2017 by reference, so it’s the international module-security standard with U.S. federal approved-algorithm choices layered on.
4. “A higher security level is always better.” The right level matches the module’s exposure. A software TLS library validates at Level 1 by design, and demanding Level 3 or 4 for something that has no hardware boundary to protect is a category error, not extra safety.
5. “FIPS 140-2 is dead, so those certificates are worthless.” FIPS 140-2 modules stay usable in fielded systems and are procurable for new systems until September 21, 2026, after which they move to the Historical List. The transition is phased, not a hard cutoff.
6. “Once a module is validated, it stays validated through any update.” A CMVP certificate is pinned to a specific module version and boundary, so a version upgrade can move a deployment off its validated state until the new version is validated in turn.

Questions people ask

Is FIPS 140-3 the same as ISO/IEC 19790? Effectively yes, with a U.S. wrapper. FIPS 140-3 incorporates ISO/IEC 19790:2012 for its security requirements and ISO/IEC 24759:2017 for its test requirements, then adds the U.S. federal set of approved algorithms. A FIPS 140-3 validation is an ISO/IEC 19790 validation done under the CMVP scheme.

What’s the difference between CAVP and CMVP again? CAVP tests one algorithm implementation for correctness in isolation; CMVP validates the whole cryptographic module against FIPS 140-3. CAVP is a prerequisite for CMVP, so a module needs its algorithms CAVP-validated first, and the CMVP module certificate is the one a federal buyer actually checks.

Do I need a FIPS 140-3 validated module to use ML-KEM? For a federal or FIPS-bound deployment, yes. The algorithm being standardized in FIPS 203 and present in a library is not enough on its own; the compliance gate is a CMVP-validated module that carries it, such as the AWS-LC FIPS module.

Which FIPS 140-3 security level do I need? It depends on what the module protects and where it runs. Level 1 suits software crypto libraries and general TLS; Level 3 suits hardware security modules guarding high-value keys with tamper-response; Level 4 suits modules in physically unprotected or hostile locations. Match the level to the exposure rather than reaching for the highest number.

How can I tell if a product is really FIPS 140-3 validated? Check the NIST CMVP validated modules list for the specific module name, version, and certificate number, and confirm the certificate is current. A validation is pinned to a version, so a product running a different version than the one on the certificate may not be covered.

Why is a post-quantum migration blocked on this? Because a regulated system can only run PQC through a validated module, and module validation lags algorithm standardization and library releases. OpenSSL shipped hybrid PQC TLS in 3.5 in April 2025 while its validated module was still the pre-quantum 3.1.2, so the feature was live and the compliant path was not, at the same time.

What happens to FIPS 140-2 modules now? They stay usable in existing systems and are procurable for new systems until September 21, 2026, after which they move to the CMVP Historical List. Historical modules can keep running where already fielded, and they’re generally not appropriate for new procurements without a documented risk acceptance.

---

Everything here is the map, given freely. When your team needs its cryptographic modules inventoried, its validated-module timelines mapped against its post-quantum plan, and the gaps sequenced so compliance and capability land together, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.