---
title: "CAVP and ACVP validation evidence for FIPS algorithms"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation"
author: "Sorena AI"
description: "How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "CAVP validation"
  - "ACVP"
  - "ACVTS"
  - "CMVP"
  - "FIPS 140-3"
  - "cryptographic algorithm evidence"
---
**[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 and ACVP validation evidence for FIPS algorithms

How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.

*Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithms*

## CAVP and ACVP validation Evidence boundaries for FIPS algorithms

Use CAVP certificates and ACVTS/ACVP test references as algorithm evidence, then confirm whether the module itself is validated through CMVP before making a FIPS claim.

Grounded in NIST and CSRC sources. Use it as implementation guidance, not for legal interpretation.

CAVP and ACVP evidence is often misread during procurement and audit reviews. A CAVP certificate shows that a named algorithm implementation was tested in a stated operational environment. It does not, by itself, prove that a product, service, cloud deployment, or cryptographic module is FIPS 140-3 validated; that module-level claim belongs to CMVP evidence.

## Separate the three evidence layers before approving a FIPS claim

Start by naming which claim is being reviewed: algorithm implementation testing, ACVTS/ACVP test coverage, or cryptographic module validation. NIST CMVP guidance says CAVP addresses testing of approved security functions and approved sensitive security parameter generation and establishment methods referenced by the SP 800-140 series.

For a procurement or audit record, do not collapse those layers into the phrase "FIPS compliant crypto." A defensible record identifies the CAVP certificate, the algorithm and mode, the implementation name and version, the tested operational environment, and the CMVP certificate when the claim is about a validated module.

- CAVP layer: confirm the algorithm implementation, version, tested operational environment, and certificate listing.
- ACVTS/ACVP layer: use the supported-test material to understand which algorithm, mode, revision, component test, or protocol KDF can be exercised.
- CMVP layer: verify the cryptographic module name, version, boundary, security policy, approved services, and module certificate status.
- Procurement layer: quote the exact certificate numbers and scope instead of accepting vendor shorthand such as "FIPS ready," "FIPS capable," or "validated crypto."

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) - Distinguishes CAVP testing of approved security functions from CMVP validation of cryptographic modules and explains how algorithm certificates bind to module evidence.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup for algorithm validation listings used to confirm certificate numbers, algorithms, vendors, implementations, and certificate status.
- [NIST ACVP supported algorithms](https://pages.nist.gov/ACVP/?ref=sorena.io#supported) - NIST-supported ACVP material for checking which automated validation tests exist for relevant algorithm, mode, revision, and component combinations.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS source for module validation scope, approved security functions, security levels, and use of CMVP validated module lists in procurement.

*Recommended next step*

*Placement: after practical guidance*

## Review the certificate boundary before making the claim

Use the certificate numbers, tested environments, ACVP test support, and CMVP module boundary as one evidence record instead of relying on broad FIPS wording.

- [Open Assessment Autopilot for FIPS algorithm evidence](/solutions/assessment.md): Convert CAVP, ACVP, and CMVP evidence checks into accountable review tasks.
- [Research FIPS validation source questions](/solutions/research-copilot.md): Resolve certificate, operational-environment, approved-mode, and module-boundary questions against cited NIST sources.
- [Talk through CAVP and ACVP validation evidence](/contact.md): Review certificate scope, procurement wording, and unresolved validation gaps with Sorena.

## What a CAVP certificate can and cannot prove

The CMVP implementation guidance says a cryptographic algorithm validation certificate states the name and version number of the validated algorithm implementation and the tested operational environment. Treat those fields as limits on the claim, not as background details.

A CAVP certificate is strongest when the module uses the same implementation and the same or included operational environment. If the implementation has been modified during integration, or the module is being tested on a different platform, processor size, operating system, or hypervisor context, the certificate may no longer support the intended module claim without additional validation work.

- Record the implementation name exactly as listed, including version and vendor naming.
- Capture every tested operational environment field that matters for the module: operating system, platform, processor, and hypervisor where applicable.
- Check whether the module uses the full algorithm implementation, a component test, a CVL entry, or a protocol-specific KDF entry.
- Flag any modified code, new processor width, changed operating environment, or ported module as a validation question before release.

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) - Section 2.3.A explains certificate binding, including implementation version, tested operational environment, and restrictions after integration into a module.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use the public CAVP search to verify the certificate details instead of relying on product brochures or copied spreadsheet values.

## Where ACVP and ACVTS fit in the evidence review

ACVP and ACVTS references help reviewers understand the automated test capabilities behind CAVP evidence. The CMVP guidance maps some component tests to CAVP ACVTS capability combinations such as algorithm, mode, revision, and componentTest fields, then points reviewers to the ACVP supported-test material for details.

