Post-quantum migration for FIPS cryptography

List every place the product, service, or module uses public-key cryptography, including dependencies supplied by operating systems, cloud services, hardware, certificate authorities, update systems, build pipelines, and vendors. Separate key establishment from digital signatures before selecting an algorithm. FIPS 203 specifies ML-KEM for key encapsulation; FIPS 204 specifies ML-DSA and FIPS 205 specifies SLH-DSA for digital signatures.

For each use case, the system owner should record the protocol, algorithm, parameter set, public and private key location, key lifetime, protected data, required confidentiality period, signing or handshake volume, message and signature size limits, certificate dependency, failure behavior, and FIPS 140-3 module boundary. The implementation owner records feasible replacements and test results; the assurance owner records CAVP, CMVP, and claim evidence. Also record where captured ciphertext could remain valuable to an attacker after a later cryptographic break; those long-lived confidentiality uses may need earlier treatment.

Name the exact primitive, parameter set, and operation. For key establishment, document whether the candidate is ML-KEM-512, ML-KEM-768, or ML-KEM-1024 and how the consuming protocol handles encapsulation, decapsulation failure, authentication, and key derivation. For signatures, compare ML-DSA and SLH-DSA using public-key size, signature size, signing and verification cost, implementation maturity, side-channel controls, relying-party support, and the lifetime of the signing key and signed artifact.

Do not call a product "post-quantum compliant" merely because it references a new FIPS publication. State the narrower fact supported by evidence: the design selected a named FIPS-standardized primitive; a named implementation has a matching CAVP record; or a named cryptographic module and service are covered by a current CMVP certificate and Security Policy.

FIPS 203, FIPS 204, and FIPS 205 became final on August 13, 2024. They standardize cryptographic primitives, not every protocol, certificate format, hardware interface, or product integration needed to deploy them. A migration can therefore be ready at the algorithm layer while blocked at the protocol, public-key infrastructure, hardware, supplier, or validation layer. Build crypto agility into the migration by keeping algorithm choices discoverable and making protocol, software, hardware, supplier, test, and recovery dependencies changeable under controlled procedures.

NIST IR 8547 is still an Initial Public Draft, so its proposed transition dates are planning input rather than final requirements. Use the draft to identify quantum-vulnerable standards and sequence work, but base a binding deadline on the final publication, a controlling agency rule, a contract, or another authority that actually applies to the system. A legacy interoperability need, unavailable protocol profile, or missing validation path can justify a documented pause or coexistence period, but it does not convert a draft date into a requirement or support a readiness claim.

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 treats ML-KEM as a key-encapsulation mechanism for sensitive security parameter establishment. 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.

Use this checklist to review the evidence for each post-quantum migration workstream. Each item should be traceable to a product boundary, release, protocol, module, or customer-facing claim.

The evidence must be specific enough for engineering and procurement to act on. It should show what changed, what stayed classical, what depends on external libraries or protocols, what fallback remains, and which validation evidence exists versus which evidence is planned.

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

Repeat this review after a library change, firmware release, protocol update, lab submission, certificate update, parameter-set change, certificate-profile change, customer commitment, supplier change, or NIST guidance update. Record one outcome: approved for the stated boundary, approved only as a prototype or design decision, blocked pending named evidence, retained temporarily under an owned exception, or retired.