NIST Post-Quantum
Compliance Checklist

A NIST post-quantum compliance checklist is a structured, step-by-step sequence of actions an organization completes to reach cryptographic readiness against quantum attack — inventory, risk assessment, architecture preparation, algorithm selection, testing, and deployment — mapped to the NIST standards. It exists because "migrate to post-quantum" is too large to act on directly: without a checklist, organizations miss hidden cryptographic dependencies, misjudge which data is most urgent, and discover protocol-size problems only in production. This page turns the migration into a series of verifiable boxes to check.

The finalized NIST standards this checklist references are FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) for stateless hash-based signatures. FN-DSA/FALCON (FIPS 206) remains a draft and is not yet finalized. These are external standards you conform to and verify against — H33 does not own or prove them. Where a durable record of migration is needed, that portable evidence is produced by H33-74; whether a system stays compliant over time is recorded and monitored by HATS; and the independent verdict that an attestation is valid — requiring ML-DSA, FN-DSA/FALCON, and SLH-DSA to all verify, a strict 3-of-3 gate — is rendered by Verification.

Cryptographic Inventory

• Catalog all public-key algorithms in use. Document every RSA, ECDSA, ECDH, Ed25519, and DH instance across all systems, libraries, and services. Include TLS configs, certificate chains, API auth, VPNs, email encryption, code signing, and document signing.
• Identify key sizes and security levels. Map each algorithm to its effective security level. RSA-2048: ~112-bit classical. ECDSA-P256: 128-bit classical. Neither provides meaningful post-quantum security.
• Classify data sensitivity and longevity. Healthcare records: 50+ years. Financial records: 7-25 years. Auth tokens: minutes. Prioritize migration based on longest-lived data.
• Map third-party dependencies. Identify cryptographic operations by third-party libraries or cloud services requiring vendor coordination.

Risk Assessment

• Evaluate harvest-now-decrypt-later exposure. Calculate: (data confidentiality lifetime) - (years until quantum computers) = migration urgency.
• Assess regulatory requirements. Map post-quantum requirements from CNSA 2.0, HIPAA, PCI DSS, GDPR as applicable.
• Quantify migration complexity. Systems with crypto-agile abstractions migrate quickly. Hard-coded dependencies require significant refactoring.

Architecture Preparation

• Implement cryptographic abstraction layers. All operations through abstract interfaces, enabling algorithm swapping without code changes.
• Update key management systems. Handle larger post-quantum keys: ML-DSA-65 public keys are 1,952 bytes (vs. 32 bytes for Ed25519).
• Plan certificate infrastructure changes. Post-quantum certificates will be larger. Verify chain sizes work with existing infrastructure.
• Test protocol compatibility. Verify post-quantum key/signature sizes work with TLS 1.3, SSH, IPsec message size limits.

Algorithm Selection

• Key encapsulation: ML-KEM-768 (FIPS 203) for general use. ML-KEM-1024 for maximum security.
• Digital signatures: ML-DSA-65 (FIPS 204) for general use. Consider SLH-DSA (FIPS 205) as secondary family for defense-in-depth.
• Hash functions: SHA-3 or SHA-256. Both quantum-resistant. H33 uses SHA3-256 in its STARK proof system.
• Symmetric encryption: AES-256. No migration needed. 128-bit quantum security via Grover.

Implementation and Testing

• Validate against NIST KATs. Known Answer Tests are the gold standard for correctness. Run all published KAT vectors before deploying.
• Constant-time operations. All secret-dependent operations must be constant-time. Use timing analysis tools to verify.
• Memory zeroization. Private keys and intermediates securely erased after use. Rust: zeroize crate with ZeroizeOnDrop.
• Performance testing. Measure latency/throughput under production load. Ensure SLAs are met with post-quantum algorithms.
• Hybrid deployment testing. Test classical + post-quantum end-to-end. Verify combined scheme is secure if either layer fails.

Deployment

• Deploy hybrid mode first. Classical and post-quantum simultaneously for backward compatibility plus quantum resistance.
• Monitor NIST announcements. Algorithm recommendations may change as cryptanalysis advances.
• Document compliance status. Track which systems are migrated, algorithms in use, and pending migrations for audit purposes.
• Plan for future algorithm updates. NIST is evaluating additional algorithms (HQC). Ensure architecture accommodates additions.

H33 Compliance Mapping

Checklist Item	H33 Coverage
ML-DSA implementation	ML-DSA-65 in production attestation pipeline
ML-KEM implementation	Kyber-768 in key exchange layer
SLH-DSA implementation	SLH-DSA-SHA2-128f in three-key signer
Constant-time operations	All operations constant-time Rust
Memory zeroization	Zeroize + ZeroizeOnDrop on all key material
KAT validation	All implementations validated against NIST KATs
Crypto agility	Multi-engine architecture, algorithm swapping
Hybrid deployment	Three independent PQ families per attestation

When to Use This Checklist — and When Not To

• Use it now if you hold data that must stay confidential beyond the arrival of a cryptographically relevant quantum computer, if you are bound by CNSA 2.0 or a sector regulator, or if procurement and cyber-insurance questionnaires are already asking about quantum readiness.
• Prioritize by data longevity, not by system. Work the checklist first against your longest-lived secrets (healthcare, legal, government, IP), because those are most exposed to harvest-now-decrypt-later capture happening today.
• Do not skip the inventory step to jump straight to deployment. Most failed migrations are failures of discovery — a hard-coded RSA dependency found in production is far more expensive than one found on paper.
• This is not a substitute for AES-256. Symmetric encryption remains quantum-safe; the checklist targets public-key algorithms (RSA, ECDSA, ECDH, DH), not your bulk-data cipher.
• Treat "checked" as "verifiable," not "asserted." A box is genuinely checked only when the claim is backed by evidence — a KAT-validated implementation, a portable attestation, an independent verdict — not by a spreadsheet note.

Frequently Asked Questions

What is a NIST post-quantum compliance checklist?

It is a structured sequence of steps — cryptographic inventory, risk assessment, architecture preparation, algorithm selection, implementation and testing, and deployment — that an organization completes to reach readiness against quantum attack, mapped to the NIST post-quantum standards (FIPS 203, 204, 205, with FIPS 206 still in draft) and to CNSA 2.0 timelines.

Which NIST standards are finalized, and which is still a draft?

ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) are finalized. FN-DSA/FALCON (FIPS 206) remains a draft and is not yet finalized. AES-256 needs no migration and remains quantum-safe. You conform to and verify against these external standards; they are not owned or proven by any vendor.

Where do I start on the checklist?

Start with the cryptographic inventory, then prioritize migration by data confidentiality lifetime rather than by system convenience. Data that must remain secret for decades is most exposed to harvest-now-decrypt-later capture and should be migrated first.

How is "compliant" proven rather than just asserted?

A checklist item is genuinely complete only when its claim is backed by verifiable evidence. The durable, portable record that a post-quantum operation occurred is produced by H33-74; ongoing compliance state is recorded and monitored by HATS; and the independent verdict that an attestation is valid — requiring all three signature families to verify, a strict 3-of-3 gate — is rendered by Verification.