Mental model
When a vendor says “we are ready for PQC”, that sentence can hide three different realities: just a roadmap promise, an independent test that the algorithm works mathematically correctly (CAVP), or independent validation of the whole hardware module, physical and logical security included (CMVP). Telling these three apart is at the heart of deciding which module a bank generates its root CA key in.
CAVP and CMVP: NIST’s own definition
NIST’s own CMVP FAQ answers this directly: “Cryptographic algorithms approved for use in the modules must first be validated by the Cryptographic Algorithm Validation Program (CAVP), before submitting the module validation to the CMVP.” So CAVP is the prerequisite for CMVP: first the algorithm itself is validated (mathematical correctness, with test vectors), then the whole module using that algorithm (physical tamper resistance, key management, self-test routines, production process control) is validated through a separate, more comprehensive process. A vendor saying “we got CAVP” is a real and verifiable achievement, but it does not substitute for CMVP; for a root CA key ceremony, CMVP is what is really needed.
Two real examples: validated vs pending
Today (September 2026) two different situations sit side by side on the market, and that difference is exactly what this lesson wants to teach:
CMVP-validated (a real certificate exists):
- Thales TCT Luna T7, Certificate #5450SOURCED, validated on 29 July 2026, with ML-DSA/ML-KEM/LMS in the algorithm list.
- Crypto4A QASM Cryptographic Module, Certificate #5497SOURCED, validated on 19 August 2026, with ML-DSA/ML-KEM/LMS/SLH-DSA in the algorithm list.
CAVP only (algorithm tests passed, no module certificate):
- Entrust nShield: CAVP validated, CMVP pendingSOURCED.
- Utimaco Quantum Protect: CAVP only, no CMVP claimSOURCED.
Note that all four vendors have made real, verifiable progress on PQC algorithms; this is not a “good vendor, bad vendor” comparison, just a difference in validation stage. But that difference matters when making a production decision: generating a root CA key today in Thales’s or Crypto4A’s CMVP-certified module has a different risk profile from generating it in Entrust’s or Utimaco’s (not yet CMVP-certified) module.
Methodology note: in the initial research, the CAVP-only status of Entrust and Utimaco rested on trade press reports about a year old. To follow this lesson’s own discipline (check the live database, don’t rely on secondary news), the claim was re-checked by querying the CMVP database directly: Entrust’s most recent certificate (#5329, nShield 5s, validated 15 June 2026) still lists no PQC algorithm. The conclusion did not change, but the verification method was corrected; an example that a finding being right does not mean you stop questioning how you verified it.
The exact count is uncertain, honestly: CMVP’s search interface cannot be queried automatically, so we do not claim the exact number of PQC-capable, CMVP-validated modules; we know there are at least two (the two above), and there may be more. Claiming “there is only one” or “this is a comprehensive list” would violate the very discipline this lesson teaches.
How to read a CMVP certificate
When you open a certificate record (like the two examples above), check these fields in order: Module Name (exactly which product and firmware version), Vendor, Validation Date (when it was validated; an old date may not cover current firmware), Overall Level (a security level from 1 to 4; a bank’s root CA usually calls for Level 3), and Algorithm List (which algorithms are really within the certificate’s scope; there is a difference between a module saying “we support PQC” in general and actually seeing ML-DSA/ML-KEM in the list; if the list is empty or contains only classical algorithms, the PQC claim is not within that certificate’s scope). This five-minute reading habit is, as the original brief also stresses, one of the skills that separates people who can check a vendor claim from those who cannot.