Artifact GuideGLOBALFIPS-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.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 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 9, 2026

Overview

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.

Section 1

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

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

Public lookup for algorithm validation listings used to confirm certificate numbers, algorithms, vendors, implementations, and certificate status.

NIST ACVP supported algorithms

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

Primary FIPS source for module validation scope, approved security functions, security levels, and use of CMVP validated module lists in procurement.

Recommended next step

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.

Assessment workflow

Open Assessment Autopilot for FIPS algorithm evidence

Convert CAVP, ACVP, and CMVP evidence checks into accountable review tasks.

Explore next step

Research workflow

Research FIPS validation source questions

Resolve certificate, operational-environment, approved-mode, and module-boundary questions against cited NIST sources.

Explore next step

Talk to Sorena

Talk through CAVP and ACVP validation evidence

Review certificate scope, procurement wording, and unresolved validation gaps with Sorena.

Explore next step

Section 2

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

Section 2.3.A explains certificate binding, including implementation version, tested operational environment, and restrictions after integration into a module.

NIST CAVP validation search

Use the public CAVP search to verify the certificate details instead of relying on product brochures or copied spreadsheet values.

Section 3

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

Maps CAVP ACVTS component tests to algorithm, mode, revision, and usage-restriction evidence for module Security Policies.

NIST ACVP supported algorithms

Official ACVP support reference used to inspect supported automated tests for the relevant algorithms and modes.

Section 4

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

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

Explains CMVP's role in validating modules and warns that the Historical list should not be used for procurement decisions.

Section 5

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

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

Supports the distinction between validated cryptographic modules, approved security functions, and procurement use of CMVP lists.

Primary sources