--- title: "Post-Quantum Migration Tracker for FIPS 203, 204, and 205" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 203" - "FIPS 204" - "FIPS 205" - "ML-KEM" - "ML-DSA" - "SLH-DSA" - "post-quantum migration tracker" - "CAVP" - "CMVP" - "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 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. *Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithm requirements* ## Post-quantum migration FIPS evidence tracker Track where ML-KEM, ML-DSA, and SLH-DSA affect products, protocols, certificates, and validation evidence without inventing unsupported migration dates or readiness status. Grounded in NIST FIPS 203, FIPS 204, FIPS 205, CAVP, and CMVP source material. Use this tracker to inventory cryptographic uses that may need post-quantum review and to record the evidence that supports each decision. The tracker should identify the algorithm role, FIPS source, parameter set, implementation boundary, CAVP evidence, and CMVP module impact. It should not claim that a product is post-quantum ready, validated, or migrated unless the matching certificate, module boundary, and operational environment evidence exists. ## Tracker rows should start with the cryptographic role, not a migration status Begin each row by naming the product, protocol, service, library, firmware image, or cryptographic module boundary where the primitive is used. Then classify the role: key establishment, digital signature generation, signature verification, certificate issuance, firmware signing, code signing, TLS termination, VPN, SSH, KMS, HSM, or embedded device update. Only after the role is clear should the row map to FIPS 203, FIPS 204, or FIPS 205. FIPS 203 specifies ML-KEM for establishing a shared secret key. FIPS 204 specifies ML-DSA for digital signatures. FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. A row that only says "PQC" is not specific enough for engineering, procurement, or validation review. - Track ML-KEM rows for key-establishment uses, including where the resulting shared secret feeds symmetric encryption, authentication, or a protocol key schedule. - Track ML-DSA rows for lattice-based signature generation and verification uses, including whether the implementation uses pure or pre-hash signing where that distinction matters. - Track SLH-DSA rows separately because it is stateless hash-based, has SHA2 and SHAKE parameter-set families, and has implementation requirements that differ from ML-DSA. - Keep classical RSA, ECDSA, and ECDH rows visible as legacy or coexistence inventory items, but do not describe them as replaced unless the actual design and evidence prove that change. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports tracker rows that classify ML-KEM as the post-quantum key-encapsulation mechanism for shared-secret establishment. - [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports tracker rows that classify ML-DSA as a post-quantum digital signature algorithm rather than a key-establishment mechanism. - [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports tracker rows that classify SLH-DSA as a stateless hash-based digital signature algorithm. *Recommended next step* *Placement: after practical guidance* ## Operationalize the FIPS PQC tracker Use the tracker to assign ML-KEM, ML-DSA, SLH-DSA, CAVP, and CMVP evidence work without publishing unsupported readiness or validation claims. - [Open Assessment Autopilot for FIPS PQC migration](/solutions/assessment.md): Convert algorithm inventory rows into accountable evidence requests, owners, and validation review tasks. - [Research FIPS PQC source questions](/solutions/research-copilot.md): Use cited FIPS, CAVP, and CMVP material to resolve parameter-set, boundary, and certificate-evidence questions. - [Talk through post-quantum evidence planning](/contact.md): Review ML-KEM, ML-DSA, SLH-DSA, CAVP, and CMVP evidence gaps before making product or procurement claims. ## Minimum fields for a useful post-quantum migration tracker A migration tracker is useful when every row can be checked by an engineer and an evidence reviewer. The row should show what is in scope, which FIPS publication controls the algorithm choice, which parameter set is selected or still undecided, what CAVP or ACVP evidence is expected, and whether the cryptographic module boundary changes. Avoid current-status labels such as "validated", "complete", "approved", or "available" unless the row also names the certificate, validation entry, module version, operational environment, and source date that support the label. When evidence is missing, use neutral working states such as "inventory only", "design decision needed", "implementation evidence needed", or "certificate evidence needed". - Inventory fields: product or service, use case, protocol or API, implementation owner, supplier, cryptographic module boundary, operational environment, and release version. - Algorithm fields: classical primitive in use, proposed PQC primitive, FIPS publication, parameter set, pure or pre-hash signature mode where relevant, and approved RBG or hash dependency where relevant. - Evidence fields: design record, test plan, CAVP certificate or ACVP test evidence, CMVP certificate impact, approved-mode statement, security policy update, and procurement claim text. - Review fields: open question, blocking evidence, customer commitment, exception owner, and the source link used for the row. - Example row: "VPN gateway | key establishment | ML-KEM | FIPS 203 | ML-KEM-768 | inventory only | CAVP evidence needed | CMVP boundary review needed". Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports tracking ML-KEM parameter-set choices as ML-KEM-512, ML-KEM-768, or ML-KEM-1024. - [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports tracking ML-DSA as a signature algorithm with approved parameter sets and private-key protection obligations. - [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports tracking SLH-DSA parameter choices and implementation dependencies, including approved random-bit generation for key generation. ## Separate algorithm conformance from module validation The tracker should keep CAVP and CMVP evidence in different columns. CAVP evidence concerns a validated algorithm implementation, including the algorithm implementation name, version, and tested operational environment. CMVP evidence concerns a validated cryptographic module and its tested operational environment. One does not automatically prove the other. For FIPS 140-3 validation work, record whether an algorithm implementation was modified when integrated into the module and whether the CAVP operational environment is identical to, or fully included in, the module testing environment. This avoids overstating a standalone algorithm certificate as proof that the shipped module, product, or service is validated. - Use one column for CAVP or ACVP evidence: algorithm, implementation name, implementation version, operational environment, certificate or test evidence, and parameter sets. - Use a separate column for CMVP impact: module name, module version, certificate number if available, cryptographic boundary, approved mode, security policy impact, and operational environment. - For supplier evidence, request the exact module and algorithm certificate details instead of accepting broad phrases such as "uses FIPS algorithms" or "PQC compliant". - For customer-facing claims, tie every claim to a specific row and avoid product-wide validation language unless the CMVP certificate and boundary support it. Sources for this answer: - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?orderBy=ValidationNumber&searchMode=validation&ref=sorena.io) - Use the public CAVP search to check algorithm-certificate evidence before recording a certificate-backed claim. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Use the public CMVP search to check cryptographic-module certificate evidence and module status before making module validation claims. - [NIST FIPS 140-3 CMVP implementation guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Supports separating CAVP algorithm implementation evidence from CMVP module validation evidence and checking operational-environment fit. ## Parameter-set decisions belong in the tracker Do not leave parameter-set selection hidden in code or vendor notes. FIPS 203 names ML-KEM-512, ML-KEM-768, and ML-KEM-1024. FIPS 204 names ML-DSA parameter sets. FIPS 205 names SLH-DSA SHA2 and SHAKE parameter-set families. The tracker should show the selected set, the reason for the choice, and where the choice is implemented. A parameter-set row should also record dependent implementation choices. For ML-KEM, record encapsulation, decapsulation, and key-generation coverage. For ML-DSA, record signature generation, verification, key generation, context-string handling, and pure or pre-hash use. For SLH-DSA, record SHA2 or SHAKE family, pure or pre-hash use, approved hash or XOF use for pre-hash signatures, and random-bit-generation evidence for key generation. - ML-KEM fields: parameter set, encapsulation API, decapsulation API, key-generation location, implicit-rejection handling evidence, and protocol integration point. - ML-DSA fields: parameter set, signature-generation path, verification path, context-string policy, deterministic or hedged implementation where documented, and key-use separation. - SLH-DSA fields: SHA2 or SHAKE parameter set, pure or pre-hash mode, approved hash or XOF evidence for pre-hash use, RBG evidence for key generation, and sensitive intermediate-data handling. - Change-control fields: implementation version, tested operational environment, supplier library version, module boundary, and whether a changed parameter set forces new CAVP or CMVP evidence. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports recording the selected ML-KEM parameter set rather than using a generic PQC label. - [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports recording ML-DSA as a signature algorithm with parameter-set and private-key-use decisions. - [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports recording SLH-DSA SHA2/SHAKE parameter-family choices and pure versus pre-hash signature handling. ## Evidence checks for implementation and validation planning Use this section as a row review before a migration entry becomes a public claim, procurement answer, or release gate. The question is not whether the row sounds complete; it is whether the row identifies the exact implementation, parameter set, operational environment, boundary, and test evidence. CMVP implementation guidance includes cryptographic algorithm self-test requirements for post-quantum algorithms. For module validation planning, tracker rows should identify whether ML-KEM, ML-DSA, or SLH-DSA functions are implemented in approved mode and what self-test or known-answer-test evidence is expected. Keep these as planning and evidence fields, not as proof of validation until the relevant certificate or validation record exists. - ML-KEM evidence check: key generation, encapsulation, decapsulation, parameter set, implicit-rejection coverage, and shared-secret integration are all named. - ML-DSA evidence check: key generation, signature generation, signature verification, context handling, parameter set, and pre-hash or pure path are all named. - SLH-DSA evidence check: key generation, signature generation, signature verification, SHA2 or SHAKE parameter family, pure or pre-hash path, and approved hash or XOF dependency are all named. - Validation evidence check: CAVP or ACVP evidence is linked separately from CMVP module evidence, and neither is used to make unsupported product-wide claims. Sources for this answer: - [NIST FIPS 140-3 CMVP implementation guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Supports adding self-test planning fields for ML-KEM, ML-DSA, and SLH-DSA without implying a certificate already exists. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?orderBy=ValidationNumber&searchMode=validation&ref=sorena.io) - Supports checking certificate evidence for algorithm implementations before tracker rows become customer-facing validation claims. ## Do not turn the tracker into unsupported timeline content This page should not invent migration deadlines, availability dates, certificate status, or customer readiness. FIPS 203, FIPS 204, and FIPS 205 provide algorithm standards; CAVP and CMVP provide validation evidence paths. The tracker can show what evidence is needed and what has been verified, but each status must come from a visible source or internal evidence record. When a team needs dates, keep them in evidence-owned records such as release plans, procurement commitments, validation lab schedules, certificate listings, or customer contracts. If those records are not public source material, do not publish the dates here. - Use neutral row states such as inventory only, design decision needed, implementation evidence needed, CAVP evidence needed, CMVP impact review needed, or customer-claim review needed. - Avoid unsupported claims such as migrated, FIPS validated, quantum safe, CAVP certified, CMVP certified, production ready, or compliant without row-level evidence. - Keep public source URLs external, https, and source-specific; do not cite local source reference files, internal spreadsheets, or private validation notes. - Review tracker rows after algorithm implementation changes, parameter-set changes, operational-environment changes, cryptographic-boundary changes, supplier changes, or claim-language changes. Sources for this answer: - [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports the ML-KEM algorithm classification used by tracker rows, not an unsupported product migration date. - [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports the ML-DSA signature classification used by tracker rows, not an unsupported product readiness status. - [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports the SLH-DSA signature classification used by tracker rows, not an unsupported product validation claim. ## Primary sources - [NIST FIPS 203 ML-KEM standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary source for ML-KEM scope, shared-secret establishment, and ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter-set tracking. - Quote: "This standard specifies three parameter sets for ML-KEM." - [NIST FIPS 204 ML-DSA standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Primary source for ML-DSA signature tracking, approved parameter-set decisions, private-key use, and pure or pre-hash signature evidence. - Quote: "This standard specifies ML-DSA" - [NIST FIPS 205 SLH-DSA standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Primary source for SLH-DSA tracking, stateless hash-based signature use, SHA2/SHAKE parameter families, and pure or pre-hash handling. - Quote: "This standard specifies the stateless hash-based digital signature algorithm" - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?orderBy=ValidationNumber&searchMode=validation&ref=sorena.io) - Public source for checking algorithm-validation certificate evidence before treating a tracker row as certificate-backed. - Quote: "validation-search" - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public source for checking cryptographic-module validation evidence and module boundaries before making CMVP-backed claims. - Quote: "Validated Modules" - [NIST FIPS 140-3 CMVP implementation guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements?ref=sorena.io) - Program guidance source for distinguishing CAVP algorithm testing from CMVP module validation and planning post-quantum algorithm self-test evidence. - Quote: "Cryptographic Algorithm Self-Test Requirements" ## 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 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. - [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-tracker