Post-Quantum Cryptography: The TLS Inventory to Run Now

Quantum keeps arriving on my desk as a slide. Not as a workload, not as a ticket, as a slide in a vendor deck, and lately almost always a slide about encryption. The shape is consistent: a timeline with a scary year on it, a logo wall, and a call to action that resolves to booking a follow-up workshop. I have been nodding politely at that slide for years and filing quantum under interesting, not actionable. It still feels like far away technology.

What I got wrong was treating it as one decision. There are two, and they run on completely different clocks. One is a watching brief and can stay there. The other moved while I was not looking. Cloudflare switched post-quantum key exchange on for every zone it hosts. OpenSSL shipped it as the default in its current LTS. Nobody asked my opinion, and the change landed in my estate anyway.

This article is about telling those two apart, and about a check you can run this afternoon to find out which parts of your own estate already moved without you.

The Weather Station and the Levee

Picture a research station on the hill above a valley town. It is real, it is staffed, and you can book time on it. You radio in a request, wait your turn on the schedule, pay for the transmission, and hours later you get a readout: a spread of possible pressure fronts with confidence bands, not the sentence "it will rain on Thursday". Genuine engineering. Nobody in the town has yet changed a single decision because of anything it printed.

Down in the valley there is a levee, built decades ago to a flood-height spec that was correct at the time. The rain that matters fell upstream days ago and is already moving. Water is seeping at the base, quietly, well before anything visible happens to the wall. An engineer is walking that wall this morning, checking which sections were rebuilt and which were not.

The architect's mistake is standing at the instruments looking up while the thing that is actually failing is at ground level. Quantum compute is the weather station: real, bookable, not yet load-bearing for any decision you own. Post-quantum cryptography is the levee, and the rain already fell.

There is though the difference that a levee failure is binary: the wall holds or the town floods. Real cryptographic exposure is graduated. TLS in transit, VPN tunnels, backup archives and signing keys each sit on their own timeline with their own upgrade path. Nothing collapses at once, which is precisely why nobody schedules the work.

The Weather Station: Real, Callable, and Not Yours to Build

The services exist and they are not toys. IBM Quantum Platform, AWS Braket and Azure Quantum all take jobs today, and Qiskit has settled into the de facto SDK role, currently at 2.5.2 and requiring Python 3.10 or later.

Architecturally, that job is unremarkable. You submit work to an external provider, it queues behind other people's work, you pay per task and per shot, and what comes back is a probability distribution rather than an answer. If you have ever integrated an async batch-compute service or an external AI provider, you already know this shape, which is why the way you'd gate and meter any external model provider transfers more or less intact.

The pricing tells you how seriously to take it. Braket charges a flat $0.30 per quantum task plus a per-shot rate that depends entirely on which machine you pick, from $0.000425 on Rigetti Cepheus to $0.08 on IonQ Forte for the same nominal operation. The free tier covers one hour of simulation a month for twelve months. IBM's Open Plan gives you 10 free QPU minutes a month, with pay-as-you-go starting at $96 per minute billed by the second.

You could spend a hundred euros learning what these services are. What you cannot do yet is point at a workload where this beats the classical alternative. As of 2026 there is no widely confirmed example of quantum systems delivering consistent real-world performance gains over classical approaches. IBM points at late 2026 for useful advantage. Independent assessments say a decade or more. I am not going to referee that fight, and you do not have to either.

For now, I would say watch and don't build yet. No production commitment, no platform team, no budget line. Know what the services cost so you can answer an exec who has seen the same deck I have. Revisit the moment somebody demonstrates a workload win on a real problem rather than a benchmark built to be won.

The Levee: Why the Timeline Argument Does Not Matter

Harvest now, decrypt later is the whole argument, and it is immune to the timeline fight. An adversary captures encrypted traffic today and stores it. When hardware capable of breaking the key exchange arrives, whether that is 2030 or 2045, everything in that archive opens. The exposure is set at capture time, long before anyone builds the machine.

That flips the trigger for action. The question to ask about a piece of data is how long it has to stay secret. Sensitivity barely comes into it. A session token that expires in fifteen minutes is fine forever. A twenty year medical record, a contract, or an internal design document with a long commercial life is already exposed, today, if it crossed a classical-only channel while somebody was recording.

Meanwhile the standards landed and the defaults followed. NIST published FIPS 203, 204 and 205 on 13 August 2024, covering ML-KEM for key encapsulation plus ML-DSA and SLH-DSA for signatures. Cloudflare turned automatic post-quantum key exchange to origins on for all existing zones and on by default for new ones in July 2026, then extended it to SMTP in August, citing harvest-now-decrypt-later by name. OpenSSL 3.5, the current LTS, ships ML-KEM in the default provider and negotiates X25519MLKEM768 without a plugin.

The cost of all this is roughly 1,088 extra bytes in the ClientHello and 10 to 20 milliseconds of median latency against classical X25519. That is the entire bill.

Walking the Wall: A Crypto Inventory in Twenty Minutes

You cannot plan a migration you cannot see. So before anything else, find out what your own estate already negotiates. This runs on a laptop, costs nothing, and takes about twenty minutes.

Step 1: Get an OpenSSL That Can Actually Do This

Run openssl version on your own machine first. Most systems still report 3.0 through 3.2, and those cannot negotiate ML-KEM at all. No amount of flag-twiddling changes that. Rather than upgrading your system OpenSSL and breaking everything that links against it, borrow one in a container. alpine:3.22 ships 3.5.8, though the base image carries only libcrypto, so the CLI needs installing.

