The Definitive Post-Quantum Cryptography (PQC) Migration Checklist

In late March 2026, Google drew a line in the sand: a 2029 timeline for a full Post-Quantum Cryptography (PQC) migration. More importantly, they signaled a massive shift in industry priorities. For years, the security world focused solely on post-quantum key exchanges (like ML-KEM) to stop Harvest-Now-Decrypt-Later (HNDL) attacks. Now, the mandate has expanded to post-quantum authentication (like ML-DSA).

A Cryptographically Relevant Quantum Computer (CRQC) capable of breaking RSA-2048 does not exist today. But your encryption’s expiration date is determined by the longevity of your sensitive data, not just the hardware timelines of quantum labs. If you are protecting data that must remain confidential for the next decade, Q-Day is already a threat.

You cannot flip a single switch to become quantum-safe. Cryptography is baked deeply into your operating systems, cloud providers, and dependencies. Here is the step-by-step, protocol-by-protocol PQC migration checklist to future-proof your TLS, OpenSSH, OpenSSL, and cloud environments. For a broader strategic overview, see The Quantum Horizon: Your PQC Migration Strategy Can’t Wait.

What to Remember

• Phased Approach: Break your migration into three steps: Inventory (CBOM), Key Exchange (urgent for HNDL), and Authentication (long-term).
• Key Exchange is Solved: Upgrading to OpenSSH 10.0, OpenSSL 3.5.0, and Go 1.24 enables hybrid ML-KEM key exchanges by default. Do this immediately.
• Authentication is Lagging: While ML-DSA (FIPS 204) is the preferred standard for digital signatures, support in browsers and tools like OpenSSH authentication is still developing due to massive signature sizes.
• TLS 1.3 is Mandatory: You cannot deploy PQC over TLS 1.2. If your infrastructure still relies on legacy TLS, quantum readiness is impossible.
• Hybrid is the Way: Never use PQC algorithms in isolation. Combine them with classical algorithms (like X25519) to maintain cryptographic agility.

Phase 1: Cryptographic Visibility and Inventory (CBOM)

You cannot upgrade what you cannot see. In a dynamic cloud environment, manual spreadsheets of certificates and algorithms are obsolete the moment they are saved.

Before touching a single configuration file, you must build a Cryptographic Bill of Materials (CBOM).

Step-by-Step Inventory:

1. Scan for Legacy TLS: Use dynamic external scanning to map all load balancers, API gateways, and web servers. Flag anything supporting TLS 1.0, 1.1, or 1.2.
2. Audit Cloud Key Management: Query AWS KMS, Azure Key Vault, and GCP Cloud KMS. Identify the key lengths and algorithms currently in use.
3. Locate Cryptographic Dependencies: Use Software Composition Analysis (SCA) to find applications relying on outdated crypto libraries (e.g., Python botocore running on legacy OpenSSL).
4. Identify High-Value Targets: Prioritize infrastructure handling data with long-term confidentiality requirements (healthcare, financial, national security).

Phase 2: The PQC Key Exchange Checklist (Urgent)

Your immediate goal is mitigating the Harvest-Now-Decrypt-Later (HNDL) threat. This means upgrading protocols to support the ML-KEM standard for key encapsulation.

1. TLS Protocol Migration

TLS 1.3 (released in 2018) is an absolute prerequisite for PQC. If you haven’t migrated from TLS 1.2, stop here and fix that technical debt first. For detailed TLS migration guidance, see Post-Quantum Cryptography TLS Migration.

The Goal: Enable the X25519MLKEM768 hybrid key exchange.

• Audit current usage: Check your ingress controllers and load balancers. According to recent data, while 84% of AWS API requests use TLS 1.3, internal company servers heavily lag, with 22% still relying on TLS 1.2.
• Update termination endpoints: Ensure your reverse proxies (Nginx, HAProxy, Envoy) are compiled against PQC-ready SSL libraries.
• Verify negotiation: Use tools to test if your endpoints successfully negotiate the hybrid cipher suite when proposed by a modern browser.

2. OpenSSH Migration

OpenSSH deployment handles two cryptographic phases: Key Exchange (setting up the secure tunnel) and Authentication (proving identity).

Step 1: Upgrade for Key Exchange

• Action: Upgrade your fleets to OpenSSH 10.0 (released April 2025).
• Why: Version 10.0 is the first release to default to the NIST-approved PQC hybrid key exchange: mlkem768x25519-sha256.
• Warning: OpenSSH 9.0 used sntrup761x25519-sha512. While quantum-resistant, it was an experimental algorithm not selected by NIST. You must move to v10.0 for compliance.

Command to verify KexAlgorithms on your server:

sshd -T | grep kexalgorithms
# Ensure mlkem768x25519-sha256 is present and prioritized.

Step 2: Wait on Authentication

• Tunnel Protection: As of mid-2026, OpenSSH does not support PQC algorithms (like ML-DSA) for user authentication.
• Tunnel Encryption: The authentication phase occurs inside the encrypted tunnel. If you upgrade to OpenSSH 10.0 for key exchange, an attacker recording the traffic today cannot decrypt it later, protecting your legacy RSA/Ed25519 authentication keys from HNDL.

3. OpenSSL & SDK Migration

If your applications interact with cloud APIs, their quantum readiness depends entirely on their underlying cryptographic libraries.

