Post-Quantum Migration Checklist

Migrating to post-quantum cryptography is not a single action. It is a multi-year process that touches every system using asymmetric cryptography: TLS, SSH, VPNs, code signing, certificates, authentication tokens, and encrypted storage. Most organizations underestimate the scope because they do not know how much cryptography they actually use.

This checklist synthesizes NIST NCCoE migration work, government policy and implementation experience. It is not a universal deadline. Scope, sequence and dates depend on cryptographic function, data lifetime, dependencies and applicable requirements.

Use the free PQC Migration Plan Template to assign owners, targets, tests, rollback and evidence. Use the PQC Vendor Questionnaire when a dependency is controlled by a supplier.

Phase 0: Establish ownership and decision rights

Appoint a migration lead responsible for portfolio coordination
Assign a technical system owner and business risk owner to each item
Define who approves algorithms, hybrid constructions and exceptions
Define evidence required for pilot, validation and production
Define who can trigger rollback and accept residual risk
Create an escalation path for vendor and standards dependencies

Status should be capability-specific: discovery, assessed, blocked, pilot, validated, rollout or complete. Do not mark an application complete because one TLS endpoint negotiates ML-KEM.

Phase 1: Discovery and inventory (start immediately)

Before you can migrate anything, you need to know what you have. This is the step most organizations skip and later regret.

Cryptographic inventory checklist

TLS certificates: catalog every certificate (public-facing and internal), noting the signature algorithm (RSA, ECDSA), key size, expiry date, and issuing CA
Key exchange: identify which TLS versions and cipher suites are in use across all endpoints (grep for ECDHE, DHE, RSA key exchange in configs and handshake logs)
SSH: inventory transport key-exchange methods separately from host and user authentication keys; record client/server versions and negotiated methods
VPN configurations: identify the encryption and key exchange algorithms in every VPN tunnel (IPsec IKE, WireGuard, OpenVPN)
Code signing: list every code signing key and certificate (software releases, container images, firmware, drivers)
Authentication tokens: identify JWT/JWS signing algorithms (RS256, ES256, EdDSA)
Stored encrypted data: catalog data encrypted at rest with asymmetric keys (especially PGP-encrypted archives, encrypted backups with RSA-wrapped keys)
Third-party dependencies: identify which vendors and services handle cryptographic operations on your behalf (CAs, CDNs, identity providers, HSMs)
Hardware security modules: inventory HSM models and firmware versions, noting which support PQC algorithms

Tools for automated discovery

NIST NCCoE’s cryptographic discovery guidance (free)
Keyfactor Command (commercial, certificate and key discovery)
Evertrust CPM (commercial, cryptographic posture management)
Venafi TLS Protect (commercial, machine identity management)
Custom: scan certificate transparency logs for your domains, grep infrastructure configs for algorithm identifiers

What you are looking for

At the end of Phase 1, you should have a spreadsheet (or database) with every cryptographic asset, its algorithm, its key size, its expiry or rotation schedule, and who owns it. This is your migration scope.

Phase 2: Risk assessment and prioritization

Not everything needs to migrate at the same time. Prioritize based on two factors:

1. Data sensitivity lifetime: How long does the protected data need to remain confidential?

Data sensitive for 10+ years: migrate first (state secrets, trade secrets, medical records)
Data sensitive for 5-10 years: migrate second (financial data, legal documents)
Data sensitive for days-months: migrate last (session tokens, ephemeral communications)

2. Exposure to harvest attacks: Is the encrypted traffic traversing networks where adversaries could intercept and store it?

Public internet traffic: highest exposure
Internal network traffic: moderate (insider threat, supply chain compromise)
Air-gapped systems: lowest exposure (but still vulnerable to physical interception)

Priority matrix

	High sensitivity lifetime	Low sensitivity lifetime
High harvest exposure (public internet)	Highest planning and pilot priority	Prioritize by service lifecycle
Low harvest exposure (internal only)	Prioritize after exposed long-lived data unless policy requires earlier action	Schedule with dependencies and refresh cycles

What to prioritize first (typically)

