Post-Quantum Cryptography Migration: A 2026 Developer's Guide

Run this against a real server today:

Bash
Copy
echo | openssl s_client -groups X25519MLKEM768 -connect cloudflare.com:443 -brief

On OpenSSL 3.5 or later, you get back:

Negotiated TLS1.3 group: X25519MLKEM768

That is not a lab demo. That is a production TLS handshake, right now, using a hybrid post-quantum key exchange, against one of the busiest edges on the internet. Cloudflare Radar reports that more than 60% of human-generated TLS traffic on its network now negotiates hybrid ML-KEM, up from just over half in late 2025. This migration is not a future concern for developers to plan around eventually. It is already live in the browsers and libraries most of us use every day, and there is a concrete, code-level reason it happened this fast.

Why "Harvest Now, Decrypt Later" Changes the Math

No quantum computer today can break RSA-2048 or ECC. Google's Willow chip has 105 physical qubits, and the best public demonstrations of error-corrected logical qubits are still in the tens, not the thousands needed for a cryptographically relevant attack. So why is OpenSSL shipping post-quantum defaults years before the threat is real?

Because encrypted data captured today can be decrypted later, once a sufficiently powerful quantum computer exists. Intelligence agencies and researchers have described this as an active strategy: adversaries record encrypted TLS sessions, VPN traffic, and archived backups now, and simply wait. If your data needs to stay confidential for 10, 15, or 20 years (health records, government files, trade secrets, long-lived credentials), the encryption protecting it today needs to survive an attack that might not be feasible until the 2030s.

NIST's own migration guidance assumes a 10-year timeline from a standing start, which is exactly why the standards, the libraries, and the defaults have all moved in the last two years. A March 2026 Google research paper lowered the estimated resources needed to break 256-bit elliptic curve cryptography to under 1,450 logical qubits and about 90 million Toffoli gates, smaller than earlier estimates. IBM's public roadmap targets 200 logical qubits by 2029. Nobody is claiming a cryptographically relevant quantum computer exists or is imminent. The point is that the ciphertext being harvested today has a shelf life measured in decades, and that shelf life is what's driving the urgency.

The NIST Post-Quantum Cryptography Standards: FIPS 203, 204, 205 (and Soon 206)

NIST finalized its first three post-quantum cryptography standards on August 13, 2024, after an eight-year public evaluation process. All three are based on lattice or hash-based math believed to resist both classical and quantum attacks.

ML-KEM is the one you'll touch most often: it replaces the Diffie-Hellman or ECDH step in a TLS handshake. ML-DSA replaces RSA or ECDSA for signing, whether that's a TLS certificate, a code-signing key, or a JWT. SLH-DSA exists as a structurally different fallback in case an unexpected weakness is ever found in lattice-based math. Falcon's compact signatures make it attractive for constrained devices, but its floating-point-heavy signing algorithm is notoriously hard to implement without leaking timing information, which is why it's landing later and with more caution.

Why Hybrid, Not Pure Post-Quantum

Almost nobody is deploying pure ML-KEM or pure ML-DSA in production TLS. What's actually shipping is hybrid: a classical algorithm and a post-quantum algorithm run side by side, and the connection is only as weak as the stronger of the two.

That's what X25519MLKEM768 means in the OpenSSL output above: X25519 (classical elliptic curve Diffie-Hellman) combined with ML-KEM-768. If ML-KEM turns out to have an undiscovered flaw, X25519 still protects the session. If a quantum computer eventually breaks X25519, ML-KEM still protects it. This is a deliberate hedge, not a stopgap, and it's the configuration Chrome, OpenSSL, Cloudflare, and AWS all default to today. Chrome added support for the hybrid ML-KEM key share in version 131, released in November 2024, and now pre-computes both key shares to avoid adding latency to the handshake.

What's Already Shipped in Production

This is not a "coming soon" list. As of mid-2026, all of the following are already true:

