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.

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 artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections6 primary sources
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.
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.
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 type and length checking on every decapsulation; do not run ML-KEM.Decaps when that check fails. For a ciphertext that passes those checks but fails the internal re-encryption comparison, implicit rejection produces a pseudorandom shared-secret output instead of a distinct validity result. 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.
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?
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.
Primary sources

References and citations

NIST FIPS 203 ML-KEM standard
doi.org4 citations
Referenced sections
  • Primary standard for ML-KEM key-encapsulation scope, parameter sets, and implementation conformance claims.
  • Defines ML-KEM as the module-lattice-based key-encapsulation mechanism and lists the ML-KEM parameter sets.
  • Supports evidence fields for ML-KEM use case, parameter-set selection, and related key-establishment assumptions.
Show 1 more
  • Supports limiting FIPS 203 claims to ML-KEM algorithm requirements and implementation conformance rather than full-product validation.
"Module-Lattice-Based Key-Encapsulation Mechanism Standard"
More quoted passages
"ML-KEM-512, ML-KEM-768, and ML-KEM-1024"
"NIST will develop a validation program"
NIST FIPS 204 ML-DSA standard
doi.org4 citations
Referenced sections
  • Primary standard for ML-DSA digital signature scope, signing and verification behavior, and implementation conformance claims.
  • Defines ML-DSA as a post-quantum digital signature standard for generating and verifying signatures.
  • Supports evidence fields for ML-DSA signing, verification, randomness mode, and parameter-set implementation choices.
Show 1 more
  • Supports limiting FIPS 204 claims to ML-DSA signature requirements and implementation conformance.
"Module-Lattice-Based Digital Signature Standard"
More quoted passages
"There are two ways that a signing algorithm can use ML-DSA.Sign_internal"
"NIST will develop a validation program"
NIST FIPS 205 SLH-DSA standard
doi.org4 citations
Referenced sections
  • Primary standard for SLH-DSA stateless hash-based signature scope and implementation conformance claims.
  • Defines SLH-DSA as the stateless hash-based digital signature standard derived from the SPHINCS+ selection.
  • Supports evidence fields for SLH-DSA signature use cases and stateless hash-based implementation choices.
Show 1 more
  • Supports limiting FIPS 205 claims to SLH-DSA signature requirements and implementation conformance.
"Stateless Hash-Based Digital Signature Standard"
More quoted passages
"This standard specifies the stateless hash-based digital signature algorithm"
"NIST will develop a validation program"
CMVP implementation guidance for FIPS 140-3
csrc.nist.gov3 citations
Referenced sections
  • Explains the boundary between CAVP algorithm implementation testing and CMVP cryptographic module validation.
  • Explains that CAVP tests algorithm implementations while CMVP validates cryptographic modules and their tested operational environments.
  • Supports the need to match validated implementation names, versions, certificates, and operational environments before reusing evidence.
"Cryptographic modules are tested and validated under the Cryptographic Module Validation Program"
More quoted passages
"Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program"
"The validation certificate serves as a benchmark"
NIST CAVP validation search
csrc.nist.gov3 citations
Referenced sections
  • Public search page for checking whether a specific algorithm implementation has validation evidence.
  • Public search point for checking whether a specific algorithm implementation has validation evidence.
  • Supports checking algorithm validation records rather than relying on broad supplier wording.
"Cryptographic Algorithm Validation Program"
NIST CMVP project
csrc.nist.gov2 citations
Referenced sections
  • Program page for cryptographic module validation context and certificate-listing resources.
  • Program source for cryptographic module validation information and certificate-listing context.
"Cryptographic Module Validation Program"

Related guides

AES FIPS 197 requirements and evidence

AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.

CAVP Algorithm Validation and ACVP Testing

How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.

CAVP Validation Evidence Workflow for FIPS Algorithms

Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, environments, and CMVP handoff records.

FIPS 180-4 and FIPS 202 secure hash guidance

Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims.

FIPS 186-5 and FIPS 204 digital signatures

Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.

FIPS 203 ML-KEM vs RSA and ECDH key establishment

Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.

Show all related guides (25)

FIPS approved algorithm selector workflow

A cited workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.

FIPS approved mode procurement: certificates, boundaries, and evidence

Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.

FIPS crypto transition and deprecation tracker

Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.

FIPS cryptographic algorithm selector

Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope.

FIPS KDF and MAC coverage for validated modules

Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.

FIPS Key Management Mapping for Algorithms and SSP Evidence

Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.

FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode

Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records.

FIPS-approved cryptographic algorithms FAQ

Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms.

ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5

Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries.

Post-Quantum Migration for FIPS Cryptography

Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries.

Post-Quantum Migration Tracker for FIPS 203, 204, and 205

Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries.

SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202

Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required.

TLS use-case mapping for FIPS algorithm evidence

Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.

FIPS 203, 204, and 205 Post-Quantum Algorithms

FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks.

FIPS Algorithm Procurement Evidence FAQ

What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers.

FIPS validation certificates for cryptographic algorithms

How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.

How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval

Identify SHA-1 and SHA-2 in FIPS 180-4 and SHA-3 and SHAKE in FIPS 202, then check current-use status and CAVP/CMVP evidence separately.

How FIPS 186-5 Signature Algorithms Fit FIPS Approval

Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.

What does FIPS 197 AES mean for FIPS-approved algorithms?

FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation.