For years, post-quantum cryptography was easy to postpone. The standards were still moving, the libraries were still catching up, and "we will migrate when it is final" was a reasonable answer. On 15 October 2026, that answer got a lot weaker.
That day, the UK National Cyber Security Centre published updated TLS guidance that explicitly recommends hybrid ML-KEM key exchange. It follows the IETF finalising RFC 10024, which standardises hybrid post-quantum key agreement for TLS 1.3. The NCSC also set a date: organisations should have completed cryptographic discovery and migration planning by 2028.
This is not a story about a quantum computer arriving next Tuesday. It is a story about deadlines arriving before the threat does, and about what builders are supposed to do with the time in between.
What actually changed
RFC 10024 defines three hybrid key agreement mechanisms for TLS 1.3:
- X25519MLKEM768
- SecP256r1MLKEM768
- SecP384r1MLKEM1024
Each one combines a classical key exchange with ML-KEM, the NIST-standardised post-quantum key encapsulation mechanism. The NCSC guidance treats these as suitable for general use and for OFFICIAL-tier government data. It also draws a clear line around TLS versions: only TLS 1.3, configured this way, gives you quantum protection. SSL and TLS 1.0 and 1.1 are deprecated and should be off. TLS 1.2 still protects against classical attacks when configured well, but the guidance says to plan a move to TLS 1.3 if you want post-quantum protection at all.
That last point matters more than it looks. A lot of migration talk focuses on swapping an algorithm. In practice, the first obstacle is usually the protocol version, the old client, or the load balancer nobody has touched in three years. The algorithm is the easy part to name. The inventory is the hard part to finish.
Why hybrid, and why that choice is honest
Pure post-quantum would be cleaner on paper. Hybrid is what got standardised, and I think that is the right call.
A hybrid exchange fails safe in two directions at once. If ML-KEM turns out to have a flaw nobody saw yet, the classical half still protects the connection today. If a quantum computer arrives sooner than expected, the ML-KEM half protects it tomorrow. Neither half has to be perfect on its own, because the combination only breaks if both break.
This is the same reasoning I used in my own messenger, where the key exchange pairs ML-KEM-768 with ECDH P-256. I did not choose hybrid because I could not decide. I chose it because migration is a transition, not a switch, and a transition needs a design that works in both worlds while it lasts. Seeing the same pattern in a national guidance document and an IETF standard is reassuring, but it is not a surprise. It is what careful migration looks like when it leaves the lab.
The honest label still matters. A hybrid connection is not "quantum-proof" in some absolute sense. It is protected against a quantum attacker as far as its post-quantum half holds, and it still depends on the implementation being correct, the keys being handled well, and the rest of the system not leaking the plaintext somewhere else. Anyone selling hybrid as a magic shield is selling something else.
The 2028 deadline is about homework, not a flip of a switch
Read the NCSC date carefully. 2028 is the deadline for discovery and migration planning, not for every system on earth to be fully post-quantum. That distinction is the whole plan.
Discovery means answering questions most teams cannot answer today: where do we use public-key cryptography, which libraries and certificates depend on it, which data stays sensitive for ten years or more, and which vendors need to move before we can? If you cannot list your cryptography, you cannot migrate it, and no deadline will fix that for you.
Then comes the prioritisation, and here the old phrase "harvest now, decrypt later" finally earns its keep. An attacker can record encrypted traffic today and decrypt it later, once a capable quantum computer exists. That only matters for data that will still be sensitive then. A chat message about lunch plans is not the same as a medical record, a trade secret, or a credential that stays valid for a decade. The systems carrying long-lived secrets go first. Everything else follows in order of exposure, not in order of panic.
The rest of the world is moving on a similar clock, which makes the UK guidance part of a pattern rather than an outlier. Reports of the 2026 migration landscape point to 1 January 2027 for new US national security system purchases, 2030 for quantum-safe key exchange in high-value federal and EU critical systems, and 2035 for most of the remainder, with France planning to stop certifying products that are not quantum-safe from 2027. The exact dates differ by country and sector. The direction does not.
What this means if you are a small builder, not an enterprise
Guidance written for government and enterprise can feel remote if you are one person with a side project. It should not. Three things from this month's news apply directly at small scale.
First, the infrastructure is already there. Chromium-based browsers have shipped hybrid X25519MLKEM768 by default since version 131. Cloudflare reported in April 2026 that more than two-thirds of human-generated TLS traffic to its network was already protected with hybrid ML-KEM, and moved its target for full post-quantum security forward to 2029. If you deploy behind a modern CDN or proxy, you may already be closer than you think. Check, do not assume.
Second, the work starts with a list, not a purchase. Open your project and write down every place a public key appears: TLS termination, certificates, signed updates, API tokens, backup encryption, the database connection. That list is your migration plan in its first draft, and it costs nothing but an evening.
Third, do not forget authentication. Key exchange is only half the story, and it is the half that got standardised first. Signatures are the other half: a connection encrypted to the wrong person is still a failure, even if nobody can read it in transit. ML-DSA is the post-quantum signature standard, and the same inventory exercise applies to it. I wrote about adding ML-DSA signatures to my messenger precisely because encryption without verified identity left the most obvious attack open. The NCSC guidance is about TLS key exchange; it does not magically fix who you are talking to.
What this does not fix
A guidance document does not patch your code, rotate your keys, or protect data that leaks through metadata, logs, backups, or an endpoint that was never encrypted in the first place. Post-quantum TLS protects data in transit between two endpoints that both support it. It says nothing about what those endpoints do with the data afterwards, who else can read it on the server, or how long it is kept.
That is not a criticism of the guidance. It is a reminder that cryptography is one layer, and the layer most likely to fail in a real project is usually the boring one: key storage, access control, old backups, a debug endpoint left open. The teams that do well in this migration will be the ones that treat the algorithm swap as one item on a longer list, not as the list itself.
The takeaway
The era of "post-quantum is a research topic" ended this month, at least officially. The standards exist. A major national authority has recommended them. The deadlines are written down, and the first one, 2028, is about knowing what you have.
If you build anything that encrypts data, start the inventory this week. Find your long-lived secrets first, move the TLS 1.3 and hybrid ML-KEM work up the list, and keep the labels honest about what is hybrid and what is not yet migrated.
The quantum computer is not here yet. The homework is, and for once it arrived early enough to actually do.
A note on honesty, as with my previous posts: my messenger protocol is an experimental project built by one person. It has not been independently audited, and I do not present it as a finished product. This post is commentary on public guidance and standards, not a claim about enterprise deployments I have not done.
Top comments (0)