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.

Global FIPS Crypto Algorithms · FAQ index

Questions and answers

Search the answers across this artifact’s FAQ modules. Open any answer in its guide or copy a direct link to share it.

25 questions across 6 modules

Back to FAQ overview
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Browse 6 FAQ modules

Showing 1–15 of 25 questions

FIPS 203, 204, and 205 Post-Quantum Algorithms

What do FIPS 203, FIPS 204, and FIPS 205 cover?

FIPS 203 covers ML-KEM, a module-lattice-based used to establish a shared secret key over a public channel. It is the post-quantum key-establishment standard in this set, not a digital signature standard.

FIPS 204 covers ML-DSA, a module-lattice-based digital signature algorithm for generating and verifying signatures. FIPS 205 covers SLH-DSA, a stateless hash-based digital signature algorithm based on SPHINCS+. Both signature standards apply to public-key-based signature systems operated by federal agencies or operated for them under contract, and their use is also available to private and commercial organizations.

  • Use FIPS 203 when the scoped function is ML-KEM key generation, encapsulation, or decapsulation.
  • Use FIPS 204 when the scoped function is ML-DSA key generation, signature generation, signature verification, or the pre-hash variants supported by the standard.
  • Use FIPS 205 when the scoped function is SLH-DSA key generation, signature generation, signature verification, or approved SHA2/SHAKE parameter-set use.
Read answer in guideOpen FAQ module
FIPS 203, 204, and 205 Post-Quantum Algorithms

What implementation evidence should teams keep?

The evidence should show the algorithm, parameter set, module boundary, and interface actually used. A bare statement that a product is post-quantum or FIPS-ready is not enough because the NIST standards include parameter-set choices, input checks, approved random bit generation, private-key or decapsulation-key safeguards, and restrictions on exposing testing-only internal interfaces. NIST has posted potential-update errata for FIPS 203 and FIPS 204, so the implementation record should identify the issued standard and the errata version reviewed.

For ML-KEM, record the chosen parameter set and whether encapsulation keys, decapsulation keys, and ciphertexts are checked before use. FIPS 203 maps ML-KEM-512, ML-KEM-768, and ML-KEM-1024 to increasing NIST and recommends ML-KEM-768 as the default unless that is impractical or a different security requirement applies. For ML-DSA, record whether ML-DSA-44, ML-DSA-65, or ML-DSA-87 is used and confirm signature length, public-key length, random seed, and intermediate-data handling requirements. For SLH-DSA, record the SHA2 or SHAKE parameter set, whether the small-signature or fast-signature variant is used, and the key-generation and signing randomness requirements.

  • Map each public claim to a scoped cryptographic function: ML-KEM key establishment, ML-DSA signatures, or SLH-DSA signatures.
  • Store parameter-set evidence, implementation version, module boundary, operating environment, and whether the function is used in an approved mode.
  • Keep test and design evidence separate from certification claims; passing internal tests or using an approved algorithm name does not by itself prove a module is CMVP-validated.
Read answer in guideOpen FAQ module
FIPS 203, 204, and 205 Post-Quantum Algorithms

How should CAVP and CMVP validation claims be handled?

Use cautious wording. CAVP now publishes validation records for ML-KEM, ML-DSA, and SLH-DSA implementations, and the CMVP implementation guidance adds cryptographic algorithm self-test requirements for these algorithms. Those records support algorithm-conformance claims for the named implementation and tested operational environment. They do not justify saying that a product, library, or cloud service is FIPS 140-3 validated unless the relevant CMVP certificate and Security Policy support that exact module, version, environment, approved mode, and service.

For procurement, customer security reviews, and audit responses, verify the CAVP algorithm entry or CMVP module certificate against the algorithm, parameter set, module name, version, implementation environment, and approved-mode statement. If a supplier only provides roadmap language, test vectors, or an algorithm name, describe it as implementation evidence or migration status rather than validated FIPS evidence.

  • Check the public CAVP validation search for algorithm evidence before citing an algorithm certificate.
  • Check CMVP module documentation before claiming a module is FIPS 140-3 validated or that post-quantum functionality is inside the validated boundary.
  • Record unresolved gaps explicitly, such as missing certificate scope, unsupported parameter set, non-approved mode, unvalidated module boundary, or supplier roadmap-only support.
Read answer in guideOpen FAQ module
FIPS 203, 204, and 205 Post-Quantum Algorithms

Questions and answers

When should a team use FIPS 203 instead of FIPS 204 or FIPS 205?

Use FIPS 203 when the scoped function is ML-KEM key establishment, including key generation, encapsulation, or decapsulation. Use FIPS 204 when the scoped function is ML-DSA digital signatures, and use FIPS 205 when the scoped function is SLH-DSA stateless hash-based digital signatures. FIPS 203 covers a , while FIPS 204 and FIPS 205 cover digital signature standards.

Which parameter set should teams default to for FIPS 203 and how do the differ?

NIST recommends ML-KEM-768 as the default parameter set because it provides a large security margin at a reasonable performance cost. The three parameter sets are ML-KEM-512 (security category 1), ML-KEM-768 (security category 3), and ML-KEM-1024 (security category 5).

What evidence should support claims about FIPS 203, FIPS 204, or FIPS 205 implementations?