• OpenSSL 3.5.0, released April 8, 2025, has native support for ML-KEM, ML-DSA, and SLH-DSA, and made the X25519MLKEM768 hybrid group the default TLS 1.3 keyshare.
• Chrome and Firefox negotiate hybrid ML-KEM by default and pre-generate both key shares so there's no added round trip.
• Cloudflare reports over 60% of human-generated TLS traffic on its edge network is already hybrid post-quantum, and in March 2026 committed, alongside Google, to a 2029 deadline for full PQC migration across their infrastructure.
• AWS added hybrid post-quantum TLS to KMS in 2024 and expanded it to Certificate Manager and Secrets Manager endpoints in early 2026, with a plan to roll it out to more HTTPS endpoints over time.
• Node.js, starting with v24.7.0, has built-in ML-KEM support in the node:crypto module. No third-party dependency required for key encapsulation.
• Kubernetes published guidance in July 2025 for enabling hybrid post-quantum TLS between control plane components, built on Go's standard library support for the same hybrid key exchange groups.

If your infrastructure runs any of the above and you haven't explicitly disabled post-quantum groups, some of your traffic is very likely already hybrid-encrypted without you doing anything.

Try It: ML-KEM Key Encapsulation in Node.js

This runs as-is on Node.js 24.7 or later (tested here on v25.5.0, no flags or dependencies needed):

js
Copy
const { generateKeyPairSync, encapsulate, decapsulate } = require("node:crypto");

// Recipient generates a key pair once
const { publicKey, privateKey } = generateKeyPairSync("ml-kem-768");

// Sender uses the recipient's public key to create a shared secret
const { ciphertext, sharedKey } = encapsulate(publicKey);

// Recipient recovers the same shared secret from the ciphertext
const recovered = decapsulate(privateKey, ciphertext);

console.log("shared key match:", Buffer.compare(sharedKey, recovered) === 0);
console.log("ciphertext size:", ciphertext.length, "bytes");
console.log("shared key size:", sharedKey.length, "bytes");

Output:

shared key match: true
ciphertext size: 1088 bytes
shared key size: 32 bytes

Notice there's no negotiation happening here, ML-KEM is a key encapsulation mechanism, not a key exchange protocol by itself. In a real handshake (TLS 1.3, SSH, or your own protocol), you'd combine this shared key with a classical ECDH shared key using a KDF, which is exactly what the hybrid groups above do under the hood.

Try It: Signing with ML-DSA

Same module, no extra dependency, for the signature side of the migration:

js
Copy
const { generateKeyPairSync, sign, verify } = require("node:crypto");

const { publicKey, privateKey } = generateKeyPairSync("ml-dsa-65");
const message = Buffer.from("firmware-v2.4.1-release-build");

const signature = sign(null, message, privateKey);
const isValid = verify(null, message, publicKey, signature);

console.log("signature size:", signature.length, "bytes");
console.log("verified:", isValid);

Output:

signature size: 3309 bytes
verified: true

That 3,309-byte signature versus roughly 64 bytes for an ECDSA P-256 signature is the tradeoff nobody advertises upfront: ML-DSA signatures are about 50 times larger. For a TLS handshake this barely registers. For a resource-constrained IoT device signing thousands of small messages, or a blockchain storing signatures on-chain, that size difference is a real design constraint, not a rounding error.

If you're not on Node 24.7+, the noble-post-quantum and mlkem npm packages implement the same FIPS 203/204 algorithms in pure TypeScript for browsers and older runtimes.

Try It: OpenSSL From the Command Line

Generating post-quantum keys directly with OpenSSL 3.5+:

Bash
Copy
# Generate an ML-KEM-768 key pair (for key exchange)
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.pem

# Generate an ML-DSA-65 key pair (for signing)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.pem

# Inspect the key
openssl pkey -in mlkem768.pem -text -noout

And to check which hybrid groups a server actually supports, use the command from the top of this article against your own domain instead of Cloudflare's:

Bash
Copy
echo | openssl s_client -groups X25519MLKEM768:X25519 -connect your-domain.com:443 -brief

If the server doesn't support the post-quantum group, OpenSSL falls back to plain X25519 automatically. This is a safe, read-only way to audit whether your own TLS termination (nginx, HAProxy, a load balancer, a CDN) already negotiates post-quantum key exchange or still needs an upgrade.

