We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALFIPS-approved cryptographic algorithm requirements

Post-quantum migration FIPS evidence tracker

Create one row with a named owner 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.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
7 sections7 primary sources
Overview

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.

Section 1

Tracker rows should start with the cryptographic role, not a migration status

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.

  • 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.
Recommended next step

Assign and review FIPS PQC tracker rows

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, 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.

  • 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, public CAVP validation entry, linked internal ACVP/ACVTS test records where relevant, CMVP certificate impact, approved-mode statement, Security Policy update, and procurement claim text.
  • Review fields: open question, blocking evidence, customer commitment, exception owner, exception expiry or review trigger, and the source link used for the row.
  • State fields: current state, accountable owner, next action, exit evidence, review date, and the decision authority that may accept an exception.
  • Example row: "VPN gateway | key establishment | ML-KEM | FIPS 203 | ML-KEM-768 | inventory only | CAVP evidence needed | CMVP boundary review needed".
Section 3

Use evidence gates instead of percentage-complete scores

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.

  • Inventory exit: the owner, boundary, current primitive, protocol location, data lifetime, and dependent systems are recorded.
  • Design exit: the selected FIPS standard, algorithm, parameter set, hybrid or fallback behavior, and failure handling are approved in the architecture record.
  • Implementation exit: versioned tests cover key generation, encapsulation or signing, verification or decapsulation, malformed inputs, and protocol interoperability.
  • Evidence exit: CAVP and CMVP records are linked at their proper boundaries, or the row states that certificate evidence is unavailable and limits the claim accordingly.
  • Release exit: approved wording, configuration instructions, exception decision, monitoring owner, and re-review triggers match the shipped version.
Section 4

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 algorithm-evidence column: public CAVP validation entry, algorithm, implementation name and version, operational environment, parameter sets, and any linked internal ACVP/ACVTS test records.
  • 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.
Section 5

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.
Section 6

Evidence checks for implementation and validation planning

Review each row before using it in a public claim, procurement answer, or release decision. Identify the exact implementation, parameter set, operational environment, boundary, and test evidence so reviewers can check the stated migration status.

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: the public CAVP entry and any internal ACVP/ACVTS test records are linked separately from CMVP module evidence, and none is used to make unsupported product-wide claims.
Section 7

Record the source for each migration date

Record migration deadlines, availability dates, certificate status, and customer readiness only when the supporting source or evidence is identified. 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. Keep confidential dates in access-controlled planning records and identify who can approve their disclosure.

  • 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 private reference labels, private 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.
Primary sources

References and citations

NIST FIPS 203 ML-KEM standard
doi.org6 citations
Referenced sections
  • Primary source for ML-KEM scope, shared-secret establishment, and ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter-set tracking.
  • Supports tracker rows that classify ML-KEM as the post-quantum key-encapsulation mechanism for shared-secret establishment.
  • Supports tracking ML-KEM parameter-set choices as ML-KEM-512, ML-KEM-768, or ML-KEM-1024.
Show 3 more
  • Supports implementation-gate coverage for ML-KEM key generation, encapsulation, decapsulation, parameter selection, and failure behavior.
  • Supports recording the selected ML-KEM parameter set rather than using a generic PQC label.
  • Supports the ML-KEM algorithm classification used by tracker rows, not an unsupported product migration date.
"This standard specifies three parameter sets for ML-KEM."
More quoted passages
"This standard specifies a key-encapsulation mechanism called ML-KEM."
"ML-KEM-512, ML-KEM-768, and ML-KEM-1024"
"Module-Lattice-Based Key-Encapsulation Mechanism Standard"
NIST FIPS 204 ML-DSA standard
doi.org5 citations
Referenced sections
  • Primary source for ML-DSA signature tracking, approved parameter-set decisions, private-key use, and pure or pre-hash signature evidence.
  • Supports tracker rows that classify ML-DSA as a post-quantum digital signature algorithm rather than a key-establishment mechanism.
  • Supports tracking ML-DSA as a signature algorithm with approved parameter sets and private-key protection obligations.
