Post-quantum TLS: what migrated first and why

Almost every threat in this course arrives forwards. Someone floods a service, someone hijacks a route, someone gets a foothold and moves sideways, and the damage lands at roughly the time the attack happens. The threat that drives post-quantum cryptography runs the other way. The attack on a conversation you have today is carried out years from now, and there is nothing you will be able to do about it then.

The mechanism is called harvest now, decrypt later, and it is dull rather than exotic. An attacker who can see traffic in bulk copies the encrypted bytes and stores them. They cannot read anything. They do not need to. They are betting that at some point a machine will exist that can break the key exchange that protected those sessions, and on that day the whole archive becomes readable at once. The capability required today is storage and patience, both of which are cheap and neither of which leaves a trace on your network.

That inversion changes the planning question. People argue endlessly about when a quantum computer capable of breaking today's public-key cryptography will exist, and nobody knows. The argument is beside the point, because the number that decides your exposure is one you already own. Add the number of years your data must stay secret to the number of years your estate would need to change its cryptography. If that sum reaches past the arrival of a capable machine, the traffic you are sending this afternoon is already exposed. You cannot control the arrival date. You can control both of the numbers you are adding to it.

Which makes the exposure specific rather than universal, and worth being honest about. A session cookie for a service you will have retired in two years is not the problem. Health records, legal advice, source code that will still be running the business in a decade, engineering drawings, negotiating positions, credentials that nobody rotates and anything that identifies a person are the problem, because their value does not expire on the timescale of the attack. The organisations with the shortest deadline are the ones holding secrets with the longest shelf life, and they are usually not the ones with the newest infrastructure.

Now the asymmetry that decides the whole migration order. A key exchange has to protect a secret for as long as the data behind it stays valuable, which can be decades. A signature has a far shorter job: it proves, during the handshake, that the server presenting a certificate holds the matching private key. Once that handshake has completed and the session has closed, nobody can go back and convince your browser of anything about it. A forged signature in 2035 cannot retroactively fake a connection your laptop made in 2026, because in 2026 there is no longer anyone to deceive.

This is also where the reassurance from the earlier TLS module runs out. Forward secrecy, which TLS 1.3 requires, means that stealing a server's long-term private key later does not expose sessions recorded earlier, because each session used ephemeral keys thrown away afterwards. That defends against theft of a stored key. It does not defend against an attacker who breaks the mathematics of the ephemeral exchange itself, which is exactly what a quantum computer is expected to do. Forward secrecy is not the answer to this threat, and treating it as one is a common and comfortable mistake.

NIST puts the motivation for the transition plainly in IR 8547, its initial public draft on moving to post-quantum standards: an adversary can copy encrypted traffic today and hold it until quantum technology has matured enough to decrypt it, so information that must stay confidential for many years is already at risk from a machine that does not yet exist.

This is why the migration starts now rather than when the hardware arrives. It also explains why the first question in a serious post-quantum conversation is not about algorithms at all. It is about which of your data would still matter to someone in 2035, because that inventory, not a vendor roadmap, decides how urgent this is for you.

The threat sets the order: confidentiality first, authentication after. It does not name a single algorithm to put in its place, and for most of the last decade that was the honest gap in every post-quantum conversation, because there was nothing standardised to recommend. In August 2024 the gap closed.

NIST finalised three post-quantum cryptography standards in August 2024, and they divide along exactly the line drawn in the previous section. FIPS 203 standardises ML-KEM, a key encapsulation mechanism. FIPS 204 standardises ML-DSA and FIPS 205 standardises SLH-DSA, both signature schemes. One standard for agreeing secrets, two for proving identity.

For a reader who does not work in cryptography, those two categories are worth holding in plain words. A key encapsulation mechanism is the machinery two parties use to end up holding the same secret number, having exchanged only messages that anybody watching could read. A signature scheme is the machinery for proving that a particular message came from the holder of a particular private key. The first protects what you said. The second establishes who you were talking to. They fail in different ways and, as the last section argued, they fail on different clocks.

Nothing on that list replaces the encryption that protects the bytes once a session key exists. These are public-key standards, and the public-key half is the part a quantum computer is expected to unpick. The symmetric encryption doing the heavy work inside an established session is not being replaced, which is one reason the migration is a change to handshakes rather than a rebuild of every protocol.

Standardising two signature schemes rather than one looks like indecision and is the opposite. The two rest on different mathematical foundations, so a weakness found in one family does not automatically take the other with it. Given that the entire point of this exercise is to survive a break that nobody has fully anticipated, holding a spare in a different family is a reasonable use of a standards process.

