By Microsoft’s Majorana 2 quantum chip, unveiled at Build 2026 on June 2, just moved Q-Day from 2035 to 2029. That is six years shaved off a timeline most developers treated as someone else’s problem. Meanwhile, intelligence agencies have confirmed what security researchers suspected: nation-state groups are already collecting encrypted traffic today, banking on quantum decryption tomorrow. The NSA has a hard 2027 deadline for post-quantum compliance. The migration has started, with or without you.
The Threat Is Already in Motion
“Harvest now, decrypt later” (HNDL) sounds like a theoretical concern. It is not. The FBI confirmed that Salt Typhoon — a Chinese state-sponsored group — infiltrated at least nine major US telecommunications providers in late 2024, maintaining undetected access for one to two years. FBI Director Christopher Wray called it “the most significant cyber espionage campaign in history.” The goal was intelligence collection: scraping communications data they cannot read yet, but will be able to read once quantum hardware matures.
If your application stores sensitive data that needs to remain confidential for more than three years — health records, financial data, legal communications, long-lived API credentials — that data is a HNDL target. Session tokens with 24-hour expiry are low risk. A database of encrypted PII with no rotation plan is not.
Your Browser Is Already Post-Quantum. Your Server Isn’t.
Here is what most developers do not know: Chrome 131 (November 2024) and Firefox already default to hybrid X25519MLKEM768 for TLS key exchange. Over 60% of human TLS traffic hitting Cloudflare’s network already uses hybrid ML-KEM. Akamai defaulted the same for six million-plus domains in February 2026. The client side of the post-quantum migration is essentially done. The bottleneck is server infrastructure.
FIPS 203 — the NIST-finalized standard for ML-KEM (Module-Lattice Key Encapsulation Mechanism) — replaces RSA and elliptic-curve Diffie-Hellman for the key exchange step of TLS. OpenSSL 3.5, released in January 2026 as a long-term support version, ships ML-KEM built-in. No patches, no third-party dependencies, no experimental flags. It is in the current versions of major Linux distributions right now.
The fix for NGINX is one line:
ssl_ecdh_curve X25519MLKEM768:X25519;This enables hybrid post-quantum key exchange while remaining fully backward-compatible with clients that do not yet support ML-KEM. If a client can negotiate X25519MLKEM768, it will. If it cannot, it falls back to X25519. No breaking changes. The handshake grows by roughly 1-2 KB — modern networks absorb this without measurable latency impact at P50. Monitor your P99 handshake latency after enabling; some TLS clients trigger a HelloRetryRequest on first connection if they have not pre-computed key shares.
To verify your server is advertising the right groups:
openssl s_client -connect yourhost.com:443 -tlsextdebug -tls1_3 2>&1 | grep -A5 "supported_groups"What ML-KEM Doesn’t Fix (And Why That’s Okay for Now)
ML-KEM secures key exchange — the part of the TLS handshake where client and server agree on a symmetric session key. It does not fix authentication, where the server proves its identity via a certificate signed with ECDSA or RSA. FIPS 204 (ML-DSA) handles post-quantum signatures, and OpenSSL 3.5 supports it. But certificate authorities have not broadly issued post-quantum X.509 certificates yet. That ecosystem migration is a 2027 problem at the earliest.
For most production applications, this is an acceptable gap. HNDL attacks primarily target key exchange — capturing the encrypted payload in transit. The server’s certificate signature is harder to exploit in a harvest-now attack because authentication data has a shorter shelf life. Prioritize key exchange first. Signature migration for internal systems (JWT signing, service-to-service auth) can follow. Wait for CA support before touching public TLS certificates.
The Migration Sequence
Phase 1 — Do this week: Upgrade your server to OpenSSL 3.5. Set X25519MLKEM768 as the preferred TLS group in NGINX, HAProxy, or Caddy. Verify with the openssl s_client command above. Zero cost, zero breaking changes.
Phase 2 — Next six months: Audit encrypted data stores. Anything sensitive with a multi-year retention window needs a rotation plan. For Python, the pqcrypto package (PyPI, January 2026) and the quantum-safe library provide ML-KEM and ML-DSA bindings. For Go, crypto/mlkem is in the standard library as of Go 1.24, and Cloudflare’s CIRCL library provides production-ready hybrid combiners.
Phase 3 — 12-18 months: Migrate internal service-to-service signing to ML-DSA-65, the FIPS 204 variant that replaces ECDSA P-256. Monitor the CA ecosystem — first PQ certificates are expected sometime in 2026, with broader trust store support arriving in 2027.
Phase 4 — 2027 hard deadline: NSA’s Commercial National Security Algorithm Suite 2.0 requires post-quantum for new national security systems in 2027. Federal contractors and defense-adjacent organizations have no flexibility here. The rest of the private sector should treat this as a leading indicator of where regulated industries are heading.
Three NIST Algorithms Worth Knowing
NIST finalized three post-quantum cryptography standards in August 2024. Knowing which algorithm does what will save you from the most common migration mistake — treating key exchange and signatures as one problem:
- ML-KEM (FIPS 203) — Key encapsulation. Replaces ECDH/RSA in TLS key exchange. Use ML-KEM-768 for production. This is your Phase 1 target.
- ML-DSA (FIPS 204) — Digital signatures. Replaces ECDSA. ML-DSA-65 is the ECDSA P-256 equivalent. Use for JWT signing, code signing, and internal auth.
- SLH-DSA (FIPS 205) — Hash-based signatures. Slower but with conservative security assumptions. Use for root CA operations and long-lived software signing keys.
Half the confusion around post-quantum migration comes from treating these as interchangeable. ML-KEM and ML-DSA solve different halves of the TLS stack on different timelines. The NGINX PQC implementation guide makes this distinction clearly, and the AWS ML-KEM announcement shows how managed services are handling the rollout.
The Bottom Line
Phase 1 is a configuration change, not a project. If you are running NGINX or HAProxy on a current Linux distribution, you are likely already running OpenSSL 3.5. One line of config and a reload is all that stands between your server and post-quantum key exchange. Do it before you close this tab.
Phases 2 and 3 require planning, especially the data audit. The instinct to defer the entire migration until certificates are fully sorted is understandable but wrong. Key exchange is the highest-risk HNDL vector, it is solvable today, and the window to protect long-lived sensitive data is narrowing. Majorana 2 did not change the direction. It changed the timeline.