docker run --rm -it alpine:3.22 sh -c "apk add --no-cache openssl && sh"
# then, inside the container:
openssl version

Expect OpenSSL 3.5.8 25 Aug 2026 (Library: OpenSSL 3.5.8 25 Aug 2026). That release is supported to April 2030.

Step 2: Confirm ML-KEM Is Actually There

Before trusting any result, verify the algorithms are present in the default provider rather than behind a plugin.

openssl list -kem-algorithms

Among the output, you are looking for these lines:

  { 2.16.840.1.101.3.4.4.1, id-alg-ml-kem-512, ML-KEM-512, MLKEM512 } @ default
  { 2.16.840.1.101.3.4.4.2, id-alg-ml-kem-768, ML-KEM-768, MLKEM768 } @ default
  { 2.16.840.1.101.3.4.4.3, id-alg-ml-kem-1024, ML-KEM-1024, MLKEM1024 } @ default
  X25519MLKEM768 @ default
  X448MLKEM1024 @ default
  SecP256r1MLKEM768 @ default
  SecP384r1MLKEM1024 @ default

The @ default on each line is the thing worth reading. This is core OpenSSL now, not an add-on.

Step 3: Make One Real Hybrid Handshake

Point it at a host you know supports the hybrid group, so you learn what success looks like before you go hunting for failure.

echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com \
  -groups X25519MLKEM768 -tls1_3 2>&1 | grep -E "Negotiated TLS1.3 group|Protocol|Cipher is"

# success looks like this:
#   Negotiated TLS1.3 group: X25519MLKEM768
#   New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
#   Protocol  : TLSv1.3

That is a real post-quantum key exchange, on your machine, against a production host.

Step 4: Learn What Failure Looks Like

This step is what turns the exercise into a usable pass/fail check. Run the same command against a host that does not support the group, forcing it so the handshake has nowhere to fall back to.

echo | openssl s_client -connect github.com:443 -servername github.com \
  -groups X25519MLKEM768 -tls1_3 2>&1 \
  | grep -E "Negotiated TLS1.3 group|Cipher is|alert handshake failure"

# a clean, unmistakable refusal:
#   ...:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:...:SSL alert number 40
#   Negotiated TLS1.3 group: <NULL>
#   New, (NONE), Cipher is (NONE)

Alert 40 means the server had no shared group to offer. Now you can tell "not supported" from "my script is broken", which matters the moment you run this across fifty hosts and start getting empty output.

Step 5: Survey Your Own Estate

Run the loop, then swap the list for your own hostnames.

for h in architectviewmaster.com www.google.com github.com login.microsoftonline.com; do
  g=$(echo | openssl s_client -connect $h:443 -servername $h -tls1_3 2>/dev/null \
      | grep 'Negotiated TLS1.3 group' | cut -d: -f2- | tr -d ' ')
  echo "$h -> ${g:-none}"
done

Note there is no -groups flag here. You want the normal negotiation, which tells you what the host would actually pick for a real client rather than what it can be forced into. Here is what I got on 21 September 2026:

architectviewmaster.com   -> none
www.google.com            -> X25519MLKEM768
github.com                -> none
login.microsoftonline.com -> none

My own site is in the not-yet column, and so is the place I keep my code and the place a lot of people sign in every morning. Whether any given host moves is mostly a question of when its edge provider flips the switch, which is exactly the point: this is happening to your estate rather than being decided by it.

Step 6: Record What You Found, and Nothing Else

The container was --rm, so there is nothing to tear down. What survives is the list, and the list is the deliverable.

For each entry, write down the host, the negotiated group, who controls the TLS termination, and one more column that does the real work: how long the data crossing that connection must stay secret.

Host class	Negotiated group	Terminated by	Confidentiality lifetime
Public web front door	X25519MLKEM768	CDN edge	Minutes to hours
Partner API	none	Own load balancer	Contract term
Backup replication	none	Own gateway	7 to 30 years
Internal admin	none	Own reverse proxy	Employment records, decades

The rows that should worry you are the ones where "none" meets a lifetime measured in years. Those are the seeping sections of the wall.

One honest caveat, and it matters more than the survey itself. This checks TLS in transit and nothing else. It says nothing about data at rest, VPN tunnels, SSH keys, code signing keys, or the encrypted backups sitting in cold storage under a twenty year retention policy. A clean TLS result is one section of the levee. You will not get one alarm, you will get a dozen separate ones over a decade, and only if someone is walking the wall.

Two Things, Not a Programme

I am not going to hand you a migration plan, because you do not have the information to build one yet, and neither do I.

• Classify your data by confidentiality lifetime. Not by sensitivity, by duration. The trigger for post-quantum work is how many years something must stay secret, and that is a question your business can answer today without a single cryptographer in the room.
• Inventory first, and only inventory. Run the survey. Write down what negotiates what, and who controls each termination point. Resist the urge to turn it into a programme with a steering committee before you know the size of the problem.

That is the whole list. Crypto-agility in new designs and vendor questionnaires will come, and they will come better informed once you have the inventory. Everything else people will sell you on the back of that slide is a solution to a problem you have not measured yet.

The weather station will keep printing pressure fronts, and it is worth knowing what it can do and what it costs so you can give a straight answer when an exec asks. Just do not confuse knowing about it with having a decision to make.

How long does your longest-lived secret have to stay secret? And when did you last walk your own wall?