Quantum computing is usually framed as a ticking clock for encryption: the world has to migrate to new cryptography before a machine exists that can break the old.

But for the web connections you use every day, that migration has already happened. We checked, and it had happened to 8 of the 10 sites we looked at — including this one, without anyone here deciding it.

Why anyone is migrating yet

No quantum computer today can break the key exchange that protects a web connection. The reason to move now is a problem with an unhelpfully memorable name: harvest now, decrypt later.

An adversary can record encrypted traffic now, store it, and wait for a machine that can recover the key later. That makes anything with a long secrecy requirement — health records, legal files, state communication — vulnerable today. The recording is happening now; the decryption is a future problem.

This is why the migration is urgent now. You cannot retroactively protect a conversation somebody already recorded.

What we measured

For each site we followed the redirect chain to the host a browser actually ends at, then asked that host two questions with a forced key exchange: will you complete a handshake if the only thing on offer is a post-quantum key exchange, and will you complete one if the only thing on offer is the classical alternative?

That is a yes-or-no test, which matters — our first attempt was not.

A chart of post-quantum key exchange support across ten sites, measured by forcing a single key-exchange group and seeing whether the handshake completes. Eight of the ten support hybrid post-quantum key exchange, all of them negotiating X25519MLKEM768: recatools.com, Cloudflare, Google, the BBC, Wikipedia, gov.sg, Amazon and OpenAI. One, github.com, completes a classical handshake but rejects the post-quantum one. One, www.dbs.com.sg, rejects TLS 1.3 entirely with a protocol version alert and serves TLS 1.2, and post-quantum key exchange exists only in TLS 1.3. Seven of the ten sites redirect to a different host from the apex domain, which is the host that was actually measured.
Green is already migrated. The measured host is the one a browser lands on, which for seven of the ten is not the address you type.

When we offered only a post-quantum key exchange, 8 of 10 sites completed a handshake. All eight negotiated the same hybrid algorithm, X25519MLKEM768.

What that name means

It is two key exchanges bolted together. X25519 is the classical elliptic-curve exchange that has protected connections for years. ML-KEM is the lattice-based algorithm standardised for the quantum era. The connection derives its key from both.

The pairing fails safe. If a flaw is ever found in the new lattice algorithm, the classical half still protects the connection. If a quantum computer arrives, the classical half is worthless and the lattice half carries it.

Nobody is betting the internet on the new algorithm alone, and that caution is the reason this could be deployed quietly rather than as an event.

The two that had not

github.com completed a classical handshake and refused the post-quantum one. That is the ordinary state of a great deal of the internet and it is not a failing; it is simply not done yet.

The other holdout was different. www.dbs.com.sg rejected TLS 1.3 outright, with a protocol-version alert, and fell back to TLS 1.2. Post-quantum key exchange is a TLS 1.3 feature, so the site is a protocol version behind the entire question.

That is a configuration fact, not a judgement. TLS 1.2 is not broken and is still widely deployed, but it has no post-quantum option — a relevant detail for a bank.

Our own row, which we did not earn

This site is in the green column, and we would like to be clear that nobody here chose it. Our content delivery network enabled hybrid post-quantum key exchange for the zones it fronts, and we found out by measuring our own connection for this guide.

That is how most of the eight got there. A few large infrastructure providers enabled it by default, pulling much of the web along with them.

So what should you do? If your website sits behind a major provider, the answer is probably nothing, and then verify. For anything else, the question is who operates your TLS termination and what they have turned on.

Where this actually leaves you

For most web browsing the migration is not a future event; it is here. 8 of the 10 sites we measured already negotiate the same hybrid post-quantum key exchange, switched on quietly by their infrastructure providers rather than by the sites themselves. That is not the whole story, though. It covers live key exchange only, and stored data, signatures and certificates are separate problems on their own timelines. Check your own connections rather than assuming, because the answer differs by host and not by brand — one site here still speaks only TLS 1.2, where post-quantum is not even an option. And if you hold anything that must stay secret for a decade, treat harvest-now-decrypt-later as a present-tense problem: the recording is happening now, whatever the decryption timeline turns out to be.

Checking your own connection

The script is committed with this guide and needs only a current OpenSSL. Our DNS lookup and IP lookup show where a host actually resolves and terminates, which is the first thing to establish before testing it. For the surrounding cryptography, which hash for what covers the algorithms that are not affected by any of this, what the padlock actually proves covers the certificate rather than the key exchange, and what public Wi-Fi still exposes measured what remains visible on a shared network no matter which key exchange you use.

Sources
  • Every result comes from a script committed alongside this guide: follow the redirect chain to the host a browser ends at, then complete a TLS 1.3 handshake with a single forced key-exchange group. Completing one when only X25519MLKEM768 is offered is proof of hybrid post-quantum support.
  • ⚠️ A CONTROL GATES THE RUN. If a host known to offer the hybrid fails the post-quantum probe, the local OpenSSL lacks the group and every negative would describe OUR CLIENT rather than the servers. The script exits rather than publish in that state.
  • ⚠️ THE FIRST INSTRUMENT WAS BROKEN and reported the wrong answer. Reading the negotiated-group line could not distinguish a classical exchange from a line OpenSSL did not print: three hosts returned nothing on a completely successful handshake. It put the total at 6 of 10 rather than 8.
  • ⚠️ THE APEX IS NOT THE SITE, and this nearly produced a false claim about a government portal. gov.sg speaks only TLS 1.2, while www.gov.sg — where the chain ends — negotiates the hybrid. Seven of the ten sites here resolve to a different host from the address typed.
  • ⚠️ FAILING BOTH PROBES IS NOT "CLASSICAL". One host turned out to reject TLS 1.3 entirely, which is a different and more informative state, because post-quantum key exchange exists only in TLS 1.3.
  • ⚠️ THIS MEASURES THE KEY EXCHANGE ONLY. Certificates, signatures and stored data are separate migrations with their own timelines, and nothing here should be read as a site being "quantum-safe" overall.
  • ⚠️ NOTHING WAS ATTACKED. These are ordinary TLS handshakes, the same ones a browser makes. No traffic was intercepted and no weakness was exercised.
  • ⚠️ TEN SITES ON ONE DAY, FROM ONE CLIENT. Support changes as providers roll out, and a result here is what a current OpenSSL could negotiate at that moment rather than a permanent property of any site.

This describes what key exchange ten public sites negotiated on one day. It is not a security assessment of any organisation, not a claim that any site is or is not "quantum-safe", and not advice about protecting a specific system.