Artifact GuideGLOBALNIST post-quantum cryptography

Post-quantum FIPS 203, 204, and 205 ML-KEM, ML-DSA, and SLH-DSA

A practical map of what each NIST post-quantum FIPS standard covers and what not to claim from the standard alone.

This helps separate algorithm selection, implementation conformance, CAVP evidence, and FIPS 140-3 module validation evidence.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 25, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 25, 2026

Overview

NIST's first three standards, FIPS 203, FIPS 204, and FIPS 205, were published and became effective on August 13, 2024. FIPS 203 covers ML-KEM for key encapsulation. FIPS 204 covers ML-DSA for digital signatures. FIPS 205 covers SLH-DSA for stateless hash-based digital signatures. They apply to information systems used or operated by US federal agencies or on an agency's behalf, subject to each publication's stated scope and exclusions, and may be adopted voluntarily or by contract elsewhere. None of those labels proves that a shipped product, module, protocol profile, or operational environment is validated.

Section 1

What each post-quantum FIPS standard covers

Start by separating the cryptographic job. FIPS 203 is for a key-encapsulation mechanism, so it belongs in key-establishment and migration discussions. FIPS 204 and FIPS 205 are signature standards, so they belong in authentication, integrity, signing, certificate, firmware, software distribution, or document-signing discussions.

Do not flatten the three standards into one undifferentiated post-quantum requirement. ML-KEM has parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-DSA has ML-DSA-44, ML-DSA-65, and ML-DSA-87. SLH-DSA has 12 approved parameter sets across SHA2 and SHAKE families, with small-signature and fast-signing variants. A design record should name the algorithm family, parameter set, use case, protocol location, and fallback or migration assumptions.

Use FIPS 203 when the decision is about post-quantum key encapsulation or key-establishment migration.
For a new ML-KEM design, document the parameter decision rather than choosing by name alone. FIPS 203 recommends ML-KEM-768 as the default because it provides a large security margin at reasonable performance cost; ML-KEM-512 or ML-KEM-1024 may fit when performance constraints or higher security requirements justify them.
Use FIPS 204 when the decision is about module-lattice-based digital signatures and ML-DSA parameter choices.
Use FIPS 205 when the decision is about stateless hash-based digital signatures and SLH-DSA parameter choices.
Do not compare parameter-set numbers across families as if they were equivalent key sizes; use the security category, performance, key and signature sizes, protocol support, and implementation evidence for the actual choice.
Keep RSA, ECDH, ECDSA, EdDSA, or classical FIPS 186-5 decisions separate from PQC choices unless the design explicitly uses a hybrid or transition pattern.

Sources for this answer

NIST FIPS 203 ML-KEM standard

Defines ML-KEM as the module-lattice-based key-encapsulation mechanism and lists the ML-KEM parameter sets.

NIST FIPS 204 ML-DSA standard

Defines ML-DSA as a post-quantum digital signature standard for generating and verifying signatures.

NIST FIPS 205 SLH-DSA standard

Defines SLH-DSA as the stateless hash-based digital signature standard derived from the SPHINCS+ selection.

Section 2

Where FIPS approval stops and validation evidence starts

A FIPS publication can approve and specify an algorithm, but it is not the same thing as a CAVP certificate for a particular implementation or a CMVP certificate for a cryptographic module. CAVP testing is about cryptographic algorithm implementations. CMVP validation is about cryptographic modules tested against FIPS 140-3 requirements.

For product and supplier evidence, ask what claim is actually being made. If the claim is algorithm conformance, the evidence should identify the algorithm implementation, version, operational environment, and applicable CAVP record when validation evidence is being relied on. If the claim is FIPS 140-3 module validation, the evidence should identify the cryptographic module, certificate, boundary, version, approved mode, and tested operational environment.

Do not call a product FIPS 140-3 validated merely because it uses ML-KEM, ML-DSA, or SLH-DSA.
Do not treat a CAVP algorithm certificate as proof that the full product boundary, module services, or operational environment has been CMVP validated.
When reusing an existing validated module or implementation, verify that the name, version, certificate number, and operational environment match the relying module or product claim.
Record unsupported claims as exceptions rather than turning them into procurement requirements.

Sources for this answer

CMVP implementation guidance for FIPS 140-3

Explains that CAVP tests algorithm implementations while CMVP validates cryptographic modules and their tested operational environments.

NIST CAVP validation search

Public search point for checking whether a specific algorithm implementation has validation evidence.

NIST CMVP project

Program source for cryptographic module validation information and certificate-listing context.

Recommended next step

Map PQC claims to the right FIPS, CAVP, and CMVP evidence

This guide helps keep ML-KEM, ML-DSA, SLH-DSA, algorithm validation, and module validation claims separated before they reach a customer response or audit packet.

Assessment workflow

Open Assessment Autopilot for PQC evidence

Convert post-quantum FIPS choices into scoped tasks, evidence requests, and certificate checks.

Explore next step

Research workflow

Research FIPS source questions

Use cited NIST material to resolve algorithm, validation, and module-boundary questions before implementation.

Explore next step

Talk to Sorena

Talk through implementation

Review algorithm scope, validation evidence, and the next compliance actions with Sorena.

Explore next step

Section 3

Evidence to keep for a post-quantum FIPS decision

Keep a narrow decision record that ties each claim to the standard, algorithm role, implementation, and operating environment. A general statement that the organization is post-quantum ready does not preserve those boundaries.

For ML-KEM, capture the key-establishment use case, parameter set, protocol binding, shared-secret handling, decapsulation failure behavior, and any hybrid transition assumption. K-PKE is an internal component and is not approved as a stand-alone public-key encryption scheme. FIPS 203 requires ciphertext checking on every decapsulation and uses implicit rejection so an invalid ciphertext produces a pseudorandom shared-secret output instead of a validity signal for callers to expose. For ML-DSA or SLH-DSA, capture the signature use case, parameter set, pure or pre-hash approach, context handling, key-purpose separation, verification behavior, and certificate or trust-store dependency.

Algorithm record: FIPS number, algorithm family, parameter set, implementation name, version, and operational environment.
Use-case record: protocol or application layer, key-establishment or signature purpose, and any hybrid or migration behavior.
Validation record: CAVP certificate details for the algorithm implementation when relied on, and CMVP certificate details only when claiming a validated module.
Change record: triggers for reassessment when the implementation, compiler, platform, processor, module boundary, protocol profile, or supplier changes.

Sources for this answer

NIST FIPS 203 ML-KEM standard

Supports evidence fields for ML-KEM use case, parameter-set selection, and related key-establishment assumptions.

NIST FIPS 204 ML-DSA standard

Supports evidence fields for ML-DSA signing, verification, randomness mode, and parameter-set implementation choices.

NIST FIPS 205 SLH-DSA standard

Supports evidence fields for SLH-DSA signature use cases and stateless hash-based implementation choices.

Section 4

Review questions before design, procurement, or audit use

Use these questions before publishing a claim, accepting a supplier statement, or wiring a PQC choice into a control set. The goal is to prevent an approved-algorithm statement from being mistaken for validated-module evidence or a complete migration plan.

Answers should be tied to source URLs and certificate identifiers where certificates are relevant. If the evidence is not available or not applicable, say so plainly and keep the decision as an engineering or policy assumption.

Which exact algorithm family and parameter set are in scope: ML-KEM, ML-DSA, or SLH-DSA?
Is the claim about using a FIPS-specified algorithm, a CAVP-tested implementation, or a FIPS 140-3 validated module?
Does the tested operational environment match the product, service, device, processor, operating system, hypervisor, or embedded boundary being claimed?
If a supplier provides a certificate number, does the certificate cover the algorithm, implementation version, module boundary, and approved mode that the product actually uses?
What changes require re-review before the same evidence can be reused?

Sources for this answer

CMVP implementation guidance for FIPS 140-3

Supports the need to match validated implementation names, versions, certificates, and operational environments before reusing evidence.

NIST CAVP validation search

Supports checking algorithm validation records rather than relying on broad supplier wording.

Section 5

Claims to avoid

The most common error is overstatement. A page, RFP response, or control narrative should not imply that a post-quantum FIPS reference validates an entire product, certifies a supplier, or proves protocol-level interoperability.

Keep public language precise. Say that a design uses an algorithm specified in FIPS 203, FIPS 204, or FIPS 205 only when that is the supported claim. Add CAVP or CMVP language only when the relevant validation evidence is identified and matches the implementation or module boundary.

Avoid "PQC certified" unless the specific certificate program, certificate number, and scope are named.
Avoid "FIPS 203/204/205 compliant product" when only the algorithm choice has been identified.
Avoid using one certificate to cover another implementation, version, processor class, operating environment, or module boundary.
Avoid procurement clauses that demand validation evidence without saying whether the request is for algorithm implementation validation, module validation, or a design statement.

Sources for this answer

NIST FIPS 203 ML-KEM standard

Supports limiting FIPS 203 claims to ML-KEM algorithm requirements and implementation conformance rather than full-product validation.

NIST FIPS 204 ML-DSA standard

Supports limiting FIPS 204 claims to ML-DSA signature requirements and implementation conformance.

NIST FIPS 205 SLH-DSA standard

Supports limiting FIPS 205 claims to SLH-DSA signature requirements and implementation conformance.

Primary sources