CAVP, CMVP and production support: the general discipline

Mental model

In the previous lesson you saw VALIDATED status illustrated with a Thales HSM certificate. This lesson shows the same CAVP/CMVP distinction in a non-HSM example, a software crypto library. The goal is to make clear that this discipline is not a hardware-specific rule but a general habit to apply to any claim about a crypto product. In M9 you will see the distinction again with much more detailed, HSM-specific examples; this lesson lays the general foundation for that one.

CAVP and CMVP: a reminder, the general frame

CAVP (Cryptographic Algorithm Validation Program) verifies with test vectors that an algorithm is implemented mathematically correctly. CMVP (Cryptographic Module Validation Program) takes CAVP as a prerequisite and independently validates the whole module (physical and logical security, key management, production process control). A product saying “we got CAVP” is a real achievement, but it does not substitute for CMVP; for a production decision, CMVP is usually what is really needed.

A concrete example: OpenSSL’s own FIPS provider

In M0 you actually tested OpenSSL 3.5’s PQC support (ML-KEM, ML-DSA, SLH-DSA) in your own Docker or native environment; that support is real and works. But “OpenSSL supports PQC” and “OpenSSL’s FIPS module is certified for PQC” are different claims. The OpenSSL Corporation’s own announcement (9 October 2025) separates them clearly: “all included algorithms have successfully passed NIST testing and independent laboratory review” (CAVP complete), but “the final CMVP review and certificate issuance remain as the last step in the process” (CMVP not finished). This lesson carries that forward to today (September 2026) with the “verify live” discipline: NIST’s own CMVP Modules In Process list shows the OpenSSL FIPS Provider’s current status as CAVP passed, CMVP pending (Comment Resolution - CMVP)^SOURCED (as of 21 August 2026), so there has been progress since the vendor’s 2025 announcement, but there is no completed certificate.

This example follows exactly the same pattern as the Entrust/Utimaco HSM example you will see in M9 (CAVP only, CMVP pending); the difference is that it is not a hardware module but the most widely used open-source crypto library in the world. The discipline is the same: whatever the product, ask whether a “we support PQC” claim implies CAVP or CMVP, and verify the answer from an independent source (NIST’s own list, not a vendor blog).

The general rule, in two steps

When a vendor or open-source project says “we support it” about a crypto feature: (1) Does the claim imply CAVP or CMVP, or neither (just “we implemented it, we didn’t test it”)? (2) Can it be verified from an independent source (the CAVP/CMVP search pages), or does it rest only on the vendor’s word? These two questions apply the same way to every crypto product claim, from HSMs to software libraries, from cloud KMS to smart cards; in M9 you will see this general discipline applied in a much more detailed, HSM-specific way.