Read this first
ACVP proves an algorithm computes the right outputs on well-formed inputs. Conformance asks whether the implementation follows the whole standard, including the input checks and reject paths honest test vectors never exercise. FIPS 140-3 validates a cryptographic module — its boundary, key management, self-tests, and roles — with algorithm validation as a prerequisite, not the whole job. They overlap but they are not interchangeable, and a certificate on one axis says nothing about the others.
Ask a vendor whether their post-quantum crypto is "validated" and you may get any of three answers: it passes NIST's ACVP test vectors, it conforms to the standard, or the module carries a FIPS 140-3 certificate. These sound like grades of the same thing. They are not — each answers a different question, and a strong claim on one axis routinely gets read as coverage on all three. Pulling them apart is the difference between knowing what you have bought and assuming it.
ACVP and CAVP: algorithmic correctness
The Automated Cryptographic Validation Protocol (ACVP) is NIST's protocol for delivering known-answer test vectors and collecting an implementation's responses. It is the testing mechanism behind the Cryptographic Algorithm Validation Program (CAVP), which issues the algorithm certificates. The check is precise and narrow: feed fixed, well-formed inputs, compare the outputs byte-for-byte against the expected answers, and confirm the algorithm computes correctly for each approved parameter set.
What an ACVP/CAVP certificate proves — and what it does not — is worth stating plainly:
- **Proves:** the algorithm produces the standard's outputs on honest, well-formed inputs, across the parameter sets it was tested for. That catches transcription errors, endianness bugs, and wrong parameters.
- **Does not prove:** how the implementation handles malformed input, whether the reject paths behave as the standard requires, whether it is free of timing or other side-channel leakage, or anything about the module that wraps the algorithm.
Conformance: the whole standard, including the reject paths
Conformance is a broader axis than ACVP. It asks whether the implementation follows the full standard — not just the arithmetic on honest inputs, but the input validation and reject-path behaviour the algorithm vectors never touch. FIPS 203 makes the gap concrete: its §7.2 encapsulation-key modulus check and §7.3 ciphertext-length check are normative, and implicit rejection must return a deterministic pseudo-random secret indistinguishable, by timing, from an accept. No honest known-answer vector contains an out-of-range key or a wrong-length ciphertext, so an implementation can pass every ACVP vector while silently skipping the very checks that make it conformant. This is the behaviour our conformance testing exercises, and it is what the FIPS 203 checklist walks through line by line.
The same shape holds for ML-DSA and SLH-DSA: verification must reject malformed keys and signatures and apply domain separation correctly, all on paths the vectors cannot reach. Conformance is orthogonal to ACVP — spec-adherence including the refusals — not a stricter version of the same test.
FIPS 140-3: the module, not just the algorithm
FIPS 140-3 validates a cryptographic module under NIST and CCCS's Cryptographic Module Validation Program (CMVP). Its scope is the module as a whole: the cryptographic boundary, the set of approved algorithms, key management, power-up and conditional self-tests, roles and authentication, and — at higher levels — physical security. Algorithm validation via CAVP/ACVP is a prerequisite for a 140-3 validation: you cannot validate the module without validated algorithms inside it. But 140-3 is about the module, not the algorithm, so a 140-3 certificate answers questions ACVP never asks — and still does not, by itself, certify reject-path conformance.
How the three relate
The cleanest way to hold them is as nested-and-orthogonal, not as a ladder:
- **ACVP ⊆ FIPS 140-3.** Algorithmic correctness is a prerequisite the module validation subsumes — every 140-3 module has CAVP-validated algorithms inside it.
- **Conformance is a distinct axis.** Spec-adherence including input validation and reject paths is orthogonal: neither ACVP nor, by itself, a 140-3 certificate guarantees it.
- **Audit is yet another axis.** Whether the code is exploitable in your context — side channels, RNG quality, memory handling — is a separate question again, the one an audit answers.
"FIPS 140-3 validated" and "passes ACVP" are not blanket assurances
Buyers treat either phrase as a stamp that the crypto is simply correct and safe. They answer different, narrow questions — the algorithm computes right on honest inputs; the module meets CMVP's requirements — and neither one proves the reject-path conformance or the absence of exploitable bugs. Before you rely on a claim, ask which axis it actually covers: correctness, conformance, module validation, or security. A certificate on one is not evidence on the others.
How quantakrypto helps
We help you read the claims for what they cover and close the gaps between them. We conformance-test the FIPS 203 (ML-KEM) and ML-DSA implementation you actually ship against the input checks and reject paths the vectors miss (certification), and we assess whether it is exploitable in your deployment (audit) — the two axes a CAVP or 140-3 certificate leaves open. The deliverable is a signed statement of which axis has been verified and how, so "validated" stops being a word that means four different things at once.