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 140-3 and algorithm validation

FIPS procurement evidence review CAVP, CMVP, and approved-mode workflow

A procurement workflow for checking whether a supplier crypto claim is supported by the right FIPS evidence: algorithm testing, module validation, tested environment, scope, and approved-mode operation.

Use it to turn vague "FIPS compliant" claims into certificate numbers, boundaries, configurations, change triggers, and retention records backed by NIST sources.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
6 sections4 primary sources
Overview

Classify the supplier's claim before accepting any certificate. FIPS 140-3 applies to U.S. federal agencies that use cryptography-based security systems to protect sensitive information and shall be used in designing and implementing cryptographic modules that federal departments and agencies operate or that are operated for them under contract; other buyers may require it by contract or adopt it voluntarily. A Cryptographic Algorithm Validation Program () entry covers a named algorithm implementation and . A Cryptographic Module Validation Program () certificate covers a named cryptographic module, version, boundary, tested environment, public , and validation status. The deployed service must also follow the approved-service and configuration conditions in that Security Policy. If the supplier provides only "FIPS compliant" marketing copy, record the claim as unsupported until the public evidence matches the delivered configuration.

Section 1

Start by classifying the supplier claim

Separate four claims before reviewing any certificate. An approved algorithm standard such as AES or SHA is not the same thing as a -tested implementation. A CAVP algorithm certificate is not the same thing as a module certificate. A CMVP certificate still has a boundary, version, tested operating environment, approved services, and usage conditions. Procurement wording should mirror that exact scope.

Procurement owns the supplier request and contract record; product security matches certificates and the ; engineering and operations confirm the delivered binary, hardware path, configuration, and service indicator. Ask the supplier to identify the component that performs each cryptographic operation, then request the evidence needed for that claim. A claim of algorithm validation needs the public record and its implementation details. A module claim also needs the public record and Security Policy. An approved-service claim needs the service indicator, configuration, and usage conditions that apply to the deployed service.

  • Algorithm-validation claim: request the certificate number, implementation name, algorithm family, version, and tested operating environment.
  • Module-validation claim: request the certificate number, module name, module version, validation status, tested operating environment, and public .
  • Approved-mode claim: request the section that lists approved services, non-approved services, service indicators, and any operator guidance needed to stay in .
  • Embedded or bound-module claim: require the supplier to identify the existing validated module by name, certificate number, version, and the subset of functionality reused by the delivered product.
  • Do not accept a certificate for a different product, version, hardware accelerator path, processor feature, or operating environment unless the and certificate scope actually cover the delivered configuration.
Section 2

Build the evidence request package

A useful procurement package asks for the evidence a reviewer can tie to a shipped configuration. The IG states that algorithm validation certificates identify the validated algorithm implementation and tested operating environment, while module validation certificates identify the validated module and tested operating environment. That distinction should drive the intake form and the contract exhibit.

For software, firmware, and hybrid modules, pay close attention to operating environments. When a -validated algorithm implementation is bound into a module undergoing FIPS 140-3 testing, the guidance requires the CAVP-tested environment to be identical to, or fully included in, the module's test environment under stated rules. Procurement should capture CPU or processor, operating system, firmware, accelerator path, and deployment profile when those facts determine whether the delivered configuration matches the public evidence.

  • Certificate inventory: certificate numbers, certificate numbers, validation status, issue/update dates when present in the source listing, and supplier-provided implementation names.
  • Boundary evidence: module boundary diagram or description, product components inside and outside the cryptographic boundary, and any embedded or bound validated modules.
  • evidence: approved services, non-approved services, roles, service indicators, operator guidance, algorithm tables, and caveats that affect allowed use.
  • Configuration evidence: delivered version, build options, hardware acceleration path, operating environment, firmware level, platform architecture, and cloud or appliance deployment profile.
  • Procurement controls: acceptance criteria for matching certificates to the delivered configuration, required supplier notices for changes, handling rules for Historical certificates used with legacy systems, and rejection rules for Revoked or mismatched certificate evidence.
Recommended next step

Review and retain FIPS procurement evidence

This workflow helps convert supplier "FIPS compliant" statements into certificate checks, Security Policy constraints, approved-mode controls, and change-review tasks.

Assessment workflow
Open Assessment Autopilot for FIPS procurement evidence

Convert certificate checks, Security Policy review, approved-mode evidence, and change triggers into accountable tasks.

Explore next step
Research workflow
Research FIPS certificate questions

Use cited NIST source material to resolve CAVP, CMVP, operating-environment, and approved-mode questions before acceptance.

Explore next step
Talk to Sorena
Talk through implementation

Review the cryptographic boundary, supplier evidence, certificate fit, and procurement acceptance criteria with Sorena.

Explore next step
Section 3

Review algorithm certificates separately from module certificates

Use evidence to show that a named algorithm implementation was successfully tested and added to a NIST validation list. Use evidence to show that a named cryptographic module was validated against FIPS 140-3. A product can include a validated algorithm without the product or its full cryptographic boundary being a validated module. A validated module can also have usage limits that procurement and deployment teams must preserve.

The review output should avoid broad labels. Say "uses AES implementation covered by certificate X in operating environment Y" or "uses cryptographic module Z validated under certificate N when configured according to S," rather than converting either certificate into a blanket product approval. If only part of a product falls inside the validated boundary, name the excluded components and do not extend the claim to them.

  • Match the certificate evidence to the actual delivered binary, firmware, hardware module, library, service boundary, or appliance model.
  • Record whether the certificate is algorithm-level or module-level, because remediation differs when either one does not match.
  • Check whether the module certificate relies on another validated module, an embedded module, a processor algorithm accelerator, or a processor algorithm implementation, then require the related caveats and text.
  • For TLS, KDF, signature, hash, encryption, and key-establishment evidence, verify that the algorithm certificate context matches the protocol or service in which the product uses it.
  • Keep rejected evidence with the reason: wrong boundary, wrong operating environment, unsupported status, stale version, unlisted service, or unsupported approved-mode claim.
Section 4

Approved-mode and Security Policy review gates

is a service-use and configuration question, not a certificate label for the whole product. guidance defines it as a set of services that includes at least one service using an approved security function or process and excludes non-approved security functions or processes. The guidance separately allows some non-approved algorithms to run with no security claimed under strict conditions; that allowance does not make them approved security functions.

Use the public to identify approved security services, non-approved services, algorithm certificates, roles, interfaces, operating rules, service indicators, and caveats. Ask how the deployed service reports approved use, because FIPS 140-3 guidance focuses on an indicator for the approved security service and does not always accept a single global mode indicator.

  • Require a reference for each accepted module certificate and cite the section that supports the procurement claim.
  • Verify that the deployed configuration uses the claimed approved services within the conditions and does not use a non-approved security function as part of that claim.
  • Document how a return code, log, status interface, configuration control, or other service indicator lets the operator determine when an approved security service is in use.
  • List non-approved algorithms or services separately and state whether they are disabled, allowed with no security claimed, or outside the procured use case.
  • Make implementation teams keep the constraints in deployment guides, hardening baselines, and customer-facing evidence packs.
Section 5

Change impact and retention workflow

A delivered-configuration change reopens the evidence decision without automatically revoking every certificate. guidance includes cases where version changes, excluded-component changes, operating-environment changes, processor acceleration, or embedded modules require validation or revalidation analysis. Record the specific change, compare it with the certificate and , and seek supplier, laboratory, or CMVP clarification when the applicable scenario is unclear.

Retain the evidence in a way that lets future auditors reconstruct the accepted claim. Store the public source URL, certificate identifier, version, supplier attestation, product version, operating environment, reviewer decision, conditions, exception owner and expiry, and rejection notes together. When a supplier ships a cryptographic update, rerun the review rather than copying the previous acceptance forward.

  • Trigger reassessment after cryptographic library changes, module version changes, firmware updates, OS or processor changes, accelerator-path changes, cloud-region or platform changes, and certificate status changes.
  • Require suppliers to notify procurement and security when a entry no longer matches the implementation or when a relied-on certificate changes status, moves to the Historical or Revoked list, or no longer covers the delivered configuration.
  • Retain accepted evidence, rejected evidence, assumptions, source URLs, and reviewer approvals by product release or contract version.
  • For inherited or embedded validation claims, track the upstream validated module status because the downstream claim can depend on it.
  • Set a review cadence tied to release management and supplier change notices, not a generic calendar reminder detached from product change.
