up:: Migration Architecture MOC
ACVP and PQC Validation
PQC validation is how a post-quantum implementation goes from “the code runs” to “an independent, federally recognized program proved it correct.” It runs on three layers that stack. The Automated Cryptographic Validation Protocol (ACVP) is the machine-to-machine test protocol that drives the Cryptographic Algorithm Validation Program (CAVP), which proves that one algorithm implementation, an ML-KEM, ML-DSA, or SLH-DSA implementation, computes correct outputs. The Cryptographic Module Validation Program (CMVP) then validates the whole module the algorithm ships inside against FIPS 140-3. The reason this matters to a migration is a gap most estates miss: a system that “uses ML-KEM” has made a claim, and only CAVP and CMVP turn that claim into evidence a regulator or a buyer will accept.
The short version:
- Validation stacks in three layers: ACVP is the test protocol, CAVP is the algorithm-validation program it drives, and CMVP is the whole-module validation under FIPS 140-3.
- ACVP is a machine-to-machine protocol where a NIST validation server issues test vectors and the implementation returns answers the server checks, which is how algorithm testing became automated and repeatable.
- CAVP tests one algorithm in isolation and says nothing about the module around it. CMVP tests the assembled module, and CAVP is a prerequisite for it.
- The post-quantum algorithms have ACVP test definitions, so ML-KEM, ML-DSA, and SLH-DSA implementations get validated the same way classical ones do.
- “Uses ML-KEM” is a claim; “CAVP and CMVP validated” is proof. Only the second is deployable in a FIPS-bound estate, and the validation lags the code, which is a migration-timing fact, not a formality.
Think of it as the difference between a builder saying a lock meets code and a certified inspector proving each lock does, then certifying the whole door assembly, the frame, the strike plate, the hinges, as a validated unit. The algorithm being correct is necessary. The module carrying it being validated is what a federal buyer actually checks, and the testing is the control, not the deployment.
What is ACVP?
ACVP is the Automated Cryptographic Validation Protocol, the machine-to-machine protocol NIST uses to test cryptographic algorithm implementations at scale. Instead of a lab manually running fixed test vectors and eyeballing the results, ACVP defines a validation server that generates test cases on demand, sends them to the implementation under test, and checks the responses programmatically. That automation is why algorithm validation can keep pace with a growing catalog of algorithms and parameter sets, including the new post-quantum ones.
The protocol is the delivery mechanism for the ML-KEM, ML-DSA, and SLH-DSA test suites. Each algorithm has an ACVP specification defining the test types it supports. For ML-KEM, for instance, ACVP defines an Algorithm Functional Test that has the implementation generate a key pair from a supplied seed and validates the produced values against the server, alongside encapsulation and decapsulation tests. NIST runs the testing through its Automated Cryptographic Validation Test System, offering a free demonstration server and a production system that requires accreditation, and the whole process is black-box: the vendor runs NIST’s vectors through the implementation and reports the results, and the implementation itself is never handed to NIST.
Source: NIST, “Cryptographic Algorithm Validation Program,” csrc.nist.gov/projects/cryptographic-algorithm-validation-program; NIST/IWG ACVP, “ACVP ML-KEM JSON Specification,” pages.nist.gov/ACVP.
What is CAVP and how does it use ACVP?
CAVP is the Cryptographic Algorithm Validation Program, NIST’s program that provides validation testing of approved cryptographic algorithms and their individual components, and ACVP is the protocol that drives it. The relationship is direct: CAVP is the program that issues a validation, and ACVP is the automated test system through which the testing is performed. When a vendor validates an algorithm, they run the ACVP test vectors, and a passing result earns a CAVP validation certificate for that specific algorithm implementation on that specific platform.
What CAVP proves is narrow and important to state precisely. It proves that one algorithm implementation produces correct outputs for the tested cases, which confirms the primitive itself is right: the ML-KEM implementation encapsulates and decapsulates correctly, the ML-DSA implementation signs and verifies correctly. It says nothing about the key management, the interfaces, the self-tests, or the physical protection of the module the algorithm lives in. CAVP is the algorithm-level gate, and it is a prerequisite for the module-level gate rather than a substitute for it.
Source: NIST, “Cryptographic Algorithm Validation Program,” csrc.nist.gov/projects/cryptographic-algorithm-validation-program.
What is CMVP and how is it different from CAVP?
CMVP is the Cryptographic Module Validation Program, a joint NIST and Canadian Centre for Cyber Security program that validates a whole cryptographic module against FIPS 140-3, the standard titled “Security Requirements for Cryptographic Modules.” Where CAVP asks “is this one algorithm correct,” CMVP asks “is this assembled module secure,” and the two answer different questions at different scopes:
| Dimension | CAVP (algorithm) | CMVP (module) |
|---|---|---|
| Scope | One algorithm implementation | The whole assembled module |
| Standard | The algorithm specification (e.g. FIPS 203 (ML-KEM)) | FIPS 140-3 |
| Driven by | ACVP test vectors | Independent lab review plus CAVP as input |
| Proves | The primitive computes correctly | Interfaces, key management, self-tests, and physical protection are sound |
| Who checks it | A prerequisite step | The certificate a federal buyer actually verifies |
An accredited testing laboratory performs the CMVP review, examining the module’s interfaces, its key lifecycle, its power-up self-tests, and its physical protections, and CAVP validation of every algorithm inside is a precondition. So the module cannot be CMVP-validated until its algorithms are CAVP-validated, and the CMVP certificate is the artifact that a FIPS-bound procurement checks. A CAVP-tested algorithm sitting inside an unvalidated module is not FIPS 140-3 validated, which is a distinction that decides whether a system can be deployed in a federal environment at all.
Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov/projects/cryptographic-module-validation-program.
Why is “uses ML-KEM” not the same as “CAVP and CMVP validated”?
Because “uses ML-KEM” describes what the code was written to do, and validation is independent proof that it does it correctly inside a sound module. The two live at different confidence levels, and the gap between them is exactly the gap between documented and verified evidence in a CBOM. A vendor claim, a library changelog, or an architecture diagram asserting ML-KEM support is documented evidence: it says the algorithm is present without proving it is correct or that the surrounding module protects the keys. A CAVP certificate and a CMVP certificate are verified evidence produced by an independent program, and they are what a regulator or a discerning buyer relies on.
The distinction has teeth for three reasons:
- Correctness is not automatic. A post-quantum implementation can have subtle sampling, encoding, or parameter bugs that a functional smoke test misses but the ACVP vectors catch. “It runs” is not “it is correct.”
- The module matters as much as the algorithm. A correct ML-KEM implementation inside a module with weak key management or no self-tests is not a secure deployment, and only CMVP checks that surrounding envelope.
- The compliance gate is the module certificate. In a FIPS-bound estate, the deployable artifact is a CMVP-validated module, so “uses ML-KEM” and even “CAVP-validated ML-KEM” are not sufficient on their own.
Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov/projects/cryptographic-module-validation-program.
Why does validation lag affect a PQC migration timeline?
Because a correct algorithm is not deployable in a FIPS-bound environment until it ships inside a CMVP-validated module, and that validation arrives well after the working code does. A vendor can implement ML-KEM the day the standard publishes, earn a CAVP algorithm certificate for it soon after, and still wait many more months for the module carrying it to clear CMVP review, because the module-level program involves an independent lab, a queue, and the full FIPS 140-3 examination. The lag between shipped code and validated module is a real and sometimes multi-year interval.
For a migration planner, this converts validation from a formality into a scheduling input. The migration-time variable Y has to account for the wait on validated modules on top of the engineering work to adopt the new algorithm, because in a federal or FIPS-bound estate the clock does not stop when the code is ready. It stops when the CMVP certificate exists. Planning against the code-ready date rather than the module-validated date is how a program discovers, late, that its post-quantum systems are not yet deployable where the mandate requires validated cryptography.
Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov/projects/cryptographic-module-validation-program.
How does PQC validation fit the testing-as-control principle?
It is the formal, federally recognized instance of the broader rule that deploying an algorithm is the claim and validating it is the security. Turning on ML-KEM is the deployment. ACVP-driven CAVP testing proves the algorithm is right, CMVP proves the module around it is sound, and together they are the control that turns a deployment into a defensible one. The same known-answer tests that ACVP issues during validation also run inside a deployed FIPS 140-3 module as power-up self-tests, so the testing does not end at certification. It becomes a runtime property of the module.
This is why a mature migration treats validation status as a first-class field in its inventory rather than an afterthought. A CBOM entry for a post-quantum system should record the CAVP and CMVP certificate status alongside the algorithm name, because that status is the difference between a claimed control and a proven one, and the whole point of building the inventory is to know which is which.
Common misconceptions
- “ACVP and CAVP are the same thing.” ACVP is the automated test protocol; CAVP is the program that uses it to issue algorithm validations. The protocol is the mechanism, the program is the authority.
- “CAVP validation means we’re FIPS 140-3 compliant.” CAVP validates one algorithm. The compliance gate is the whole-module CMVP certificate, and CAVP is only a prerequisite for it. A CAVP-tested algorithm in an unvalidated module is not FIPS 140-3 validated.
- “If the library says it supports ML-KEM, we’re validated.” A support claim is documented evidence. Validation is independent proof through CAVP and CMVP, and only that proof counts in a FIPS-bound estate.
- “Post-quantum algorithms can’t be validated yet.” They can. ACVP defines test specifications for ML-KEM, ML-DSA, and SLH-DSA, so they validate through the same CAVP and CMVP pipeline as classical algorithms.
- “Validation is a paperwork step with no schedule impact.” The lag between code-ready and module-validated can run to a year or more, which lands directly in the migration-time variable of Mosca’s theorem.
Questions people ask
What is the difference between ACVP, CAVP, and CMVP? ACVP is the automated protocol that issues test vectors, CAVP is the program that uses it to validate a single algorithm implementation, and CMVP is the program that validates the whole module against FIPS 140-3. Algorithm, then module, in that dependency order.
Is my ML-KEM implementation FIPS validated just because it passes tests? Not necessarily. Passing ACVP vectors earns a CAVP algorithm certificate, but FIPS deployment in a bound estate requires the whole module to hold a CMVP certificate, and CAVP is only a prerequisite for that.
Can post-quantum algorithms be CAVP-validated today? Yes. ACVP has test specifications for ML-KEM, ML-DSA, and SLH-DSA, so implementations of the NIST post-quantum standards validate through the standard CAVP pipeline.
Why does a vendor claim of “ML-KEM support” not satisfy an auditor? Because a claim is documented evidence and validation is verified evidence. An auditor wants the CAVP and CMVP certificates that independently prove the algorithm is correct and the module is sound, which a datasheet cannot do.
How much time should I budget for validation in a migration plan? Budget for the module-validated date, not the code-ready date. The CMVP queue and the full FIPS 140-3 review can add many months to over a year after CAVP, and that interval belongs in the migration-time variable of Mosca’s theorem.
Do the validation tests keep running after certification? Yes. The known-answer tests ACVP uses also run inside a deployed FIPS 140-3 module as power-up self-tests, so the algorithm’s correctness is re-checked every time the module starts.
Everything here is the map, given freely. When your team needs its post-quantum systems checked for real CAVP and CMVP status rather than vendor claims, and that status turned into a defensible inventory, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.