FIPS 203, 204, and 205 post-quantum algorithms What teams need to evidence before making FIPS-approved algorithm claims

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.

For ML-KEM, record the chosen parameter set and whether encapsulation keys, decapsulation keys, and ciphertexts are checked before use. FIPS 203 recommends ML-KEM-768 as the default parameter set 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. The three standards say NIST will develop validation programs to test implementations for conformance to the algorithms in this standard, and the CMVP implementation guidance adds cryptographic algorithm self-test requirements for ML-KEM, ML-DSA, and SLH-DSA. That supports planning and evidence collection, but it does not justify saying that a product, library, or cloud service is validated unless the relevant certificate or module listing supports that exact scope.

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.