Do not describe ACVP support as a product validation by itself. Use it to answer narrower questions: whether a relevant test exists, how a component is denoted on the CAVP page, and whether a Security Policy should list the tested components that may be called during module operation.

- Use ACVP supported-test material to check algorithm/mode/revision support before planning a new validation or transition.
- For component testing, capture the CAVP denotation shown in the CMVP guidance, such as component ECDSA signature generation, RSA decryption primitive, KDF, TLS KDF, or KAS key confirmation entries.
- For protocol KDFs and component tests, document the usage restriction because the approved use may be limited to a specific protocol, KTS, KAS, or signature-generation context.
- When no CAVP test exists or a transition period has not expired, treat vendor affirmation only as permitted by the applicable CMVP guidance and document the limitation.

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) - Maps CAVP ACVTS component tests to algorithm, mode, revision, and usage-restriction evidence for module Security Policies.
- [NIST ACVP supported algorithms](https://pages.nist.gov/ACVP/?ref=sorena.io#supported) - Official ACVP support reference used to inspect supported automated tests for the relevant algorithms and modes.

## Checklist for procurement and audit evidence

Use this checklist when a supplier, product team, or assessor says a cryptographic feature is covered by CAVP, ACVP, or CMVP. Each item should be answered with a certificate, Security Policy section, validation listing, test-support reference, or documented gap.

The target output is a bounded evidence record: which algorithms are tested, which module is validated, which operational environments are covered, and which claims remain unsupported until the vendor or lab supplies more evidence.

- Identify the claim type: algorithm implementation tested by CAVP, automated test support shown through ACVP/ACVTS material, or module validation through CMVP.
- Copy the CAVP certificate number, implementation name, version, algorithm, mode, revision, and tested operational environment into the evidence record.
- Copy the CMVP certificate number, module name, version, security level, status, boundary summary, Security Policy link, and approved service indicators when module validation is claimed.
- For embedded or bound validated modules, record the existing validated module name, CMVP certificate number, versions, active status, and the Security Policy markings required by the CMVP guidance.
- Reject or escalate claims when the certificate is historical or revoked for the intended procurement use, the operational environment does not match, the algorithm is untested and not vendor-affirmed under current guidance, or the product boundary is not the validated module boundary.

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) - Supports evidence requirements for certificate binding, tested operational environments, embedded or bound modules, Security Policy markings, and approved services.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains CMVP's role in validating modules and warns that the Historical list should not be used for procurement decisions.

## Common claim errors that need correction

Most CAVP and ACVP evidence failures are overstatements. The source material supports precise claims about tested implementations, supported tests, module validation, and approved-mode use. It does not support broad claims that every build, operating environment, cloud service, protocol use, or bundled product is automatically validated.

When a claim cannot be traced to the certificate and module boundary, record it as unsupported rather than softening it into generic compliance language. This protects procurement, sales, audit, and engineering teams from relying on evidence that does not match the shipped configuration.

- Do not say an entire product is FIPS 140-3 validated when only one algorithm implementation has a CAVP certificate.
- Do not say ACVP support proves validation; use ACVP material to identify supported tests and CAVP ACVTS mappings.
- Do not reuse a certificate across changed source code, changed operational environments, different processor width, or a different module boundary without validation review.
- Do not list an algorithm as approved for module operation when CMVP guidance requires CAVP testing, vendor affirmation, Security Policy disclosure, or a usage restriction that is missing from the evidence.
- Do not use CMVP Historical list entries as procurement proof for a new acquisition unless the procurement requirement explicitly allows that status.

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 the error checks in CMVP rules for certificate binding, operational environments, vendor affirmation, and Security Policy disclosure.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the distinction between validated cryptographic modules, approved security functions, and procurement use of CMVP lists.

## Primary sources

- [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) - Primary grounding for CAVP certificate binding, ACVTS component mappings, tested operational environments, Security Policy requirements, vendor affirmation, and module validation evidence.
  - Quote: "CAVP addresses the testing of Approved Security Functions"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public CAVP listing used to verify algorithm certificate numbers and details before accepting procurement or audit claims.
  - Quote: "Cryptographic algorithm validation listings"
- [NIST ACVP supported algorithms](https://pages.nist.gov/ACVP/?ref=sorena.io#supported) - Official ACVP reference for checking supported automated validation tests and CAVP ACVTS-related algorithm capability details.
  - Quote: "supported"
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS standard for module-level validation scope, approved security functions, CMVP validated module lists, and procurement cautions.
  - Quote: "CMVP validated modules list"

## 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 Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records.
- [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-and-acvp-validation