Post-Quantum TLS Breaks at the Handshake, Not the Cipher.
The symmetric encryption protecting your sessions is largely fine. It's the handshake — the key exchange and the certificate chain — that a quantum adversary dismantles, and that's the part hardest to change.
Say "a quantum computer breaks encryption" to a room of engineers and most of them picture the cipher: the AES protecting the bytes on the wire giving way, sessions laid open in bulk. That picture is almost exactly backwards. The symmetric encryption in a modern TLS session is the part that survives the quantum transition in the best shape. The part that does not survive is the handshake — the few hundred milliseconds in which two endpoints agree on a key and prove who they are.
That matters because the handshake is also the part of TLS you have the least unilateral control over. The record layer is a local choice: pick a stronger cipher, ship it, done. The handshake is a negotiation with every client, every certificate authority, and every middlebox on the path. Changing it means changing an ecosystem, and ecosystems move at the speed of their slowest participant.
What quantum actually threatens in TLS
It helps to be precise about which quantum capability threatens which primitive, because the two relevant algorithms do very different things. Shor's algorithm, conceptually, solves the hidden mathematical structure — factoring and discrete logarithms — that public-key cryptography is built on. Every asymmetric primitive in classical TLS depends on that structure: the ECDH key agreement and the RSA or elliptic-curve signatures in the certificate chain. A sufficiently capable quantum computer running Shor recovers the private key from the public one. Grover's algorithm is a different and far milder threat: it offers a quadratic speedup for brute-force search, which against a symmetric cipher or a hash effectively halves the security level. Halving is survivable; the clean break Shor delivers against asymmetric math is not. TLS inherits exactly this split — the asymmetric handshake is where the damage is fatal, the symmetric record is where it is merely a parameter change.
Symmetric is fine, mostly
The AEAD record layer — AES-GCM, or a ChaCha-class construction — is where the bulk of your data actually gets encrypted, and it is in good shape. Grover's quadratic speedup means a 128-bit key offers something closer to 64 bits of effective resistance against an ideal quantum search, which is not a margin anyone should rely on; but the remedy is to move to 256-bit keys, and the strength is restored. That is a cipher-suite choice, not a protocol redesign, and TLS 1.3 already negotiates 256-bit AEAD suites. The word doing the work in "mostly" matters, though. The record layer is only as secret as the key the handshake produced. If that key can be recovered — and we are about to see that it can — then the strength of the cipher protecting the session is beside the point. A perfect lock on a door whose key was copied is not protecting anything.
The key exchange is the urgent part
In TLS 1.3 the client offers one or more key_share entries — ephemeral public values, classically an X25519-class elliptic-curve point — and the server responds with its own. Each side combines its private value with the other's public one to derive a shared secret that seeds the session keys. The entire confidentiality of the session rests on the assumption that no one watching the wire can turn those public values back into the shared secret. Shor breaks precisely that assumption. And here is the part that makes key exchange urgent today rather than on the day a quantum computer is announced: an adversary does not need the computer now. They need only record the handshake and the ciphertext now, store it, and derive the key later, once the capability exists. The confidentiality of a session captured today has a shelf life that ends whenever that machine arrives. The response is hybrid key exchange — carrying both a classical X25519 share and an ML-KEM (FIPS 203) share in the same handshake and combining both secrets, so the session key is safe unless both the classical and the post-quantum component break. It is a change to the named groups and the key_share, deployable connection by connection, which is why it is the first thing to move.
A quantum adversary does not need to break the cipher protecting your session; it needs only to have recorded the moment your two endpoints agreed on the key, and to be patient.
The certificate chain is the slow part
The signatures in the certificate chain are just as vulnerable to Shor as the key exchange — the math underneath an elliptic-curve or RSA signature is the same math Shor dismantles. But the threat has a different shape in time. A signature authenticates; forging one lets an attacker impersonate a server. To do that the attacker needs the quantum computer at the moment of the handshake, because a session that already completed cannot be retroactively re-authenticated by a forgery produced years later. Authenticity is a future threat; confidentiality is a retrospective one. That difference in urgency is real, and it is fortunate, because migrating the certificate ecosystem is the slow part by a wide margin. Every link in the chain — leaf, intermediates, roots in the trust store — carries a signature, and moving to a post-quantum signature scheme such as ML-DSA or SLH-DSA means certificate authorities, every intermediate, every root shipped in every trust store, and every verifier agreeing on the new algorithms. That is coordination measured in years, not a flag you flip. The post-quantum signatures and public keys are also substantially larger than their elliptic-curve predecessors, which pushes the problem straight into the next one.
Bigger handshakes, real breakage
Classical key shares and signatures are tens of bytes. ML-KEM key shares and post-quantum signatures are kilobytes. That sounds academic until you remember that a TLS handshake's first flight was quietly engineered to be small, and a great deal of infrastructure assumes it stays that way.
- The ClientHello outgrows one packet — A hybrid key share can push the ClientHello past the size that fit in a single datagram, so the first message of the handshake now spans multiple records or packets instead of arriving whole.
- Extra round trips appear — If a client offers the wrong group and the server asks it to retry, or if fragmentation forces reassembly, the latency budget TLS 1.3 worked hard to shrink to a single round trip starts to grow again.
- Amplification and buffer limits bite — Mechanisms that cap how much a server may send before a client is validated, and stacks with fixed-size handshake buffers, were sized for small flights and can stall or reject large ones.
- Old assumptions surface as bugs — Code that assumed a ClientHello arrives in one piece, or that a key share is a fixed small size, fails in ways that look like network faults rather than cryptographic ones.
Middleboxes and the intolerance problem
TLS 1.3 already fought a long campaign against intolerance — middleboxes that inspect handshakes and reject anything they were not built to recognize. The protocol carries scar tissue from that fight, including the way it disguises itself as an older version on the wire to survive hostile networks. Post-quantum handshakes reopen the wound. An inline inspection device that chokes on an unfamiliar named group, or that cannot cope with a ClientHello split across several records, will drop the connection — and it will usually do so silently, with no signal that explains it rejected your post-quantum key share. The symptom is a handshake that fails on some network paths and not others, which is one of the most expensive classes of bug to diagnose because it looks like everything except what it is. The only reliable way to find these paths is to test the real ones, with real clients, across the networks your users actually sit behind — not a clean lab.
Migrating TLS deliberately
The order of operations follows directly from the threat. Hybrid key exchange goes first, because confidentiality is under attack today through capture-now-decrypt-later, and because it is the change you can make unilaterally on your own endpoints. The certificate-chain migration to post-quantum signatures is planned in parallel but executed on the ecosystem's timeline, not yours, and the sane posture in the meantime is crypto-agility: the ability to negotiate and swap named groups and signature algorithms without re-architecting, so that when the signature side is ready you are not rebuilding from scratch. Throughout, the symmetric layer simply moves to 256-bit keys and is otherwise left alone — the one part of the story that really is a parameter change.
None of this is exotic. It is a disciplined reading of which part of a familiar protocol is actually exposed, in what order, and on whose schedule. When 6QURE reviews a TLS deployment for the post-quantum transition, that is the work: separating the part that is merely a parameter from the part that is a standards-body migration, confirming that the handshake can carry a hybrid key share across the real network paths in play, and making sure the design can negotiate the algorithm it has not yet had to choose. The cipher is rarely the problem. The handshake, and the ecosystem it has to negotiate with, almost always is.
Facing something like this in your own environment?