Search every question across sub-FAQs

FIPS 203 covers ML-KEM, a module-lattice-based key-encapsulation mechanism 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.

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

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.

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.

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.

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.

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

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

A validation certificate is a benchmark for the configuration and operational environment 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.

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, operational environment, 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 validation certificate, 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.

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.

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 extendable-output function 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.

The useful evidence is not a screenshot that says SHA-256 or SHA3-256 exists. Record the CAVP 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. CAVP validates algorithm implementations; CMVP 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.

Do not treat every FIPS 202 function as interchangeable. SHA-3 hash functions can appear as standalone functions or inside approved higher-level algorithms when the relevant testing path supports that use. CMVP implementation guidance is more restrictive for SHAKE128 and SHAKE256: outside algorithm standards that explicitly allow them, SHAKE functions are used as standalone algorithms.

A second mistake is importing a hash certificate into a higher-level claim without checking whether the higher-level algorithm has its own CAVP testing requirement or vendor-affirmed path. That matters for signatures, KDFs, DRBGs, and module approved-service listings.

Use FIPS 186-5 when the decision is about digital signature generation or verification for RSA, ECDSA, deterministic ECDSA, EdDSA, or HashEdDSA. FIPS 186-5 became effective on February 3, 2023; its one-year transition ended when FIPS 186-4 was withdrawn on February 3, 2024. DSA is no longer approved for digital signature generation, although DSA may be used to verify signatures generated before the FIPS 186-5 implementation date. NIST has posted potential-update errata for FIPS 186-5, so implementation reviews should use the issued standard together with the current errata.

The selection record should name the exact signature family, operation, parameters, key purpose, and approved hash or XOF relationship. For RSA, FIPS 186-5 permits signature generation or verification with modulus sizes at least 2048 bits, while CMVP implementation guidance explains how CAVP testing and Security Policy documentation handle sizes where CAVP testing is or is not available.

A useful evidence package starts with the standard citation but does not stop there. Keep the FIPS 186-5 algorithm decision, the CAVP algorithm-validation record, and the CMVP module claim as separate records that are linked only when the implementation name, version, parameters, and operating environment match.

For a CAVP check, capture the implementation name and version, vendor, certificate or validation-search entry, algorithm and mode, parameter set or modulus size, and tested operating environment. For a CMVP check, tie the signature service to the cryptographic module boundary, approved-mode service list, Security Policy, and any bound or embedded module caveats.