TLS key establishment on public-facing services carrying long-lived sensitive data
Long-lived signing keys (root CAs, code signing, firmware keys)
VPN tunnels carrying sensitive data across public networks
SSH key exchange and authentication on internet-facing systems
Internal TLS and authentication (lower priority, but still needed)

Phase 3: Pilot hybrid deployment

Do not go directly from classical to pure PQC. The transition path is hybrid: classical + PQC together, both verified.

TLS key establishment pilot

Enable hybrid X25519MLKEM768 on your reverse proxy or load balancer
Verify that clients support it (Chrome and Edge do by default since 2024-2025)
Monitor for any compatibility issues (some firewalls/middleboxes may reject the larger ClientHello)
Measure the bandwidth impact (roughly +1.1 KB per handshake)

This is often an accessible first pilot, but only with a documented compatible endpoint and client path. It protects that session’s key establishment. It does not migrate certificate signatures, identity, storage or application signing.

SSH key-establishment pilot

RFC 10042, published as an Informational RFC in August 2026, defines three hybrid ML-KEM plus ECDH methods for SSH transport key exchange. Treat this as a separate capability from SSH host and user authentication.

Record the released client and server versions under test
Record the exact RFC 10042 method offered and negotiated
Test classical fallback and the behavior when hybrid KEX is required
Include bastions, SFTP automation, CI/CD and embedded SSH libraries
Keep host-key and user-key signature migration as separate rows

Use Post-Quantum SSH: What RFC 10042 Standardizes for the method names, verified implementation evidence and compatibility checks. A negotiated hybrid KEX protects session-key establishment; it does not make SSH authentication post-quantum.

Where to enable it

Platform	How
Cloudflare	Already enabled by default (server-side, no action needed)
Nginx	Requires OpenSSL 3.5+ or OQS provider, configure groups directive
AWS ALB	Check current PQ support in KMS/TLS policies
Caddy	Supports via crypto/tls package updates
HAProxy	Requires OpenSSL 3.5+ backend

What to test

TLS handshake completes successfully with hybrid key exchange
No increase in connection errors from clients or middleboxes
Latency impact is within acceptable bounds (<5ms additional typically)
Certificate chain validation still works (hybrid KE does not affect certificate signatures)

Phase 4: Certificate and signature migration (longer timeline)

This is harder than key exchange because it requires the entire trust chain (root CA through intermediate to leaf) to support PQC signatures. In 2026, this is still early:

Identify which CAs offer ML-DSA or hybrid certificates (experimental in 2026)
Plan for composite certificates (classical + PQC signature, per IETF LAMPS WG drafts)
Test ML-DSA certificate issuance from an internal CA (if you operate your own PKI)
Identify long-lived certificates (multi-year validity) that should be renewed with PQC before their next rotation

Timeline reality check

Public WebPKI ML-DSA certificates are not expected to be broadly available until 2027-2028. Internal PKI can move faster. Plan accordingly: deploy hybrid key exchange now (Phase 3), migrate certificates later (Phase 4), with long-lived signing keys as the bridge priority.

Phase 5: Signature and authentication migration

After TLS key exchange and certificates, migrate everything else that uses asymmetric cryptography:

SSH authentication: track standards and released implementation support for PQ host and user signatures separately from RFC 10042 key exchange
JWT signing: migrate from RS256/ES256 to ML-DSA-based algorithms (when libraries support them)
Code signing: issue new PQC signing keys for software and firmware releases
S/MIME: migrate email encryption certificates (requires CA support)
Git commit signing: migrate when tooling supports PQC algorithms
API authentication: rotate any RSA/ECDSA-based API keys to PQC equivalents

Dependency: HSM support

Many of these operations require HSM support for the new algorithms (especially code signing and CA operations). HSM vendors are adding PQC support in 2026-2027 firmware updates. Until your HSM supports ML-DSA or ML-KEM natively, software-based signing (OpenSSL 3.5+) is the interim solution.

Phase 6: Validation and compliance