• OpenSSL: Upgrade to OpenSSL 3.5.0 (or later). Released in April 2025, this is the milestone version introducing full support for ML-DSA and SLH-DSA. Learn more about this release in OpenSSL 3.5 LTS Arrives: Fortifying the Future with PQC and QUIC.
• Golang: Upgrade to Go 1.24 or later, which supports X25519MLKEM768 by default in the standard crypto/tls library.
• AWS SDKs: If you use Python’s boto3/botocore, ensure the host OS is running OpenSSL 3.5.0+. Even though AWS Secrets Manager and KMS support PQC key exchanges, telemetry shows only 10% of client requests actually use it, purely due to outdated local SDKs and libraries.

Phase 3: The Digital Signature Checklist (Long-Term)

With key exchanges secured, the focus shifts to post-quantum authentication. NIST has approved ML-DSA (FIPS 204) as the primary algorithm and SLH-DSA (FIPS 205) as the stateless fallback.

Authentication migration is notoriously difficult because PQC signatures are massive. An ML-DSA-44 public key is 1,312 bytes (compared to Ed25519’s 32 bytes). This bloats traditional X.509 certificate chains, breaking systems with strict size limits.

Your Action Plan:

1. Target ML-DSA: Standardize on ML-DSA. SLH-DSA is a fallback with a mature math foundation but produces signatures that are painfully slow to generate (310ms vs ML-DSA’s 0.16ms). Do not wait for FN-DSA (FIPS 206) to be standardized.
2. Audit VPNs and Identity Providers: Check your vendor roadmaps. PQC DSA support in VPNs and IdPs is currently sparse. Make PQC support a mandatory requirement in your 2027 procurement cycles.
3. Prepare for Merkle Tree Certificates (MTCs): To bypass the size constraints of PQC signatures, the browser ecosystem is shifting from classic X.509 chains to MTCs. Ensure your PKI infrastructure and Certificate Authorities are tracking MTC adoption.

Cloud Provider Checklist: Know Your Environment

Cloud provider support for PQC is heavily fragmented. Do not assume your API calls are secure simply because they are in the cloud.

• Google Cloud (GCP): Currently leads the pack. All GCP API servers support ML-KEM hybrid key exchanges. Cloud KMS fully supports ML-DSA-65 and SLH-DSA-SHA2-128S for digital signing.
• AWS: Support is uneven. Only ~13% of AWS API servers currently support PQC key exchanges. Critical services like KMS and Secrets Manager support it, but generic endpoints (like iam.amazonaws.com) often do not. AWS KMS supports ML-DSA keys, but CloudHSM currently lacks support.
• Azure: Lags significantly. Finding Azure API servers (like management.azure.com) that support PQC key exchanges is currently difficult. Push your Microsoft reps for a firm rollout timeline.

Lessons Learned: The Importance of Cryptographic Agility

Why do we insist on “hybrid” cryptography (combining a classical algorithm like X25519 with a quantum one like ML-KEM)?

Look no further than the NIST PQC competition. An algorithm named SIKE made it to the final rounds and was widely considered secure. Based on its promise, early adopters (like Cloudflare and Google) deployed it experimentally.

Then, researchers broke SIKE using a traditional (non-quantum) computer and some advanced math.

The Lesson: The math behind PQC is relatively new and lacks the decades of scrutiny that RSA and Elliptic Curves have endured. By using hybrid cryptography, early adopters of SIKE were protected. Even though the quantum algorithm fell apart, the classical algorithm wrapped around it held the line. Never deploy a PQC algorithm on its own until it has survived a decade of public scrutiny. For a comprehensive guide covering TLS, SSH, and IPsec protocols, refer to A Comprehensive Guide to TLS, SSH, and IPsec with Post-Quantum Cryptography.

Conclusion

The transition to Post-Quantum Cryptography is a marathon, not a sprint. But the starting gun has already fired.

Focus immediately on building your Cryptographic Bill of Materials (CBOM) and upgrading your core protocols (TLS 1.3, OpenSSH 10.0, OpenSSL 3.5.0) to mitigate the Harvest-Now-Decrypt-Later threat. Once your key exchanges are secured, you can begin the arduous, multi-year process of migrating your PKI and authentication systems to ML-DSA.

Do not wait for Q-Day to scramble your engineering teams. The vendors who act now will secure their data; those who delay will face catastrophic compliance and security failures.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

1. What is the difference between ML-KEM and ML-DSA?

ML-KEM (FIPS 203) is a Key Encapsulation Mechanism used to securely establish a shared secret over a public channel. ML-DSA (FIPS 204) is a Digital Signature Algorithm used to authenticate identity and ensure data integrity.

2. Why is TLS 1.3 required for Post-Quantum Cryptography?

PQC algorithms rely on modern cryptographic primitives and hybrid key exchange negotiations that are only supported in the TLS 1.3 protocol architecture. Legacy TLS versions cannot securely negotiate these new standards.

3. What is a Harvest-Now-Decrypt-Later (HNDL) attack?

HNDL is an attack where adversaries intercept and store encrypted data today. They cannot read it now, but they are waiting for a Cryptographically Relevant Quantum Computer (CRQC) to be built in the future to decrypt the stored traffic.

4. Can I use PQC algorithms for OpenSSH authentication today?

Not yet. While OpenSSH 10.0 supports PQC for the initial key exchange (stopping HNDL attacks), it does not currently support PQC digital signatures for user authentication due to ongoing standardization and integration work.

5. What is Cryptographic Agility and why use Hybrid Cryptography?

Cryptographic agility is the ability to easily swap out algorithms if one is broken. Hybrid cryptography combines a proven classical algorithm (like X25519) with a new PQC algorithm, ensuring data remains secure even if the new PQC math is unexpectedly compromised.