Artifact GuideGLOBALFIPS-approved cryptographic algorithm requirements

FIPS algorithm evidence CAVP validation workflow

A workflow for proving which algorithm implementations have CAVP evidence, which claims require CMVP module validation, and which product changes require a fresh evidence review.

Grounded in NIST CAVP, CMVP implementation guidance, and FIPS 140-3 source material. Use it as implementation guidance, supporting implementation planning and should be validated against jurisdiction-specific legal, contractual, and policy requirements before implementation.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 27, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 27, 2026

Overview

Use this workflow when a supplier, engineering team, auditor, or customer asks for proof that a cryptographic algorithm implementation has been validated through CAVP or tested through ACVP tooling. The workflow keeps algorithm-validation evidence separate from FIPS 140-3 module validation so a CAVP certificate is not misrepresented as a validated product or service.

Section 1

Start with the exact algorithm implementation claim

CAVP evidence is useful only when the claim names the implementation being tested. Capture 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.

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, DRBG, KAS, KTS, ML-KEM, or signature implementation does not by itself validate the whole module, cloud service, appliance, or software product.

Record the algorithm and mode exactly as it appears in the supplier statement or validation listing.
Identify whether the evidence is for a standalone implementation, a processor algorithm accelerator, a processor algorithm implementation, a bound or embedded module, or the module under CMVP validation.
Name the relying use case: approved service, protocol implementation, procurement requirement, customer assurance packet, or CMVP submission support.
Reject generic FIPS cryptography claims unless they can be traced to a CAVP algorithm entry and, where required, a CMVP module certificate.

Sources for this answer

NIST Cryptographic Algorithm Validation Program (CAVP)

Supports the distinction between validation testing of approved cryptographic algorithm implementations and broader module or product claims.

CMVP Implementation Guidance for FIPS 140-3

Explains that CAVP addresses approved security-function testing referenced by the SP 800-140 series for FIPS 140-3.

Section 2

Collect certificate and search evidence

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.

Capture a dated copy or export of the CAVP validation-search result used for the decision.
Record certificate numbers and validation identifiers exactly; do not normalize names in a way that breaks lookup.
Preserve tested environment details, including processor, operating system, hardware acceleration, or software/firmware notes when the source lists them.
Tie each certificate entry to the product bill of materials, cryptographic inventory, or CMVP submission table that relies on it.

Sources for this answer

NIST CAVP validation search

Public lookup source for algorithm validation entries, certificate identifiers, implementation names, vendors, and searchable validation details.

CMVP Implementation Guidance for FIPS 140-3

Grounds the need to keep cryptographic algorithm validation listings separate from cryptographic module validation listings.

Recommended next step

Operationalize CAVP validation evidence

Use this workflow to separate CAVP certificates, ACVP test artifacts, CMVP module claims, and customer-facing assurance language before release or procurement review.

Assessment workflow

Open Assessment Autopilot for FIPS evidence

Convert CAVP, ACVP, and CMVP evidence checks into accountable tasks, source links, and release gates.

Explore next step

Research workflow

Research FIPS source questions

Resolve algorithm validation, approved mode, module boundary, and procurement evidence questions against cited NIST sources.

Explore next step

Talk to Sorena

Talk through CAVP validation evidence

Review certificate evidence, change triggers, and customer-facing assurance language with Sorena.

Explore next step

Section 3

Preserve ACVP test artifacts without exposing private data

ACVP automation can produce registration, vector, response, and verdict artifacts that are useful during engineering and lab review. Keep those records in the internal evidence system, but publish only public validation references and non-sensitive summaries on customer-facing pages.

A complete internal ACVP evidence record should identify who submitted the test, which implementation and parameter set was tested, which vector set or session produced the result, which failures were corrected, and which final public CAVP listing or validation reference was produced from the work.

Store ACVP registration options, capabilities, vector-set IDs, response files, verdicts, and lab correspondence in access-controlled evidence storage.
Redact seeds, private keys, unreleased implementation details, and lab-only correspondence before creating public assurance material.
Map every ACVP result to a public CAVP entry or to an unresolved gap; do not leave passed test artifacts disconnected from the validation claim.
For algorithms such as ML-KEM, keep test-only interfaces and production interfaces distinct because NIST specifies CAVP test interfaces that should not be exposed to applications.

Sources for this answer

NIST CAVP access to ACVTS

Official NIST source for ACVTS environments and ACVP use in CAVP algorithm validation workflows.

NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard

Shows that some algorithm standards define CAVP test interfaces that must be kept separate from application-facing production interfaces.

Section 4

Build the CAVP to CMVP handoff record

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. That relationship is a handoff, not a shortcut: the CMVP certificate, Security Policy, operational environment, service indicator, and validation status still decide the module claim.

Map CAVP certificate entries to Security Policy algorithm tables, approved-service descriptions, self-test coverage, and service-indicator behavior.
Document whether the implementation is inside the module boundary, provided by an embedded validated module, or called through a bound module.
For embedded or bound modules, identify the existing validated module by name, CMVP certificate number, version, and used functionality.
Keep CAVP evidence and CMVP evidence in separate fields so reviewers can tell which claim each source supports.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Primary standard for FIPS 140-3 module validation scope, approved security functions, and CMVP procurement relevance.

CMVP Implementation Guidance for FIPS 140-3

Supports handoff fields for approved services, Security Policy references, CAVP certificate tables, and bound or embedded module distinctions.

Section 5

Use change triggers before reusing old evidence

Do not reuse CAVP evidence merely because an algorithm name still matches. Re-check the evidence when the implementation version, compiler, processor acceleration, operating environment, cryptographic boundary, approved mode behavior, parameter set, or dependent module changes.

The highest-risk reuse cases involve hardware acceleration, bound or embedded modules, and algorithm transitions. CMVP guidance requires precise identification of external validated modules and notes that validation status can change when an existing validated module becomes historical or when an algorithm transition affects the implementation.

Trigger review after implementation rewrites, library upgrades, compiler or build changes, hardware acceleration changes, operating-system changes, or platform-porting changes.
Trigger review when an algorithm transition, caveat, or CMVP status change affects a certificate that the product relies on.
For bound or embedded modules, verify that the existing validated module remains Active at the relevant submission point and that the used functionality still matches.
Record the decision as reuse accepted, CAVP evidence update required, CMVP revalidation impact, or customer claim removed.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Grounds change-trigger checks for operational environments, processor accelerators, algorithm transitions, and bound or embedded module status.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the distinction between Active validated module procurement use and Historical list reference use.

Section 6

Acceptance checklist for the evidence packet

Use 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.

The packet names the algorithm, mode or parameter set, implementation, vendor, version, tested environment, and certificate or validation identifier.
The packet links to stable external NIST sources and contains no private lab artifacts.
The packet states whether the claim is algorithm validation, ACVP test evidence, CMVP module validation, or procurement assurance.
The packet maps each CAVP entry to the product, module service, Security Policy table, approved service indicator, or customer requirement that uses it.
The packet lists unresolved gaps, including missing certificates, mismatched implementation names, unsupported operating environments, historical module status, or evidence that cannot be published.

Sources for this answer

NIST CAVP validation search

Source for reviewer lookup of public CAVP entries used in the acceptance checklist.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports acceptance checks that keep algorithm evidence separate from validated-module procurement claims.

Primary sources