---
title: "CAVP Validation Evidence Workflow for FIPS Algorithms"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow"
author: "Sorena AI"
description: "Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records."
published_at: "2026-05-09"
updated_at: "2026-05-27"
keywords:
  - "CAVP evidence"
  - "ACVP testing"
  - "CMVP validation"
  - "FIPS 140-3"
  - "algorithm certificate"
  - "CAVP"
  - "ACVP"
  - "CMVP"
  - "FIPS algorithms"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# CAVP Validation Evidence Workflow for FIPS Algorithms

Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records.

*Artifact Guide* *GLOBAL* *FIPS-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.

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.

## 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)](https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program?ref=sorena.io) - Supports the distinction between validation testing of approved cryptographic algorithm implementations and broader module or product claims.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains that CAVP addresses approved security-function testing referenced by the SP 800-140 series for FIPS 140-3.

## 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](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup source for algorithm validation entries, certificate identifiers, implementation names, vendors, and searchable validation details.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the need to keep cryptographic algorithm validation listings separate from cryptographic module validation listings.

*Recommended next step*

*Placement: after practical guidance*

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

- [Open Assessment Autopilot for FIPS evidence](/solutions/assessment.md): Convert CAVP, ACVP, and CMVP evidence checks into accountable tasks, source links, and release gates.
- [Research FIPS source questions](/solutions/research-copilot.md): Resolve algorithm validation, approved mode, module boundary, and procurement evidence questions against cited NIST sources.
- [Talk through CAVP validation evidence](/contact.md): Review certificate evidence, change triggers, and customer-facing assurance language with Sorena.

## 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](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/how-to-access-acvts?ref=sorena.io) - Official NIST source for ACVTS environments and ACVP use in CAVP algorithm validation workflows.
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Shows that some algorithm standards define CAVP test interfaces that must be kept separate from application-facing production interfaces.

## 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](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Primary standard for FIPS 140-3 module validation scope, approved security functions, and CMVP procurement relevance.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports handoff fields for approved services, Security Policy references, CAVP certificate tables, and bound or embedded module distinctions.

## 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - 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](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Supports the distinction between Active validated module procurement use and Historical list reference use.

## 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](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Source for reviewer lookup of public CAVP entries used in the acceptance checklist.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Supports acceptance checks that keep algorithm evidence separate from validated-module procurement claims.

## Primary sources

- [NIST Cryptographic Algorithm Validation Program (CAVP)](https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program?ref=sorena.io) - Official CAVP overview used to ground algorithm-validation scope and prevent algorithm evidence from being overstated as module validation.
  - Quote: "validation testing of Approved cryptographic algorithms"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup for CAVP validation records, certificate identifiers, implementation names, vendors, and searchable validation details.
  - Quote: "validation-search"
- [NIST CAVP access to ACVTS](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/how-to-access-acvts?ref=sorena.io) - Official NIST source for ACVTS environments and ACVP use in CAVP algorithm validation workflows.
  - Quote: "Automated Cryptographic Validation Protocol"
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Program guidance for CAVP-to-CMVP handoff, approved services, Security Policy tables, and bound or embedded module evidence.
  - Quote: "CAVP Certs Table"
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://csrc.nist.gov/pubs/fips/140-3/final?ref=sorena.io) - Primary source for FIPS 140-3 module validation scope, approved security functions, CMVP validation, and procurement cautions.
  - Quote: "shall employ Approved security functions"
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final?ref=sorena.io) - Grounds the warning that CAVP test interfaces for some algorithms should not be exposed as production application interfaces.
  - Quote: "used to test ML-KEM implementations"

## Related Topic Guides

- [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.
- [CAVP and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.
- [FIPS 180-4 and FIPS 202 secure hash guidance](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims.
- [FIPS 186-5 and FIPS 204 digital signatures](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.
- [FIPS 203 ML-KEM vs RSA and ECDH key establishment](/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh.md): Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding.
- [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md): FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks.
- [FIPS Algorithm Procurement Evidence FAQ](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md): What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers.
- [FIPS approved algorithm selector workflow](/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow.md): A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.
- [FIPS approved mode procurement: certificates, boundaries, and evidence](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.
- [FIPS crypto transition and deprecation tracker](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.
- [FIPS cryptographic algorithm selector](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope.
- [FIPS KDF and MAC coverage for validated modules](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.
- [FIPS Key Management Mapping for Algorithms and SSP Evidence](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.
- [FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records.
- [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md): How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
- [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms.
- [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md): Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.
- [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md): Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.
- [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries.
- [Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ.
- [Post-Quantum Migration for FIPS Cryptography](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries.
- [Post-Quantum Migration Tracker for FIPS 203, 204, and 205](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries.
- [SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202](/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3.md): Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required.
- [TLS use-case mapping for FIPS algorithm evidence](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.
- [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md): FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow