We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALFIPS-approved cryptographic algorithms

CAVP validation and ACVP testing Evidence boundaries for FIPS algorithms

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

Based on NIST and CSRC sources. Use it as implementation guidance, not for legal interpretation.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
5 sections4 primary sources
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."
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.
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.
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.
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.
Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov6 citations
Referenced sections
  • Primary official source for CAVP certificate binding, ACVTS component mappings, tested operational environments, Security Policy requirements, vendor affirmation, and module validation evidence.
  • Distinguishes CAVP testing of approved security functions from CMVP validation of cryptographic modules and explains how algorithm certificates bind to module evidence.
  • Section 2.3.A explains certificate binding, including implementation version, tested operational environment, and restrictions after integration into a module.
Show 3 more
  • Maps CAVP ACVTS component tests to algorithm, mode, revision, and usage-restriction evidence for module Security Policies.
  • Supports evidence requirements for certificate binding, tested operational environments, embedded or bound modules, Security Policy markings, and approved services.
  • Supports the error checks in CMVP rules for certificate binding, operational environments, vendor affirmation, and Security Policy disclosure.
"Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program (CAVP)."
More quoted passages
"The validation certificate serves as a benchmark"
"Within the context of the CAVP ACVTS"
"Security Policy and validation test report"
"shall not be used in an approved mode"
NIST FIPS 140-3 security requirements for cryptographic modules
doi.org4 citations
Referenced sections
  • Primary FIPS standard for module-level validation scope, approved security functions, CMVP validated module lists, and procurement cautions.
  • Primary FIPS source for module validation scope, approved security functions, security levels, and use of CMVP validated module lists in procurement.
  • Explains CMVP's role in validating modules and warns that the Historical list should not be used for procurement decisions.
Show 1 more
  • Supports the distinction between validated cryptographic modules, approved security functions, and procurement use of CMVP lists.
"CMVP validated modules list"
More quoted passages
"Cryptographic modules that conform to this standard shall employ Approved security functions"
"Historical list should not be used for procurement decisions"
NIST ACVP supported algorithms
pages.nist.gov3 citations
Referenced sections
  • Official ACVP reference for checking supported automated validation tests and CAVP ACVTS-related algorithm capability details.
  • NIST-supported ACVP material for checking which automated validation tests exist for relevant algorithm, mode, revision, and component combinations.
  • Official ACVP support reference used to inspect supported automated tests for the relevant algorithms and modes.
"supported"
NIST CAVP validation search
csrc.nist.gov3 citations
Referenced sections
  • Public CAVP listing used to verify algorithm certificate numbers and details before accepting procurement or audit claims.
  • Public lookup for algorithm validation listings used to confirm validation numbers, algorithms, vendors, implementations, and validation dates.
  • Use the public CAVP search to verify the certificate details instead of relying on product brochures or copied spreadsheet values.
"Validation Number"

Related guides

AES FIPS 197 requirements and evidence

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

Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, environments, and CMVP handoff records.

FIPS 180-4 and FIPS 202 secure hash guidance

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

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

Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.

FIPS approved algorithm selector workflow

A cited workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.

Show all related guides (25)

FIPS approved mode procurement: certificates, boundaries, and evidence

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

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

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

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

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

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-approved cryptographic algorithms FAQ

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.

ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5

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

An official source 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

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

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

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

Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.

FIPS 203, 204, and 205 Post-Quantum Algorithms

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

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 validation certificates for cryptographic algorithms

How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.

How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval

Identify SHA-1 and SHA-2 in FIPS 180-4 and SHA-3 and SHAKE in FIPS 202, then check current-use status and CAVP/CMVP evidence separately.

How FIPS 186-5 Signature Algorithms Fit FIPS Approval

Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.

What does FIPS 197 AES mean for FIPS-approved algorithms?

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.