"Post-quantum migration" sounds like a multi-year project, and at the org level it is. But the part most backend devs actually touch, post-quantum key exchange on your TLS, is now almost anticlimactically simple. OpenSSL 3.5 ships the hybrid groups natively. It's closer to one config line than a migration.

Why bother now (the one honest reason)

"Harvest now, decrypt later." An attacker can record your encrypted traffic today and decrypt it years from now once quantum hardware catches up. So anything with a long secrecy lifetime, health data, credentials, anything regulated, is effectively exposed in transit if you're on classic X25519/RSA alone. PQC key exchange closes that one specific hole.

Check what you've got

The post-quantum groups landed in OpenSSL 3.5:

openssl version # you want 3.5.0 or newer openssl list -kem-algorithms | grep -i mlkem

Test any server for PQC support

You can probe a server right now. Cloudflare's edge has done hybrid PQC for a while:

openssl s_client -groups X25519MLKEM768 -connect cloudflare.com:443 </dev/null 2>/dev/null \ | grep -i "Negotiated TLS1.3 group"

If it prints X25519MLKEM768, that handshake used post-quantum key exchange. Point it at your own host to see where you stand.

Turn it on (nginx example)

With an OpenSSL 3.5+ build, you just tell it which groups to offer, hybrid first:

ssl_protocols TLSv1.3; ssl_ecdh_curve X25519MLKEM768:X25519;

X25519MLKEM768 is the hybrid: it runs classic X25519 and ML-KEM-768 together. If a client doesn't support the PQC half, it falls back to plain X25519. So turning it on costs you nothing in compatibility, modern clients get PQC, older ones get exactly what they got before.

Reload, then re-run the s_client test against your own server to confirm.

The one real gotcha: signatures are the hard part

Key exchange (ML-KEM) is the cheap, high-value win, and it's what stops harvest-now-decrypt-later. Post-quantum signatures (ML-DSA) are the heavy lift: the keys and signatures are much larger, which bloats handshakes and certificates, and the CA/cert ecosystem is still catching up. So the pragmatic 2026 move is to enable hybrid PQC key exchange now (cheap, safe) and watch the signature side rather than forcing it early.

I wrote up the full server-migration picture, the FIPS 203/204 standards, the performance tradeoffs, and a staged rollout plan, here: Beyond RSA: The 2026 Server Migration Guide to Post-Quantum Cryptography

Anyone flipped on hybrid PQC in prod yet? Curious whether you've seen any real handshake-size or latency impact.