Post-quantum migration FIPS evidence tracker

Supports tracker rows that classify ML-KEM as the post-quantum key-encapsulation mechanism for shared-secret establishment.

Supports tracker rows that classify ML-DSA as a post-quantum digital signature algorithm rather than a key-establishment mechanism.

Supports tracker rows that classify SLH-DSA as a stateless hash-based digital signature algorithm.

Recommended next step

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.

Assessment workflow

Open Assessment Autopilot for FIPS PQC migration

Convert algorithm inventory rows into accountable evidence requests, owners, and validation review tasks.

Explore next step

Research workflow

Research FIPS PQC source questions

Use cited FIPS, CAVP, and CMVP material to resolve parameter-set, boundary, and certificate-evidence questions.

Explore next step

Talk to Sorena

Talk through post-quantum evidence planning

Review ML-KEM, ML-DSA, SLH-DSA, CAVP, and CMVP evidence gaps before making product or procurement claims.

Explore next step

Section 2

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

Supports tracking ML-KEM parameter-set choices as ML-KEM-512, ML-KEM-768, or ML-KEM-1024.

Supports tracking ML-DSA as a signature algorithm with approved parameter sets and private-key protection obligations.

Supports tracking SLH-DSA parameter choices and implementation dependencies, including approved random-bit generation for key generation.

Section 3

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

Use the public CAVP search to check algorithm-certificate evidence before recording a certificate-backed claim.

NIST CMVP validated modules search

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

Supports separating CAVP algorithm implementation evidence from CMVP module validation evidence and checking operational-environment fit.

Section 4

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

Supports recording the selected ML-KEM parameter set rather than using a generic PQC label.

Supports recording ML-DSA as a signature algorithm with parameter-set and private-key-use decisions.

Supports recording SLH-DSA SHA2/SHAKE parameter-family choices and pure versus pre-hash signature handling.

Section 5

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

Supports adding self-test planning fields for ML-KEM, ML-DSA, and SLH-DSA without implying a certificate already exists.

NIST CAVP validation search

Supports checking certificate evidence for algorithm implementations before tracker rows become customer-facing validation claims.

Section 6

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

Supports the ML-KEM algorithm classification used by tracker rows, not an unsupported product migration date.

Supports the ML-DSA signature classification used by tracker rows, not an unsupported product readiness status.