Create one evidence-owned row for every key-establishment or signature use affected by ML-KEM, ML-DSA, or SLH-DSA, then close it only when the design, implementation, protocol, and validation evidence agree.
Based on NIST FIPS 203, FIPS 204, FIPS 205, CAVP, and CMVP source material.
Structured answer sets in this page tree.
Cited legal and guidance references.
Create one tracker row for every public-key use that may need post-quantum review. Name the key-establishment or signature role, FIPS source, parameter set, implementation and module boundaries, protocol dependency, CAVP evidence, CMVP impact, owner, and exit record. FIPS 203, FIPS 204, and FIPS 205 became effective on August 13, 2024 for the federal systems within each standard's applicability clause; they are also available for private and commercial adoption. They standardize ML-KEM, ML-DSA, and SLH-DSA, but do not certify a product or set a universal migration deadline. Do not mark a product ready, validated, or migrated unless the shipped version, certificate, Security Policy, operational environment, and enabled service support that exact claim.
The system owner and implementation owner should 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. The assurance owner should separately record the public and internal evidence that supports the row.
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.
Use the tracker to assign ML-KEM, ML-DSA, SLH-DSA, CAVP, and CMVP evidence work without publishing unsupported readiness or validation claims.
Convert algorithm inventory rows into accountable evidence requests, owners, and validation review tasks.
Use cited FIPS, CAVP, and CMVP material to resolve parameter-set, boundary, and certificate-evidence questions.
Review ML-KEM, ML-DSA, SLH-DSA, CAVP, and CMVP evidence gaps before making product or procurement claims.
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, whether a public CAVP validation entry or internal ACVP/ACVTS test record 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". Assign an owner and exit evidence to every state so the tracker shows what must happen next.
A percentage can hide whether a row is only inventoried or is ready for release with matching validation evidence. Use evidence gates that describe the decision reached and the artifact that supports it.
A practical sequence is inventory, design decision, implementation verification, algorithm-evidence review, module-impact review, interoperability review, claim approval, and release monitoring. A row closes as retired when the use disappears; pauses as blocked when the protocol, supplier, laboratory, or certificate path is unavailable; proceeds with a limited internal claim when evidence covers only the design or algorithm implementation; or proceeds to a module claim only when the CMVP boundary and approved service match. An authorized exception needs an owner, scope, reason, compensating controls where applicable, expiry or review trigger, and the authority that accepted it.
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.
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.
This section is 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.
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 non-public 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.
"The validation certificate serves as a benchmark"
"Cryptographic Algorithm Validation Program"
"Validated Modules"
"Cryptographic Algorithm Self-Test Requirements"
"Module-Lattice-Based Key-Encapsulation Mechanism Standard"
"Module-Lattice-Based Digital Signature Standard"
"Stateless Hash-Based Digital Signature Standard"