---
title: "Post-Quantum Migration for FIPS Cryptography"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-migration"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-migration"
author: "Sorena AI"
description: "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."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "post-quantum migration"
  - "FIPS 203"
  - "FIPS 204"
  - "FIPS 205"
  - "ML-KEM"
  - "ML-DSA"
  - "SLH-DSA"
  - "CAVP"
  - "CMVP"
  - "FIPS 140-3"
  - "FIPS cryptography"
  - "post-quantum cryptography"
---
**[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 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.

*Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithms*

## Post-quantum migration for FIPS cryptography

Use this guide to inventory classical public-key use, choose the right NIST post-quantum primitive, and keep validation claims separate from migration planning.

Grounded in NIST FIPS 203, FIPS 204, FIPS 205, FIPS 140-3, and CMVP implementation guidance. Use it as implementation guidance, not for legal interpretation.

Post-quantum migration is not a single algorithm swap. Teams need to identify where public-key cryptography is used, decide whether the use case is key establishment or signatures, map the design to ML-KEM, ML-DSA, or SLH-DSA, and keep evidence clear about whether the claim is algorithm approval, CAVP algorithm validation, or FIPS 140-3 module validation.

## Start with a cryptographic-use inventory

Begin by listing every place the product, service, or module uses public-key cryptography. Separate key establishment from digital signatures before selecting a post-quantum algorithm. ML-KEM under FIPS 203 is a key-encapsulation mechanism; ML-DSA under FIPS 204 and SLH-DSA under FIPS 205 are digital signature standards.

For each use case, record the protocol, algorithm, parameter set, key lifecycle, data protected, performance constraint, certificate dependency, and whether the implementation sits inside a FIPS 140-3 cryptographic module boundary. This prevents a migration plan from treating TLS negotiation, firmware signing, document signing, code signing, and stored-data signatures as the same problem.

- Classify each use as key establishment, signature generation, signature verification, certificate validation, or legacy dependency.
- Map key-establishment candidates to ML-KEM only when the design actually needs encapsulation and decapsulation behavior.
- Map signature candidates to ML-DSA or SLH-DSA only after recording message size, signing frequency, verification environment, key-management model, and interoperability constraints.
- Keep classical algorithms such as RSA, ECDSA, ECDH, and finite-field schemes visible in the inventory so hybrid, fallback, and deprecation decisions are explicit.

Sources for this answer:

- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports treating ML-KEM as the FIPS-standardized post-quantum key-encapsulation mechanism for key-establishment migration.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports treating ML-DSA as a FIPS-standardized post-quantum digital signature option.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports treating SLH-DSA as the FIPS-standardized stateless hash-based digital signature option.

## Choose algorithms by use case, not by one migration label

A useful migration record names the exact primitive and parameter set being considered. For key establishment, document whether the candidate is ML-KEM-512, ML-KEM-768, or ML-KEM-1024 and why that level matches the system risk and interoperability plan. For signatures, document whether ML-DSA or SLH-DSA better fits the signing workflow, relying-party environment, and operational constraints.

Do not write that a product is "post-quantum compliant" just because it references one of the new FIPS publications. The supportable claim is narrower: a design selected a FIPS-standardized algorithm, an implementation may be tested for algorithm conformance through CAVP when the relevant testing applies, and a cryptographic module claim depends on CMVP/FIPS 140-3 validation for the module boundary.

- Use ML-KEM language for encapsulation, decapsulation, shared-secret establishment, and related key-establishment evidence.
- Use ML-DSA or SLH-DSA language for signing, verification, public-key distribution, signature size, and relying-party verification evidence.
- Record any hybrid classical-plus-post-quantum design as an implementation and interoperability decision, not as a fact implied by FIPS 203, FIPS 204, or FIPS 205 alone.
- Track parameter-set decisions separately from protocol decisions because a standard algorithm can still be deployed incorrectly for a specific protocol or product boundary.

Sources for this answer:

- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Identifies the approved ML-KEM parameter sets that migration records should name instead of using generic PQC labels.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports separating digital signature migration from key-establishment migration.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports considering SLH-DSA where a stateless hash-based signature design is the intended migration path.

## Keep CAVP and CMVP evidence separate

Post-quantum migration evidence should not collapse algorithm conformance, self-test behavior, and module validation into one claim. CAVP evidence concerns algorithm testing. CMVP evidence concerns a cryptographic module validation under FIPS 140-3. A procurement or audit package needs both boundaries stated plainly.

The CMVP implementation guidance includes post-quantum self-test guidance and ML-KEM treatment under key-agreement methods. That helps a module team understand what a validation package may need to address, but it does not by itself prove that a specific shipped product has a current validation certificate.

- For each implementation, record the algorithm, parameter set, implementation version, CAVP certificate evidence when available, and the module that consumes the implementation.
- For each FIPS 140-3 claim, record the module name, module version, operational environment, Security Policy, approved mode statement, and certificate status.
- For each migration exception, record whether the blocker is algorithm availability, protocol support, lab testing, customer interoperability, hardware acceleration, certificate dependency, or module revalidation timing.
- Avoid procurement wording that says "FIPS validated algorithm" when the evidence only shows selection of a FIPS-standardized algorithm or a plan to seek validation.

Sources for this answer:

- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports separating cryptographic module validation requirements from algorithm-standard selection.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Supports evidence planning for module self-tests, ML-KEM handling, and CMVP validation guidance without overstating certificate status.
- [NIST CAVP project](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Supports using CAVP as the algorithm-validation evidence track, distinct from CMVP module validation.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize post-quantum migration

Use this FIPS cryptography guidance to separate algorithm selection, CAVP evidence, CMVP module status, and customer-facing migration claims.

- [Open Assessment Autopilot for FIPS cryptography](/solutions/assessment.md): Convert post-quantum migration scope, validation gaps, and evidence owners into accountable review tasks.
- [Research FIPS cryptography source questions](/solutions/research-copilot.md): Use cited NIST source material to resolve algorithm, validation, and module-boundary questions before implementation.
- [Talk through implementation](/contact.md): Review scope, evidence, owners, and the next post-quantum migration actions with Sorena.

## Migration evidence checklist

Use this checklist as the page-level evidence model for a post-quantum migration workstream. Each item should be traceable to a product boundary, release, protocol, module, or customer-facing claim.

The best evidence is specific enough for engineering and procurement to act on. It should show what changed, what stayed classical, what remains dependent on external libraries or protocols, and what validation evidence exists today versus what is planned.

- Inventory: list every RSA, ECDSA, ECDH, finite-field, ML-KEM, ML-DSA, and SLH-DSA use with product version and owner.
- Decision record: state whether each use case is keep, replace, hybridize, monitor, or retire, and name the source-linked reason.
- Algorithm record: include selected algorithm, parameter set, implementation version, CAVP status or gap, and any known protocol constraints.
- Module record: include FIPS 140-3 module boundary, Security Policy impact, approved-mode impact, self-test impact, and revalidation trigger.
- Customer record: separate public roadmap language from validated-product language so sales, security questionnaires, and procurement responses do not overclaim.

Sources for this answer:

- [NIST Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography?ref=sorena.io) - Supports using NIST's PQC project as the source context for migration tracking and future algorithm updates.
- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports the key-establishment fields in the inventory and decision record.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Supports including module boundary, approved mode, self-test, and revalidation fields in the evidence checklist.

## Review gates before publishing a migration claim

Before publishing roadmap, compliance, or procurement language, route the claim through three gates. First, engineering confirms the cryptographic use case and implementation boundary. Second, security or compliance confirms the source-linked algorithm and validation evidence. Third, product or sales confirms the wording does not imply a validated module or deployed customer capability that does not exist.

This review should be repeated after a library change, firmware release, protocol update, lab submission, certificate update, customer commitment, or NIST guidance update. The goal is not to delay migration; it is to prevent a useful PQC roadmap from becoming an unsupported compliance claim.

- Engineering gate: confirm the algorithm, parameter set, protocol, implementation version, and affected release.
- Validation gate: confirm CAVP algorithm evidence, CMVP module evidence, or the exact gap if validation evidence is not yet available.
- Procurement gate: replace broad claims with scoped language such as "uses ML-KEM in this component" or "planned for the next FIPS 140-3 module submission" when that is what the evidence supports.
- Change gate: reopen the record when NIST publications, CMVP guidance, CAVP testing, module boundaries, or customer requirements change.

Sources for this answer:

- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports source-linked wording for ML-KEM claims in migration communications.
- [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports source-linked wording for ML-DSA signature claims.
- [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports source-linked wording for SLH-DSA signature claims.
- [NIST CMVP project](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Supports requiring separate evidence for cryptographic module validation claims.

## Primary sources

- [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary source for ML-KEM as the FIPS-standardized post-quantum key-encapsulation mechanism.
  - 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 source for ML-DSA as a FIPS-standardized post-quantum digital signature algorithm.
  - 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 source for SLH-DSA as a FIPS-standardized stateless hash-based digital signature algorithm.
  - Quote: "Stateless Hash-Based Digital Signature Standard"
- [NIST CAVP project](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Public NIST project page for algorithm validation evidence, separate from module validation.
  - Quote: "Cryptographic Algorithm Validation Program"
- [NIST CMVP project](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Public NIST project page for FIPS 140-3 module validation context.
  - 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 and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.
- [CAVP Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating 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 grounding.
- [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 source-linked 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): Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.
- [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 FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded 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.
- [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) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

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

Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-migration