---
title: "Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205"
author: "Sorena AI"
description: "An official source guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 203"
  - "FIPS 204"
  - "FIPS 205"
  - "ML-KEM"
  - "ML-DSA"
  - "SLH-DSA"
  - "CAVP"
  - "CMVP"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

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

An official source guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ.

*Artifact Guide* *GLOBAL* *NIST 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.

FIPS 203, FIPS 204, and FIPS 205 standardize three post-quantum algorithm families for federal use cases and voluntary private adoption. 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. None of those labels, by itself, proves that a shipped product, module, protocol profile, or operational environment is validated.

## 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 and SLH-DSA are both signature choices, but they have different constructions and implementation considerations. A defensible design record names 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.
- 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.
- 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](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Defines ML-KEM as the module-lattice-based key-encapsulation mechanism and lists the ML-KEM parameter sets.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Defines ML-DSA as a post-quantum digital signature standard for generating and verifying signatures.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Defines SLH-DSA as the stateless hash-based digital signature standard derived from the SPHINCS+ selection.

## 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains that CAVP tests algorithm implementations while CMVP validates cryptographic modules and their tested operational environments.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search point for checking whether a specific algorithm implementation has validation evidence.
- [NIST CMVP project](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program source for cryptographic module validation information and certificate-listing context.

*Recommended next step*

*Placement: after practical guidance*

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

- [Open Assessment Autopilot for PQC evidence](/solutions/assessment.md): Convert post-quantum FIPS choices into scoped tasks, evidence requests, and certificate checks.
- [Research FIPS source questions](/solutions/research-copilot.md): Use cited NIST material to resolve algorithm, validation, and module-boundary questions before implementation.
- [Talk through implementation](/contact.md): Review algorithm scope, validation evidence, and the next compliance actions with Sorena.

## Evidence to keep for a post-quantum FIPS decision

The useful artifact is a narrow decision record, not a broad statement that the organization is post-quantum ready. Tie each claim to the standard, the algorithm role, the implementation, and the environment where it will run.

For ML-KEM, capture the key-establishment use case, parameter set, protocol binding, shared-secret handling, and any hybrid transition assumption. For ML-DSA or SLH-DSA, capture the signature use case, parameter set, direct-signing or pre-hash approach where applicable, 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](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports evidence fields for ML-KEM use case, parameter-set selection, and related key-establishment assumptions.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports evidence fields for ML-DSA signing, verification, randomness mode, and parameter-set implementation choices.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports evidence fields for SLH-DSA signature use cases and stateless hash-based implementation choices.

## 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the need to match validated implementation names, versions, certificates, and operational environments before reusing evidence.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Supports checking algorithm validation records rather than relying on broad supplier wording.

## 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](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports limiting FIPS 203 claims to ML-KEM algorithm requirements and implementation conformance rather than full-product validation.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports limiting FIPS 204 claims to ML-DSA signature requirements and implementation conformance.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports limiting FIPS 205 claims to SLH-DSA signature requirements and implementation conformance.

## Primary sources

- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary standard for ML-KEM key-encapsulation scope, parameter sets, and implementation conformance claims.
  - Quote: "Module-Lattice-Based Key-Encapsulation Mechanism Standard"
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Primary standard for ML-DSA digital signature scope, signing and verification behavior, and implementation conformance claims.
  - Quote: "Module-Lattice-Based Digital Signature Standard"
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Primary standard for SLH-DSA stateless hash-based signature scope and implementation conformance claims.
  - Quote: "Stateless Hash-Based Digital Signature Standard"
- [CMVP implementation guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains the boundary between CAVP algorithm implementation testing and CMVP cryptographic module validation.
  - Quote: "Cryptographic modules are tested and validated under the Cryptographic Module Validation Program"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for checking whether a specific algorithm implementation has validation evidence.
  - Quote: "validation-search"
- [NIST CMVP project](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program page for cryptographic module validation context and certificate-listing resources.
  - Quote: "Cryptographic Module Validation Program"

## Related Topic Guides

- [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): 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](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): 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](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): 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](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): 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](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): 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](/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh.md): Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.
- [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md): 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](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md): 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 approved algorithm selector workflow](/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow.md): 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](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): 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](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): 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](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): 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](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): 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](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): 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](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): 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 validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md): How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
- [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): 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.
- [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md): 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](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md): Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.
- [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): 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](/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3.md): 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](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.
- [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md): 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.


---

[Privacy Policy](https://www.sorena.io/privacy.md) | [Terms of Use](https://www.sorena.io/terms-of-use.md) | [DMCA](https://www.sorena.io/dmca.md) | [About Us](https://www.sorena.io/about-us.md)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md