Artifact GuideGLOBALFIPS-approved cryptographic algorithm requirements

FIPS-approved cryptographic algorithm requirements Procurement evidence for FIPS algorithm and module claims

A procurement-focused answer for teams reviewing supplier claims about FIPS-approved algorithms, CAVP algorithm certificates, and FIPS 140-3 module validation.

Grounded in NIST FIPS, CAVP, CMVP, and supply-chain procurement guidance. Use it as implementation guidance, not for legal interpretation.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Questions
3

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

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

Procurement evidence should not stop at a supplier statement that a product uses AES, SHA, HMAC, ECDSA, or another FIPS-approved algorithm. Ask for evidence that connects the purchased product version to the relevant algorithm implementation, tested operational environment, cryptographic module boundary, module certificate status, security policy, and approved-service use case.

Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

How should procurement teams handle FIPS algorithm evidence?

Treat a FIPS algorithm claim and a FIPS 140-3 module claim as related but different assertions. CAVP evidence supports a tested algorithm implementation; CMVP evidence supports a validated cryptographic module. A procurement file should show which claim the supplier is making and which public certificate or security policy supports it.

For each in-scope product or service, record the supplier name, product name, version, cryptographic module name, module certificate number, algorithm certificate number, operational environment, and the security service that uses the algorithm. If the supplier relies on a bound or embedded validated module, the evidence should identify that module by name, certificate number, and version rather than treating the larger product as automatically validated.

  • Require the supplier to identify whether the claim is algorithm validation, module validation, or both.
  • Match certificate evidence to the exact purchased version, platform, operating environment, and cryptographic boundary.
  • Keep the module security policy with the procurement record because it explains approved and non-approved services, service indicators, and certificate scope.
  • Reject unsupported shorthand such as "uses FIPS algorithms" when no CAVP certificate, CMVP certificate, or security-policy mapping is provided.
Citations
NIST CAVP validation search

Use the public CAVP search to check algorithm certificate numbers, implementation names, versions, and operational environments cited by a supplier.

Recommended next step

Map supplier FIPS claims to certificates, services, and review triggers

Use this FAQ to turn supplier FIPS claims into evidence requests, certificate checks, product mappings, and accountable remediation work.

Assessment workflow
Turn FIPS procurement evidence into controls

Convert certificate checks, security-policy reviews, and supplier evidence gaps into accountable work.

Explore next step
Research workflow
Ask a FIPS procurement evidence follow-up

Use cited research support when scope, source interpretation, or evidence ownership is unclear.

Explore next step
Talk to Sorena
Talk through FIPS algorithm procurement evidence

Review FIPS-approved algorithm scope, CAVP certificates, CMVP module evidence, supplier gaps, and next compliance actions with Sorena.

Explore next step
Question 2

What evidence should teams collect from suppliers?

Collect evidence that a reviewer can verify without relying on marketing language. The core packet should include the supplier's FIPS claim, the public CAVP algorithm certificate where algorithm validation is claimed, the public CMVP module certificate where module validation is claimed, the FIPS 140-3 security policy, and a product-to-certificate mapping that names the exact product build and deployment environment.

Procurement clauses should define what counts as acceptable evidence and how conformance will be verified. For FIPS algorithm procurements, that means naming the certificate identifiers, requiring the supplier to disclose non-approved services or modes that may be present, and requiring notice when certificate status, product version, operating environment, module boundary, or cryptographic implementation changes.

  • Supplier claim: the exact statement being accepted, such as "module validated to FIPS 140-3" or "algorithm implementation validated by CAVP."
  • Public certificate evidence: CAVP certificate numbers for algorithm implementations and CMVP certificate numbers for modules, with current status checked at review time.
  • Security policy evidence: approved services, non-approved services, service indicators, algorithm lists, module versions, and operating environment scope.
  • Product mapping: SKU, software or firmware version, deployment platform, cloud service configuration, and the component that actually invokes the approved security service.
  • Change evidence: supplier notice and internal reassessment triggers for certificate status changes, algorithm transitions, module updates, platform additions, or audit findings.
Citations
Question 3

What review checks prevent weak FIPS procurement files?

The main review risk is accepting evidence that proves a different thing than the procurement claim. An AES certificate may support a specific algorithm implementation in a tested environment, but it does not by itself prove the purchased product is a FIPS 140-3 validated module or that every service in the product runs in an approved manner.

Before award, renewal, or reassessment, compare the certificate records and security policy against the actual deployment. Reopen the review when a supplier changes the module, adds an operating environment, changes firmware, moves a certificate to a different status, introduces a non-approved service, or claims a new algorithm without matching CAVP or permitted vendor-affirmed evidence.

  • Check that the certificate status is current enough for the procurement decision and is not being confused with a different module, version, or platform.
  • Verify that approved-service indicators are documented and usable for the service the organization will call.
  • Confirm that non-approved algorithms or services are not presented as approved security functions in the procurement response.
  • For bound or embedded module claims, verify the referenced validated module, certificate number, version, and operational environment.
  • Document gaps as procurement conditions, remediation tasks, compensating controls, or rejection reasons instead of turning them into unsupported validation claims.
Citations
NIST CAVP validation search

Use this public search to verify that cited algorithm certificate numbers correspond to the implementation and environment in the procurement record.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov
Referenced sections
  • Supports review triggers for historical or revoked module status, bound or embedded modules, and precise certificate identification.
"Historical or Revoked list"
NIST CAVP validation search
csrc.nist.gov
Referenced sections
  • Use this public search to verify that cited algorithm certificate numbers correspond to the implementation and environment in the procurement record.
"Cryptographic Algorithm Validation Lists"
NIST FIPS 197 Advanced Encryption Standard
doi.org
Referenced sections
  • Shows why an AES claim is not enough by itself: FIPS 197 specifies the algorithm, while implementation and module evidence must still be mapped to validation records.
"FIPS-approved cryptographic algorithm"
NIST SP 800-161 Rev. 1 Update 1
doi.org
Referenced sections
  • Supports procurement clauses that define accepted evidence and verification methods for supplier requirements.
"state what is accepted as evidence"
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 and ACVP validation evidence for FIPS algorithms
How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.
CAVP Validation Evidence Workflow for FIPS Algorithms
Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating 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 grounding.
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 approved algorithm selector workflow
A source-linked 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 validation certificates for cryptographic algorithms
How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
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
Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.
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
A grounded 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.