FIPS algorithm evidence CAVP validation workflow

CAVP evidence is useful only when the claim names the implementation being tested. The implementation owner captures the algorithm family, mode, parameter set, implementation name, version, vendor, processor or platform dependency, and the product or module boundary that will rely on the result. The assurance reviewer accepts, limits, or rejects the claim after matching those fields to the public entry.

Keep the claim narrow. NIST source material treats CAVP as validation testing for approved cryptographic algorithm implementations, while CMVP validates cryptographic modules against FIPS 140-3. A validated AES, SHA-3, deterministic random bit generator (DRBG), key-agreement scheme (KAS), key-transport scheme (KTS), ML-KEM, or signature implementation does not by itself validate the whole module, cloud service, appliance, or software product.

The evidence packet should let a reviewer reproduce the lookup. Save the public validation-search URL or certificate reference, the algorithm name, certificate number or validation identifier, implementation name, vendor name, version details, tested operational environment, and any caveats that appear with the entry.

For procurement or customer responses, attach the source record rather than paraphrasing it. The reviewer should be able to compare the supplier claim against the public listing and see whether the listed implementation is the one used by the delivered product.

An ACVP client exchanging data with ACVTS can produce capability registration, vector, response, and verdict artifacts for engineering and laboratory review. NIST offers a Demo ACVTS server for interested users, but only an accredited laboratory using Production ACVTS can create a listed algorithm validation certificate. Record the environment used before treating a passed session as anything more than test evidence, and label Demo results, failed sessions, superseded vectors, and laboratory drafts so they cannot be mistaken for a public Production ACVTS outcome.

Keep sensitive session records in access-controlled evidence storage and use the public CAVP entry for external validation claims. An internal record should identify the submitter, implementation, parameter set, test environment, vector set or session, verdict, corrected failures, laboratory, and resulting public validation entry. If no public entry resulted, record a test result or validation gap, not a certificate.

When the evidence supports a FIPS 140-3 module validation, translate the CAVP entry into the module submission context. The handoff should state which module service uses the algorithm, whether the service is claimed as approved, which Security Policy table or submission field cites the certificate, and whether the module boundary matches the implementation evidence.

FIPS 140-3 requires conforming modules to employ approved security functions, and CMVP guidance ties CAVP-tested functions to the module validation record. The handoff does not replace the CMVP certificate, Security Policy, operational environment, service indicator, or validation status needed for the module claim.

Do not reuse CAVP evidence merely because an algorithm name still matches. Re-check the listed implementation, version, operational environment, algorithms, modes, and parameters when the implementation, compiler or build, processor acceleration, platform, module boundary, parameter set, mode, or dependent module changes. A change is a review trigger; its effect depends on the certificate, current program guidance, and the claim being made.

Bound or embedded module claims need an additional status check. CMVP guidance requires the external validated module to be Active when the module under test is submitted to CMVP, and the downstream validation can later inherit Historical status. Those submission rules do not turn every product update into an automatic CAVP revocation, so record the change and obtain laboratory or CMVP guidance when the effect is unclear.

Review this checklist before relying on CAVP evidence in a release gate, supplier review, audit response, or CMVP submission. Each item should be answerable from the evidence packet without requiring the reviewer to infer facts from marketing copy. Accept only the matched algorithm implementation and environment; limit the claim when the record covers fewer modes, parameters, or operations than the product exposes; reject it when the implementation, environment, certificate, or public status does not match; and open a gap record when evidence is still pending.