15 Jul 2026 · by Rehan Azaz

Starting the post-quantum migration before we had to

CryptographySecurityTLS

Code editor showing an AWS KMS client configured for hybrid post-quantum TLS

A security questionnaire came in from a prospective B2B customer with a line item we couldn't tick: describe your roadmap for post-quantum cryptography. We didn't have one. Protect-A-Plate stores licence-plate numbers tied to identity — the kind of record that is still sensitive in ten years, which is exactly the data that "harvest now, decrypt later" is aimed at. That questionnaire turned a someday into a this-quarter.

What the threat actually touches

AES-256 on the stored records is fine. Grover's algorithm halves the effective key strength, so 256 bits behaves like 128 — still well out of reach. The part that breaks is the asymmetric cryptography: the key exchange that sets up every TLS session, and the RSA and elliptic-curve operations that wrap data keys. Shor's algorithm takes those apart. So the risk surface isn't the ciphertext sitting in the database, it's the handshake in front of it and anything doing key wrapping with classical public-key crypto.

Harvest now, decrypt later makes the timing the point: an adversary recording TLS sessions today can hold them until a cryptographically relevant quantum computer exists and decrypt them retroactively. Data with a long confidentiality lifetime is the part you migrate first — CISA, the NSA, and NIST have jointly warned that this kind of harvesting against critical infrastructure is a present-day risk, not a hypothetical one.

The state of the ecosystem

NIST finalised the standards in 2024 — FIPS 203 for ML-KEM (key encapsulation), FIPS 204 for ML-DSA (signatures), FIPS 205 for SLH-DSA. Through 2025 the rest caught up: major browsers and CDNs — Cloudflare among the first — turned on a hybrid X25519 + ML-KEM-768 group by default, so a large share of real traffic is already negotiating it. Hybrid means both key exchanges run and their secrets are combined — if ML-KEM turns out to have a flaw, you are no worse off than X25519 alone.

What we changed

Hybrid key exchange at the TLS edge. Enabled X25519MLKEM768 on the edge termination. At this point it is close to a config flag — a security-policy setting on the CDN, or an OpenSSL 3.5 build behind nginx. Pointed openssl s_client at the endpoint afterwards to confirm the negotiated group was the hybrid one and not a silent downgrade.
Post-quantum TLS to KMS. Data keys are wrapped and unwrapped by AWS KMS, and the SDK call to KMS is itself a TLS session worth protecting. The CRT-backed client negotiates a hybrid group on that connection:

import { KMSClient } from "@aws-sdk/client-kms";

// CRT-backed handler negotiates hybrid X25519 + ML-KEM
// on the TLS session to the KMS endpoint.
const kms = new KMSClient({
  region: "eu-west-1",
  requestHandler: { postQuantumTlsEnabled: true },
});

At-rest re-wrapping — staged, with a date. The stored blobs are AES-256-GCM, treated as quantum-resilient for now. The key wrapping underneath KMS is still classical, and re-wrapping every record against an ML-KEM KEM is a real project, not a flag. It is on the roadmap with a quarter attached rather than "later".

The incident it caused

An ML-KEM-768 client share is about 1.2 KB, against 32 bytes for X25519. The ClientHello stops fitting in a single packet and spans two. Most of the internet handles that fine; one corporate customer's network did not. A middlebox on their side silently dropped the fragmented ClientHello, and their users got connection failures that looked like our outage. It was their IT that fixed it, but the debugging session was ours, and the lesson stuck: a bigger handshake finds the boxes that were never really following the spec.

The takeaway

You don't need a quantum computer to exist for this to be worth doing — you need data whose secrecy has to outlast one. The first step is nearly free: turn on hybrid key exchange at the edge and watch your error rates for fragmented-ClientHello breakage. The at-rest re-encryption is the expensive part, and staging it is fine — as long as "later" has a date on it.

FAQ

What is post-quantum cryptography and why does it matter now?

Cryptography designed to resist attacks from a sufficiently powerful quantum computer, standardised by NIST as ML-KEM, ML-DSA, and SLH-DSA. It matters now, before such a computer exists, because of harvest-now-decrypt-later: data encrypted today with breakable key exchange can be recorded today and decrypted retroactively once the capability arrives.

What is "harvest now, decrypt later"?

An attack pattern where an adversary captures encrypted traffic today with no ability to read it yet, and simply waits — storing it until a future quantum computer can break the classical key exchange that protected it. It only matters for data with a confidentiality lifetime longer than "a few years," which is most identity-linked and health data.

Does AES-256 need to be replaced for post-quantum security?

No. Grover's algorithm gives a quantum computer at most a quadratic speedup against symmetric ciphers, so AES-256 degrades to roughly AES-128-equivalent strength — still far out of reach. The vulnerable part is asymmetric cryptography: the key exchanges and signatures that set up a session or wrap a key, which Shor's algorithm breaks outright.

What is hybrid post-quantum key exchange?

Running a classical key exchange (like X25519) and a post-quantum one (like ML-KEM) together and combining both resulting secrets. If ML-KEM turns out to have an undiscovered flaw, the session is still exactly as safe as X25519 alone was — hybrid mode can only add security, never remove it.

Will enabling post-quantum TLS break anything?

Usually not, but test for it: an ML-KEM-768 client share is around 1.2 KB versus 32 bytes for X25519, which pushes the ClientHello across two packets instead of one. Most networks handle that transparently; a small number of older middleboxes silently drop fragmented ClientHellos, which shows up as connection failures that look unrelated to TLS.

When do I actually need to worry about post-quantum migration?

As soon as you hold data that has to stay confidential for years and it crosses a network you don't fully control — which is most identity-linked, financial, or health data. If nothing you handle needs secrecy past the next couple of years, this is lower priority; if any of it does, the TLS-edge step above is cheap enough to do regardless.