Show 2 more
  • Supports recording ML-DSA as a signature algorithm with parameter-set and private-key-use decisions.
  • Supports the ML-DSA signature classification used by tracker rows, not an unsupported product readiness status.
"This standard specifies ML-DSA"
More quoted passages
"approved for use"
"digital signatures"
"Module-Lattice-Based Digital Signature Standard"
NIST FIPS 205 SLH-DSA standard
doi.org5 citations
Referenced sections
  • Primary source for SLH-DSA tracking, stateless hash-based signature use, SHA2/SHAKE parameter families, and pure or pre-hash handling.
  • Supports tracker rows that classify SLH-DSA as a stateless hash-based digital signature algorithm.
  • Supports tracking SLH-DSA parameter choices and implementation dependencies, including approved random-bit generation for key generation.
Show 2 more
  • Supports recording SLH-DSA SHA2/SHAKE parameter-family choices and pure versus pre-hash signature handling.
  • Supports the SLH-DSA signature classification used by tracker rows, not an unsupported product validation claim.
"This standard specifies the stateless hash-based digital signature algorithm"
More quoted passages
"stateless hash-based digital signature algorithm"
"approved random bit generator"
"pure and pre-hash"
"Stateless Hash-Based Digital Signature Standard"
NIST CAVP validation search
csrc.nist.gov3 citations
Referenced sections
  • Public source for checking algorithm-validation certificate evidence before treating a tracker row as certificate-backed.
  • Use the public CAVP search to check algorithm-certificate evidence before recording a certificate-backed claim.
  • Supports checking certificate evidence for algorithm implementations before tracker rows become customer-facing validation claims.
"Cryptographic Algorithm Validation Program"
NIST FIPS 140-3 CMVP implementation guidance
csrc.nist.gov3 citations
Referenced sections
  • Program guidance source for distinguishing CAVP algorithm testing from CMVP module validation and planning post-quantum algorithm self-test evidence.
  • Supports separating CAVP algorithm implementation evidence from CMVP module validation evidence and checking operational-environment fit.
  • Supports adding self-test planning fields for ML-KEM, ML-DSA, and SLH-DSA without implying a certificate already exists.
"Cryptographic Algorithm Self-Test Requirements"
More quoted passages
"CAVP"
NIST CMVP validated modules search
csrc.nist.gov2 citations
Referenced sections
  • Public source for checking cryptographic-module validation evidence and module boundaries before making CMVP-backed claims.
  • Use the public CMVP search to check cryptographic-module certificate evidence and module status before making module validation claims.
"Validated Modules"
CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov
Referenced sections
  • Supports separating algorithm evidence, module boundaries, tested operational environments, self-tests, approved services, and Security Policy evidence into distinct review gates.
"The validation certificate serves as a benchmark"

Related guides

AES FIPS 197 requirements and evidence

AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.

CAVP Algorithm Validation and ACVP Testing

How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.

CAVP Validation Evidence Workflow for FIPS Algorithms

Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, environments, and CMVP handoff records.

FIPS 180-4 and FIPS 202 secure hash guidance

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

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

Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP evidence.

Show all related guides (25)

FIPS approved algorithm selector workflow

A cited 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

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

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

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

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

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

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-approved cryptographic algorithms FAQ

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.

ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5

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

An official source 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

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

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

Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.

FIPS 203, 204, and 205 Post-Quantum Algorithms

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

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 validation certificates for cryptographic algorithms

How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.

How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval

Identify SHA-1 and SHA-2 in FIPS 180-4 and SHA-3 and SHAKE in FIPS 202, then check current-use status and CAVP/CMVP evidence separately.

How FIPS 186-5 Signature Algorithms Fit FIPS Approval

Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.

What does FIPS 197 AES mean for FIPS-approved algorithms?

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.