The dates matter more than the algorithm names for most people reading this. NIST IR 8547, published as an initial public draft, sets the transition timeline: classical public-key cryptography is deprecated after 2030 and disallowed after 2035. Those two words are not synonyms, and the five years between them are the point. The gap is the window in which an estate is expected to finish, not the window in which it is expected to start.

Read as a procurement instruction rather than a cryptographic one, that timeline says something concrete. Anything you buy now with a ten-year service life has to be able to change its cryptography within that life, without being replaced. That property is a design question you can ask a supplier in writing today, in ordinary language: what would it take for this system to negotiate a different key exchange, and who has to do it. A supplier who cannot answer has told you something useful about 2030.

One point of discipline, because this course is fussy about it. NIST IR 8547 is an initial public draft. Planning against its dates is sensible, because they are the clearest published dates anyone has, and describing them as final would be wrong. The same discipline applies with more force to the TLS specification in the next section.

Published dates say when classical public-key cryptography stops being acceptable. They say nothing about what to run in the meantime, and the answer that actually deployed is not the one the standards alone would suggest. Almost nobody is running ML-KEM on its own.

What is actually deployed in browsers is a hybrid key exchange. One ClientHello carries two key shares: a classical X25519 share and an ML-KEM share. The server answers both. The TLS key schedule mixes the two resulting secrets into one session secret. An attacker who records that handshake has to break both exchanges to recover anything, because either secret alone is missing an ingredient.

The combination has a name that appears in real tooling: X25519MLKEM768. It is specified in draft-ietf-tls-ecdhe-mlkem, which is an Internet-Draft rather than an RFC. Both of those statements are true at once, and holding them together is the professional skill. You may say, with evidence, that mainstream browsers negotiate this group by default and that it protects a large share of real traffic. You may not cite it as a settled standard, and you should expect that the details can still change, because that is what a draft is.

Hybrid rather than pure post-quantum is a statement about confidence, not about performance. Confidence in a cryptographic primitive is earned by years of clever people failing to break it, and the post-quantum schemes are young by that measure. Running the new scheme alongside the old one means nobody has to bet on either in isolation. It is also the reason the change could ship in April 2024, months before FIPS 203 was finalised: the worst realistic outcome of the new half being wrong was the security everyone already had.

The document behind the group is worth naming precisely, because this course will keep asking you to. draft-ietf-tls-ecdhe-mlkem, Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, defines hybrid key agreement mechanisms for TLS 1.3 that combine ML-KEM with an elliptic-curve exchange, and X25519MLKEM768 is the one that deployed widely. A working draft of the IETF has no formal standing and can be changed or withdrawn, which has not stopped it becoming the specification behind a default in two major browsers. Citing it as an RFC is the tell that somebody has repeated a claim rather than checked it.

The deployment picture is the reason this module exists in a networking course rather than a cryptography one. Hybrid key exchange has been default in Chrome since version 124 in April 2024, as X25519Kyber768 then as X25519MLKEM768 from version 131, and in Firefox 132. More than 30 percent of TLS 1.3 handshakes at Cloudflare's edge used post-quantum key exchange in early 2026. This is no longer a pilot, and it reached that state without a single project board approving it.

Read that percentage the way this course reads every percentage. Measurement literacymeans naming the population, the method and the window before quoting the number. The population is traffic arriving at one large edge network, the denominator is TLS 1.3 handshakes rather than all connections, and the window is early 2026. It is not a statement about the internet as a whole. It is still the most useful single figure available, because it is measured at a vantage point that sees a large and varied slice of the world's web traffic, and because it counts what was actually negotiated rather than what was advertised.

The gap between the two facts is where the operational work sits. If two major browsers offer the group by default, the share of handshakes that use it is not limited by clients. It is limited by servers, and by the equipment sitting in front of servers: load balancers, TLS terminators, inspection appliances and anything else that ends a connection on your behalf. When a browser offers the hybrid group and the far end does not support it, the handshake completes anyway using a classical exchange. Negotiation is doing its job.

Which produces the failure mode this course has met in several forms already. Nothing tells the user that their connection is classical-only. There is no warning, no padlock change, no log line by default. It is exactly the quiet fallback that hides a broken IPv6 path or a blocked UDP port 443, and the answer is the same: if you want to know, you have to measure the negotiated result rather than trust that the page loaded.

One consequence carries further than the web. Because QUIC folds the TLS 1.3 handshake into its own, the same key exchange groups apply there. A move in TLS is a move in HTTP/3 at the same time, which is a good outcome from the decision to build QUIC on TLS rather than beside it.