Keep the algorithm, parameter set, module boundary, implementation version, operating environment, and approved mode in scope. CAVP now publishes validation records for ML-KEM, ML-DSA, and SLH-DSA implementations, but a CAVP algorithm record does not by itself prove that a product, library, or module is CMVP-validated. For procurement or audit responses, check the exact CAVP record and, for a module-validation claim, the applicable CMVP certificate and Security Policy.

How should teams handle randomness and side-channel concerns for these post-quantum standards?

Use an approved random bit generator for the random seeds and values that each selected operation requires. ML-KEM key generation and encapsulation require fresh random inputs. ML-DSA and SLH-DSA key generation require randomness, while signing can use deterministic or hedged variants; hedged signing adds fresh randomness and can reduce some side-channel and fault-attack risks. Record which variant the implementation uses and protect or destroy secret intermediate values as the applicable standard requires.

Do the published FIPS 203 and FIPS 204 texts have known errata?

Yes. NIST has posted potential-update errata for FIPS 203 and FIPS 204 and says the identified issues will be corrected in future updates or revisions. Use the issued standards together with the current NIST publication pages and errata when implementing or reviewing conformance; do not silently rewrite the standard or claim that an erratum is already part of a revised FIPS.

Read answer in guideOpen FAQ module
FIPS Algorithm Procurement Evidence

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.
Read answer in guideOpen FAQ module
FIPS Algorithm Procurement Evidence

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.
Read answer in guideOpen FAQ module
FIPS Algorithm Procurement Evidence

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.
Read answer in guideOpen FAQ module
FIPS Algorithm Procurement Evidence

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.

Read answer in guideOpen FAQ module
FIPS validation certificates for cryptographic algorithms

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.
Read answer in guideOpen FAQ module
FIPS validation certificates for cryptographic algorithms

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.
Read answer in guideOpen FAQ module
FIPS validation certificates for cryptographic algorithms

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.
Read answer in guideOpen FAQ module
FIPS validation certificates for cryptographic algorithms

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.
Read answer in guideOpen FAQ module
FIPS validation certificates for cryptographic algorithms

Questions and answers

What is the difference between a CAVP certificate and a CMVP certificate?

A CAVP certificate supports a tested cryptographic algorithm implementation, while a CMVP certificate supports a validated cryptographic module. The CMVP guidance says the algorithm certificate states the implementation name, version number, and tested , while the module certificate states the validated module name, version number, and tested operational environment.

Does a cover my deployed product automatically?

No. The certificate is only a benchmark for the configuration and used during validation testing. For software modules, compare the tested operating system, platform, processor, and hypervisor details against the deployed environment before reusing the evidence.

Can I say the whole product is FIPS validated if one algorithm has a certificate?

No. A CAVP algorithm certificate does not by itself prove the product is a FIPS 140-3 validated module. Use the module certificate, , and deployment mapping to show the exact scope of the claim.

Does Historical status mean a CMVP certificate was revoked?

No. Historical status means the certificate or documentation is old or affected by a program transition and should not support a new federal system. It may still be considered for a legacy system under the responsible agency's decision. Revoked status is different: the validation is no longer valid and cannot demonstrate compliance with the FIPS 140 standards.

Read answer in guideOpen FAQ module
How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval

Which hash functions come from FIPS 180-4 and FIPS 202?

FIPS 180-4 is the current issued Secure Hash Standard for SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 is the current issued standard for the SHA-3 family: SHA3-224, SHA3-256, SHA3-384, and SHA3-512. It also specifies SHAKE128 and SHAKE256; each is an whose output length is selected by the application. NIST has announced plans to revise FIPS 180-4 and update FIPS 202, but those announcements do not replace the issued standards.

For a FIPS-approved algorithm decision, start by naming the exact function and use case. A message digest for digital signatures, an HMAC construction, a KDF, a DRBG, a post-quantum algorithm component, and a standalone SHAKE use can have different validation evidence even when the same hash family appears in the design.

SHA-1 needs a use-specific transition check. FIPS 180-4 still specifies SHA-1, but NIST transition guidance disallows SHA-1 for ordinary digital-signature generation while allowing legacy signature verification and some protocol-specific uses under stated conditions. Do not infer an approved current use from the fact that SHA-1 remains in the hash standard.

  • Use FIPS 180-4 to identify the SHA-1 or SHA-2 digest specification, but check the current approved-use source before treating a particular SHA-1 operation as approved.
  • Use FIPS 202 when the decision is about SHA-3 hash functions or SHAKE extendable-output functions.
  • Do not treat the standard name alone as proof that a product, library, or module is validated.
Read answer in guideOpen FAQ module
How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval

What evidence proves the hash implementation is approved?

The useful evidence is not a screenshot that says SHA-256 or SHA3-256 exists. Record the algorithm certificate or validation result for the exact implementation name, version, algorithm, parameters, and tested operational environment.

Keep that algorithm evidence separate from the module evidence. validates algorithm implementations; validates cryptographic modules under FIPS 140-3. A module claim needs the module certificate, approved-mode documentation, and security policy scope, not only a hash-algorithm certificate.

  • Capture the algorithm name, certificate number or validation entry, implementation version, vendor, and tested operating environment.
  • For software modules, compare the operating environment with the module operating environment before relying on the certificate.
  • For a FIPS 140-3 claim, tie the hash evidence to the validated module boundary and approved services shown in -facing documentation.
Read answer in guideOpen FAQ module