Artifact GuideGLOBALFIPS-approved cryptographic algorithms

CAVP validation and ACVP testing Evidence boundaries for FIPS algorithms

Use CAVP records as algorithm-validation evidence, understand ACVP as the test protocol and ACVTS as the test system, then verify CMVP separately for a module-level claim.

Based on 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

Jul 25, 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 Jul 25, 2026

Overview

, , , and describe different parts of one validation ecosystem. ACVP is the Automated Cryptographic Validation Protocol used to exchange capabilities, vectors, responses, and verdicts; ACVTS is the Automated Cryptographic Validation Test System. A completed ACVP/ACVTS session is not a separate product certificate. The public CAVP record supports the tested algorithm implementation, while a FIPS 140-3 module claim requires separate CMVP evidence.

Section 1

Separate the program, test mechanics, and module claim

Start by naming which claim is being reviewed: a -validated algorithm implementation or a -validated cryptographic module. The vendor supplies the implementation and version, an accredited laboratory performs the applicable testing, CAVP publishes the algorithm-validation result, and CMVP separately reviews a module submission against FIPS 140-3. and carry out automated algorithm testing; they do not create a third certification layer. 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 these concepts into the phrase "FIPS compliant crypto." A defensible record identifies the public validation entry, algorithm and mode, implementation name and version, tested operational environment, and the certificate and Security Policy when the claim is about a validated module.

program: confirm the algorithm implementation, version, tested operational environment, public validation entry, and validation date.
protocol and system: use capability and supported-test material to understand which algorithm, mode, revision, component test, or protocol KDF can be exercised; keep session artifacts as supporting test records, not as a certificate or public validation claim.
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 validation numbers, algorithms, vendors, implementations, and validation dates.

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 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 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 the ACVP protocol and ACVTS system fit

defines the protocol used to register capabilities and exchange test vectors, responses, and verdicts. is the NIST test system implementing that automated workflow for testing. guidance maps some component tests to ACVTS capability combinations such as algorithm, mode, revision, and componentTest fields, then points reviewers to supported-test material for details.

Do not describe support, an account, or a passed session as product validation. Use those artifacts to answer narrower questions: whether a relevant test exists, what capability was exercised, how a component is denoted on the eventual record, and whether a Security Policy should list the tested component used during module operation. Likewise, vendor affirmation is a program-defined allowance for specified cases, not a substitute name for a CAVP certificate.

Use supported-test material to check algorithm, mode, revision, and component support before planning testing or a transition.
For component testing, capture the denotation shown in the 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 test exists or a transition period has not expired, use vendor affirmation only where the current guidance permits it, record the exact algorithm and limitation, and do not present it as CAVP validation.

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

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

The completed review records which algorithms were tested, which module was validated, which operational environments are covered, the certificate status and review date, and which claims remain unsupported. Recheck it after a source-code, library-version, processor, operating-system, hypervisor, module-boundary, certificate-status, or approved-service change.

Identify the claim type: algorithm validation through or module validation through ; classify / records as supporting test artifacts rather than a separate validation credential.
Copy the certificate number, implementation name, version, algorithm, mode, revision, and tested operational environment into the evidence record.
Copy the 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, 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 errors involving validation and / test records 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 certificate.
Do not say support, access, or a passed test session proves public validation; use those records as support for the resulting validation entry.
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 guidance requires testing, vendor affirmation, Security Policy disclosure, or a usage restriction that is missing from the evidence.
Do not use Historical list entries as procurement proof for a new acquisition unless the procurement requirement explicitly allows that status.