Post-Quantum Migration Checklist: The Practical Steps for Engineering Teams
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 provides the concrete steps in the right order. It synthesizes guidance from NIST’s NCCoE migration project, CISA’s Quantum-Readiness recommendations, Meta’s published migration playbook (April 2026), and NSA’s CNSA 2.0 timelines. Adapt the pace to your risk exposure, but do not change the order.
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 keys: catalog all SSH key types across your infrastructure (ssh-rsa, ssh-ed25519, ecdsa-sha2)
- 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) | Migrate immediately | Migrate within 2 years |
| Low harvest exposure (internal only) | Migrate within 1 year | Migrate within 3 years |
What to prioritize first (typically)
- TLS key exchange on public-facing services (harvest-now target, fix with hybrid ML-KEM)
- Long-lived signing keys (root CAs, code signing, firmware keys)
- VPN tunnels carrying sensitive data across public networks
- SSH keys 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 exchange (the easiest first win)
- 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 the single fastest PQC control you can deploy. It directly protects against harvest-now-decrypt-later for new TLS sessions.
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 keys: generate ML-DSA keys (when OpenSSH supports them, experimental)
- 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+)
Key deadlines to track
| Deadline | Source | What it means |
|---|---|---|
| January 2027 | NSA CNSA 2.0 | PQC required in new defense system procurement |
| 2029 | Google (internal) | Google’s own migration complete |
| 2030 | NSA CNSA 2.0 | PQC required for all NSS software/firmware signing and networking |
| 2031 | NSA CNSA 2.0 | PQC required for OS, browsers, cloud, and legacy systems |
| 2033 | NSA CNSA 2.0 | PQC required for remaining categories |
| 2035 | NSM-10 | Full federal government migration complete |
These are US government deadlines. The European Union (under NIS2 and the Cyber Resilience Act) is developing equivalent timelines. Commercial organizations without regulatory mandate should use the 2029-2030 window as an informal target.
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.
Treating this as a 2030 problem. The NSA’s 2027 procurement gate means defense suppliers need PQC capability next year. Google’s 2029 target means the broader ecosystem will expect it by then. The planning window is now.
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?
Not legally required (in 2026), but strongly recommended if you handle data that will remain sensitive for 5+ years. Compliance frameworks will likely require it within 2-3 years. Starting now avoids a rush.
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.