Re-run the cryptographic inventory (Phase 1) and confirm all high-priority assets have migrated
Verify no classical-only cryptography remains on harvest-exposed paths
Document the migration for compliance (auditors will ask for this, especially in regulated industries)
Set up continuous monitoring for cryptographic drift (new services deployed with classical-only crypto)
Plan for pure-PQC cutover (removing the classical half of hybrid mode) once industry consensus forms (likely 2030+)

Capability-based timeline

Capability	Plan now	Pilot or migrate when supported	Completion driver
Key establishment	Inventory exposed connections, data lifetime and clients	Test documented hybrid groups and fallback	Applicable policy, risk and ecosystem support
Signatures	Inventory code, firmware, documents, tokens and certificates	Test ML-DSA with every verifier	Trust-chain and relying-party readiness
PKI	Map roots, intermediates, enrollment, revocation and automation	Use controlled private PKI tests	Standards, CA, HSM and client interoperability
KMS and HSM	Record protection level and operation	Pilot exact supported key types and workflows	Provider status and validation requirements
Long-lived devices	Map boot roots, update path, storage and bandwidth	Test dual trust anchors and recovery images	Product lifetime and update feasibility

FIPS 203, 204 and 205 are final standards. NIST IR 8547 remains listed as a draft transition publication. The June 2026 US Executive Order and OMB M-26-15 federal migration guide define phased requirements for covered federal systems, including prioritized key-establishment migration through December 31, 2030. These are not universal private-sector deadlines. CNSA 2.0 applies to national security systems and related product requirements. Record applicability per system.

Common mistakes

Starting with code signing instead of TLS key exchange. TLS hybrid key exchange is the easiest, fastest first win. It requires no CA changes, no certificate reissuance, and protects against harvest attacks immediately. Start there.

Skipping the inventory. Without knowing what cryptography you actually use, you will discover systems mid-migration that were missed. The inventory is tedious but prevents surprises.

Waiting for HSM support to do anything. HSMs are not needed for TLS key exchange migration. Software-based hybrid deployment works now. Do not let HSM timelines gate your entire migration.

Copying a headline deadline. Government, provider and internal dates apply to different systems and capabilities. Record source, scope and owner rather than assigning one date to every row.

FAQ

How long does a PQC migration take?

For a large organization: 2-5 years for complete migration. The first meaningful protection (hybrid TLS key exchange) can be deployed in weeks to months. Certificate and signature migration takes longer due to ecosystem dependencies.

What if I only have a small engineering team?

Start with Phase 1 (inventory, even a rough one) and Phase 3 (enable hybrid TLS key exchange on your main public-facing services). These two steps provide the highest protection-per-effort and can be done by a single engineer.

Do I need to migrate if I am not a government contractor?

Legal and contractual requirements depend on jurisdiction, sector and system. Long-lived sensitive data can justify inventory and planning without predicting a compliance deadline.

What is Meta’s migration approach?

Meta published a six-step, five-maturity-level framework in April 2026: automated + developer-reported cryptographic inventory, hybrid-first deployment, and phased migration. Their key insight: the inventory must combine automated scanning with developer self-reporting, because automated tools miss embedded cryptography in application code.

Should I migrate symmetric encryption (AES) too?

No. AES-256 remains secure against quantum computers (Grover’s algorithm reduces it to 128-bit effective security, which is still sufficient). Only asymmetric cryptography (RSA, ECC, DH) needs replacement.

Sources

NIST NCCoE: Migration to Post-Quantum Cryptography - project guidance and tools
CISA: Quantum-Readiness Migration to Post-Quantum Cryptography - joint CISA/NSA/NIST factsheet
Meta: Post-Quantum Cryptography Migration Framework - vendor case study and enterprise playbook
RFC 10042: PQ/T Hybrid Key Exchange with ML-KEM for SSH - Informational RFC for hybrid ML-KEM SSH transport key exchange
NSA CNSA 2.0 FAQ - requirements and timelines for national security systems
EO 14412: Securing the Nation Against Advanced Cryptographic Attacks - specified US federal migration requirements
Cloudflare: Post-Quantum Executive Order analysis - third-party analysis of practical implications