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

Based on 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
Jul 25, 2026
4 sections6 primary sources
Overview

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

4 of 4 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 , , or security-policy mapping is provided.
Recommended next step

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

This FAQ helps 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: numbers for algorithm implementations and 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.
Question 3

What review checks prevent weak FIPS procurement files?

Do not accept evidence that proves a different 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.

Certificate status changes need different decisions. An Active CMVP listing can support new and existing federal systems when the deployment matches the listing. A Historical listing is not a revocation, but NIST says federal agencies should not use it for new systems; it may still support a documented legacy-system decision. A Revoked listing is no longer valid evidence of compliance with the FIPS 140 standards.

  • Check whether the module is Active, Historical, or Revoked and apply the status to the intended new-system or legacy-system procurement decision.
  • 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.
Question 4

Questions and answers

Is a supplier statement that a product uses AES enough ?

No. The statement identifies an algorithm family, not the tested implementation or validated module. Ask for the relevant CAVP algorithm entry, the CMVP module certificate and security policy when module validation is claimed, and a mapping from the purchased product version and deployment environment to that evidence.

Can a Historical be accepted for a new procurement?

For U.S. federal use, NIST says modules on the Historical list should not be included in new systems, although they may still be procured for legacy systems. A Historical certificate is not revoked, but its documentation may not reflect current guidance or transitions. Record whether the purchase supports a new or existing system and obtain the responsible authority's decision.

What supplier change should reopen the FIPS evidence review?

Reopen the review when the cryptographic module or library changes, the product or firmware version changes, a new processor or operating environment is added, the module boundary or approved-service configuration changes, or a CAVP or CMVP listing changes status. The supplier should identify which certificates and security-policy statements remain applicable after the change.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov4 citations
Referenced sections
  • Primary official source for CAVP versus CMVP evidence, operational environment matching, security-policy evidence, and approved-service indicators.
  • Supports the distinction between CAVP-tested algorithm implementations and CMVP-validated cryptographic modules.
  • Supports collecting security-policy evidence for approved and non-approved services and externally accessible service indicators.
Show 1 more
  • Supports review triggers for historical or revoked module status, bound or embedded modules, and precise certificate identification.
"tested operational environment"
More quoted passages
"complete list of all approved and non-approved services"
"Historical or Revoked list"
NIST CAVP validation search
csrc.nist.gov3 citations
Referenced sections
  • Public source for verifying CAVP algorithm certificates cited in supplier procurement evidence.
  • Use the public CAVP search to check algorithm certificate numbers, implementation names, versions, and operational environments cited by a supplier.
  • This public search helps verify that cited algorithm certificate numbers correspond to the implementation and environment in the procurement record.
"Cryptographic Algorithm Validation Program"
NIST FIPS 140-3 security requirements for cryptographic modules
doi.org3 citations
Referenced sections
  • Primary standard for cryptographic module security requirements and procurement relevance of validated modules.
  • Explains why validated cryptographic modules are used as a procurement security metric for equipment containing cryptographic modules.
  • Supports scoping review around cryptographic module security requirements rather than broad product-level marketing claims.
"cryptographic modules"
More quoted passages
"security metric"
"cryptographic module"
NIST CMVP validated modules and certificate status guidance
csrc.nist.gov2 citations
Referenced sections
  • Official guidance for Active, Historical, and Revoked module certificate status and its effect on new and legacy federal systems.
  • Explains the procurement consequences of Active, Historical, and Revoked certificate status, including the distinction between new and legacy federal systems.
NIST FIPS 197 Advanced Encryption Standard
doi.org2 citations
Referenced sections
  • Primary standard showing that AES is a FIPS-approved algorithm, separate from proof that a product or module is validated.
  • 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.
"Advanced Encryption Standard (AES)"
More quoted passages
"FIPS-approved cryptographic algorithm"
NIST SP 800-161 Rev. 1 Update 1
doi.org2 citations
Referenced sections
  • Supports defining accepted supply-chain evidence and verification methods in procurement contracts.
  • Supports procurement clauses that define accepted evidence and verification methods for supplier requirements.
"state what is accepted as evidence"

Related guides

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

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.

Show all related guides (25)

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

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.