How to Plan Your Post-Quantum Cryptography Migration

You don't need to rewrite your cryptography this quarter. You need a plan that doesn't require rewriting it in a panic later.

1. Inventory every asymmetric algorithm in use. RSA, ECDSA, ECDH, and Diffie-Hellman show up in TLS certificates, SSH keys, JWTs, code-signing certificates, VPN configs, and internal service-to-service auth. Most teams are surprised by how much of this is undocumented and buried in config files or third-party dependencies.
2. Build cryptographic agility before you build post-quantum support. If your algorithm choice is hardcoded deep in business logic, migrating it later means another rewrite. Push the algorithm and key configuration out to config, behind an interface, so swapping it is a deploy, not a project.
3. Turn on hybrid TLS where your stack already supports it. If you're on OpenSSL 3.5+, nginx, or a modern load balancer, enabling X25519MLKEM768 is often a configuration change, not new code. This is the highest-leverage, lowest-risk step you can take this month.
4. Prioritize long-lived secrets first. A TLS session key lives for minutes. A code-signing certificate, a root CA, or an encrypted database backup can live for a decade. Migrate signatures and encryption on anything with a long shelf life before you worry about ephemeral session keys.
5. Track your dependencies' PQC support, don't build it yourself. Implementing lattice cryptography correctly, especially constant-time implementations that resist timing attacks, is not a weekend project. Use vetted libraries (OpenSSL 3.5+, Node's built-in crypto, noble-post-quantum, or your cloud provider's SDKs) and update them as support matures.
6. Watch the regulatory deadlines that actually apply to you. CNSA 2.0 requires new U.S. National Security System acquisitions to support post-quantum algorithms starting January 1, 2027, with broader compliance required through 2033. If you sell into government, defense, or regulated industries, these dates are contractual requirements, not suggestions.

Common Post-Quantum Migration Mistakes to Avoid

Deploying pure post-quantum instead of hybrid. Skipping the classical algorithm entirely removes your safety net if a weakness is ever found in the post-quantum math. Every major deployment (Chrome, OpenSSL, Cloudflare, AWS) runs hybrid for a reason. Do the same unless you have a specific requirement that forbids it.

Fixing TLS and forgetting signatures. Hybrid key exchange gets most of the press, but certificates, code signing, and firmware signing are just as exposed to harvest-now-decrypt-later risk if what's being protected needs to stay authentic for years, not just confidential.

Ignoring the size increase. ML-KEM and ML-DSA keys and signatures are meaningfully larger than their classical counterparts. If you have hardcoded buffer sizes, strict MTU assumptions, or protocols that assume small fixed-size keys, test with real post-quantum key sizes before you ship, not after something silently truncates.

Treating this as a one-time project. FIPS 206 is still coming. Parameter recommendations shift as cryptanalysis continues. The teams that will handle this well are the ones with crypto agility baked in, so the next standard is a config change, not a migration project all over again.

Where Post-Quantum Migration Leaves Developers

Nobody can build a quantum computer capable of breaking RSA-2048 today. But the data encrypted with RSA-2048 today can be captured and stored for a decade, waiting for one. That asymmetry, cheap to exploit now, expensive to fix retroactively, is why NIST finalized these standards in 2024, why OpenSSL made them the default in 2025, and why most of the internet's biggest edges are already running hybrid post-quantum TLS in 2026 without most developers noticing.

You don't need to solve this today. You need to know where RSA and ECDSA live in your stack, confirm your TLS termination supports the hybrid groups, and make sure the next algorithm swap is a config change instead of a rewrite. Start with the openssl s_client command at the top of this article, pointed at your own domain, and see where you actually stand.

Related Tools

Auditing and rotating cryptographic material is easier with the right tools on hand:

• SSL Certificate Checker - check any domain's certificate details, TLS version, and expiry before you start planning a migration
• SSH Key Generator - generate RSA and ECDSA key pairs client-side while you inventory which algorithms are still in use
• JWK to PEM Converter - convert between JWK and PEM formats when auditing the keys behind your JWT signing setup
• Hash Generator - generate SHA-256 and SHA-512 hashes to verify file integrity on downloaded libraries and firmware