So the confidentiality half has moved, quietly, by default, and measurably. The other half of TLS, the part that proves the server is the one named in the address bar, has barely moved at all.

The certificate your browser validated on the way to this page was signed with classical cryptography, and so was every certificate above it. That is not an oversight anybody is embarrassed about. It is the consequence of the timing asymmetry from Section 30.1 meeting the shape of the thing that has to change.

Recall the certificate chainfrom the applied stage: the server's certificate is signed by an intermediate, the intermediate by a root, and the root is already sitting in the trust store on your device. Every link is somebody else's signature. Migrating the key exchange needed two ends to agree, and the two ends were a browser and a server. Migrating signatures needs a certificate authority, its intermediates, its roots, the trust stores inside every operating system and browser, and every client that validates a chain, to agree or at least to interoperate during the change. Some of those clients are appliances that will never receive another update.

Because the deadline is different, that slowness is affordable. Nobody gains anything by recording a signature today and forging it in 2035, since the handshake it authenticated is long over and the session key it helped establish has been discarded. An attacker with a quantum computer in 2035 can forge certificates and impersonate servers in 2035, which is a serious problem for 2035 and precisely why the IR 8547 dates exist. It is not a reason to prioritise signatures over key exchange today.

Signature migration has started where the ecosystem problem is smallest. Cloudflare began offering ML-DSA on origin-facing connections in mid 2026, which is the leg between its edge and a customer's own origin server. Both ends of that leg are known, both can be updated on the same day, and no public trust store is involved. It is the sensible first place to run post-quantum signatures in earnest, and it is a useful signal of direction, not evidence that browser-facing certificates are about to change.

This is the distinction to carry into any conversation with a supplier. When a product is described as quantum safe, the useful question is which half. Ask which key exchange group it negotiates and how you can see that for yourself. Ask whether the certificate is classical, expect the answer to be yes, and treat that as correct rather than as a gap. A supplier who cannot tell you the negotiated group is not describing a property of their product; they are describing a slide.

Knowing which half moved and why is enough to hold your own in that conversation. It is not yet enough to decide what to do on Monday, and the actions are smaller and less expensive than the subject suggests.

Three pieces of work follow from everything above, and none of them requires buying anything. They are an inventory, a measurement and a plan, in that order, because each one makes the next one cheaper.

The inventory answers one question: which of our data, if copied off the wire today, would still matter to somebody in 2035? Ask it about the traffic rather than the storage, because this threat is about what crosses a network. The answer is a list, and the list is what turns an abstract argument about quantum computers into a priority order. A hospital, a law firm, a defence supplier and a news site will produce different lists and should therefore behave differently. This step is where most organisations discover that the honest answer is smaller than they feared, or considerably larger.

The measurement answers the second question: what does our own stack actually negotiate? A browser's security panel names the negotiated key exchange group, and X25519MLKEM768 appears there by name in Chrome. Do that against your own public services, then keep going past the website: the remote-access gateway, the API endpoints, the mail servers, the appliance that terminates TLS in front of everything else. It costs minutes and it produces evidence rather than assumption, which is the habit this whole course has been building. What you cannot observe being negotiated is not protecting you.

The plan is then dated rather than aspirational, and the dates come from published documents instead of a supplier's roadmap: deprecated after 2030, disallowed after 2035. Set your own milestones inside that window and give each system on the inventory a date by which it must be able to negotiate a post-quantum group. Systems that cannot, and cannot be changed, are not a cryptography problem. They are a replacement decision you now have several years to make calmly.

A second published schedule is quietly helping. The certificate lifetime reductions taught in the TLS module, agreed in CA/Browser Forum ballot SC-081v3 on 11 April 2025, cut maximum public certificate validity to 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029. That schedule forces ACME automation on anyone who has not adopted it, and an estate that can reissue every certificate without a human is an estate that can change signature algorithm when the time comes. The two migrations are separate, and the capability the first one demands is exactly the capability the second one will need.

Three things are worth refusing along the way. Do not wait for a flag day, because this migration has no single date and the browsers proved it by shipping ahead of the standards. Do not treat post-quantum readiness as a property you purchase, because it is a property of a negotiated connection that you can go and look at. Do not assume recorded traffic is hypothetical, because recording is the cheapest thing an adversary on a network path can do and it is the one part of this threat that requires no future technology at all.

The check below is on the ordering argument, because it is the one claim in this module that a professional will be asked to defend out loud, usually by somebody who has read a headline about quantum computers breaking encryption and wants to know why the certificates have not changed.