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

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 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 May 9, 2026

Overview

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.

Section 1

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

Supports treating ML-KEM as the FIPS-standardized post-quantum key-encapsulation mechanism for key-establishment migration.

NIST FIPS 204 ML-DSA standard

Supports treating ML-DSA as a FIPS-standardized post-quantum digital signature option.

NIST FIPS 205 SLH-DSA standard

Supports treating SLH-DSA as the FIPS-standardized stateless hash-based digital signature option.

Section 2

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

Identifies the approved ML-KEM parameter sets that migration records should name instead of using generic PQC labels.

NIST FIPS 204 ML-DSA standard

Supports separating digital signature migration from key-establishment migration.

NIST FIPS 205 SLH-DSA standard

Supports considering SLH-DSA where a stateless hash-based signature design is the intended migration path.

Section 3

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

Supports separating cryptographic module validation requirements from algorithm-standard selection.

CMVP Implementation Guidance for FIPS 140-3

Supports evidence planning for module self-tests, ML-KEM handling, and CMVP validation guidance without overstating certificate status.

NIST CAVP project

Supports using CAVP as the algorithm-validation evidence track, distinct from CMVP module validation.

Recommended next step

Operationalize post-quantum migration

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

Assessment workflow

Open Assessment Autopilot for FIPS cryptography

Convert post-quantum migration scope, validation gaps, and evidence owners into accountable review tasks.

Explore next step

Research workflow

Research FIPS cryptography source questions

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

Explore next step

Talk to Sorena

Talk through implementation

Review scope, evidence, owners, and the next post-quantum migration actions with Sorena.

Explore next step

Section 4

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

Supports using NIST's PQC project as the source context for migration tracking and future algorithm updates.

NIST FIPS 203 ML-KEM standard

Supports the key-establishment fields in the inventory and decision record.

CMVP Implementation Guidance for FIPS 140-3

Supports including module boundary, approved mode, self-test, and revalidation fields in the evidence checklist.

Section 5

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

Supports source-linked wording for ML-KEM claims in migration communications.

NIST FIPS 204 ML-DSA standard

Supports source-linked wording for ML-DSA signature claims.

NIST FIPS 205 SLH-DSA standard

Supports source-linked wording for SLH-DSA signature claims.

NIST CMVP project

Supports requiring separate evidence for cryptographic module validation claims.

Primary sources