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