Artifact FAQGLOBALFIPS validation certificates

FIPS validation certificates How to read CAVP and CMVP evidence

Validation certificates are useful only when the certificate type, implementation, version, operational environment, and claim scope all match.

This FAQ helps separate CAVP algorithm evidence from CMVP module validation evidence before answering customers, auditors, or procurement teams.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

Short answer: first identify which is being cited. A CAVP certificate supports a claim about a tested cryptographic algorithm implementation. A CMVP certificate and its support a claim about a validated cryptographic module. Neither should be stretched to cover a different implementation, version, , module boundary, or product configuration.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

What does each validation certificate prove?

The CMVP implementation guidance draws a clear line between certificate types. CAVP tests and validates cryptographic algorithm implementations; the algorithm states the implementation name, implementation version, and tested .

CMVP tests and validates cryptographic modules. A module states the validated cryptographic module name, version, and tested . That module-level evidence is separate from the algorithm certificate, even when the module uses CAVP-tested algorithms.

  • Use CAVP evidence for the tested algorithm implementation, such as an AES, hash, signature, KDF, MAC, or DRBG implementation.
  • Use CMVP evidence for a FIPS 140-3 cryptographic module claim, including the module boundary, , approved services, status, and caveats.
  • Do not convert a CAVP algorithm certificate into a product-level or module-level FIPS 140-3 validation claim.
Citations
Question 2

When does a certificate match a deployed implementation?

A is a benchmark for the configuration and used during validation testing. For an algorithm implementation embedded in a module undergoing FIPS 140-3 testing, the guidance requires the algorithm implementation to remain unmodified and the CAVP-tested operational environment to be identical to, or fully included in, the module testing environment.

For software modules, the operating system, platform, processor, and any hypervisor details are part of the check. A certificate tested on one operating system or processor bit size should not be treated as evidence for another environment unless the official record and module evidence support that environment.

  • Compare the certificate's algorithm implementation name and version with the implementation shipped in the product or module.
  • Compare the certificate's tested operating system, platform, processor, and hypervisor details with the deployed or validated environment.
  • Re-check evidence after code changes, library swaps, processor acceleration changes, operating-system changes, module-boundary changes, or certificate status changes.
Citations
Question 3

How should certificate evidence be worded in reviews?

Use wording that names the exact evidence and stops at what it proves. The statement should identify the certificate type, certificate number or listing, vendor, module or implementation name, version, , validation status, and the date the public listing was checked.

For procurement and customer responses, replace broad phrases such as FIPS compliant encryption with narrower wording. For example, state that a named algorithm implementation has a CAVP , or that a named cryptographic module is listed by CMVP for a stated version and environment. Then add any approved-mode instructions, caveats, and deployment conditions that limit the claim.

  • Keep CAVP certificate records with the algorithm implementation, parameters, certificate number, tested environment, and source URL.
  • Keep CMVP certificate records with the module name, version, certificate number, , status, approved-mode instructions, caveats, and source URL.
  • Avoid claims that a whole application, cloud service, or product is FIPS validated unless the cited CMVP certificate and deployment configuration actually support that scope.
Citations
NIST CAVP validation search

Use the public CAVP listing for current algorithm certificate details rather than relying only on copied screenshots.

Question 4

What do Active, Historical, and Revoked CMVP statuses mean?

Status changes the decision a certificate can support. An Active module may be used for new and existing federal systems when the exact module version, environment, approved services, and caveats match. A Historical certificate has not been revoked, but NIST says federal agencies should not include the module in new systems; legacy use or procurement requires the responsible agency's documented decision.

A Revoked certificate is no longer valid and may not be cited to demonstrate compliance with the FIPS 140 standards. Historical status can result from age, a sunset date, or a program transition, so read the status reason and current certificate page instead of relying on an old certificate image or supplier copy.

  • For a new system, check that the certificate is Active and that its sunset date and transition status fit the acquisition schedule.
  • For a legacy system, record why a Historical module remains in use, which agency or risk owner accepted it, and what replacement or review trigger applies.
  • For a Revoked module, stop using the certificate as validation evidence and determine whether replacement, revalidation, or another validated module is required.
Citations
Primary sources

References and citations

csrc.nist.gov
Referenced sections
  • Supports certificate-scoped evidence wording and review triggers for implementation and environment changes.
"states the name and version number"
csrc.nist.gov
Referenced sections
  • Use the public CAVP listing for current algorithm certificate details rather than relying only on copied screenshots.
Related guides

Explore more topics

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 Algorithm Validation and ACVP Testing
How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.
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 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 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.
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.
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.
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.
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.