Section 6

Procurement review steps

Keep this workflow in intake notes or contract review. Each step should produce an evidence-backed decision that another reviewer can reconstruct.

  • Step 1, claim intake. Owner: Procurement and security. Inputs: Supplier FIPS claim, product/version, crypto component inventory. Decision: Is this an algorithm claim, module-validation claim, approved-mode claim, or internal target?
  • Step 2, certificate match. Owner: Security reviewer. Inputs: / certificate IDs, implementation names, module names, versions, tested operating environments. Decision: Does the public evidence match the delivered configuration?
  • Step 3, review. Owner: Product security and operations. Inputs: Security Policy, approved services, service indicators, caveats, operator guidance. Decision: Can the deployment operate inside the validated boundary and approved-mode conditions?
  • Step 4, decision and change control. Owner: Procurement, engineering, supplier owner. Inputs: Acceptance statement, gaps, supplier notice clause, release record, rejected-evidence log, reassessment triggers. Decision: Is the evidence accepted, conditionally accepted, escalated, or rejected, and what changes reopen it?
  • Write the final acceptance sentence narrowly enough that it remains true when copied into a contract, security questionnaire, or customer evidence pack.
  • State separate outcomes for the algorithm record, module certificate, approved-service use, and delivered configuration; one accepted layer does not cure a gap in another.
  • Attach the evidence pack to the product release, supplier contract, or system authorization record where it will actually be reused.
  • Escalate mismatches to engineering before signature; procurement should not paper over a certificate that does not cover the shipped boundary.
Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov7 citations
Referenced sections
  • Program guidance for certificate binding, module boundaries, tested operating environments, approved services and indicators, embedded modules, Security Policy evidence, and revalidation scenarios.
  • Supports certificate binding, module-boundary review, approved-service evidence, embedded or bound module identification, and the Security Policy fields needed to classify a supplier claim.
  • States what an algorithm validation certificate identifies and gives the identical-or-fully-included operational-environment rule for binding that implementation into a module under FIPS 140-3 testing.
Show 4 more
  • Supports the distinction between an algorithm validation certificate and a module validation certificate, including implementation identity, tested environment, embedded modules, accelerators, and Security Policy caveats.
  • Defines approved mode, distinguishes approved security services from other allowed services, limits non-approved algorithm use, and explains when a service-specific or global indicator is acceptable.
  • Provides change and revalidation scenarios involving versioning, excluded components, operational environments, processor acceleration, and external validated modules.
  • Supports the evidence fields in the review table: algorithm and module identity, tested environment, boundary, Security Policy entries, service indicators, caveats, and change impact.
"The validation certificate serves as a benchmark"
NIST CAVP validation search
csrc.nist.gov7 citations
Referenced sections
  • Public search page used to verify validation numbers, vendors, implementations, product types, included algorithms, and validation dates before accepting supplier evidence.
  • Public search page used to verify validation numbers, vendors, implementations, product types, included algorithms, and validation dates before accepting algorithm evidence.
  • Public search page for reproducing the algorithm-record lookup documented in the procurement package.
Show 4 more
  • Public algorithm listing used to verify that the implementation and covered algorithms match the supplier's claimed component.
  • Public algorithm listing used to verify certificates named in the module's Security Policy.
  • Public source for rechecking an algorithm validation record after an implementation or configuration change.
  • Public source for reproducing the CAVP lookup recorded in the final procurement decision.
NIST CMVP validated modules
csrc.nist.gov2 citations
Referenced sections
  • Official entry point for Active, Historical, and Revoked CMVP module records. Historical modules should not be included in new federal systems but can be procured for legacy systems; agencies may make their own risk determination about continued use. Revoked certificates may not demonstrate compliance.
  • Official entry point for checking a module's public CMVP certificate, current validation list, Historical list, and Revoked list.
NIST FIPS 140-3 security requirements for cryptographic modules
doi.org
Referenced sections
  • Primary standard for cryptographic module validation, approved security functions, agency procurement planning, and the warning that the CMVP historical list should not be used for procurement decisions.
"Agencies should develop plans for the acquisition"

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

Show all related guides (25)

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