Free guide · Francisco Arrieta · 6 min

Check whether your site's encryption is ready for quantum

Read the key exchange your own site negotiates, and turn on the post-quantum one if your host already offers it

Your site is probably already using post-quantum encryption, and you didn’t do anything to make that happen. It’s worth knowing, because the part that’s still yours to check isn’t the part people assume.

The story people have heard is that quantum computers will break encryption, and somebody will have to do something about it eventually. The part that doesn’t get through is that the something has largely been done, quietly, in the last two years, by browsers and CDNs, on your behalf.

Chrome has negotiated a post-quantum key exchange by default since version 131 in November 2024. Cloudflare turned it on across its network. If your site sits behind a big CDN and your visitors use a current browser, the connection between them is already protected against the thing everyone is worried about.

The worry, specifically, is that somebody records your encrypted traffic today and keeps it. They can’t read it now. If a large quantum computer arrives in fifteen years, the key exchange from today is what breaks, and the recording becomes readable. That’s why this got fixed early. It’s the one part of the problem where waiting doesn’t work.

So the useful question isn’t whether to do something. It’s which half you’re looking at.

Before you start

You need Chrome and a site you own. Five minutes.

One word, once. A key exchange is the opening handshake where two machines agree on a secret to encrypt the rest of the conversation. It’s the part a quantum computer would attack, which is why it’s the part that got upgraded first.

Step 1

Read the connection on your own site

Open your site in Chrome, press F12 for DevTools, and go to the Security tab.

Click your site under Main origin, and read the Connection line. You’re looking for something like:

protocol: TLS 1.3, key exchange group: X25519MLKEM768, cipher: AES_256_GCM

X25519MLKEM768 is the answer you want. It’s a hybrid: X25519 is the classical key exchange that’s been in use for years, and MLKEM768 is the post-quantum one NIST standardized. Both run, and an attacker has to break both.

If the line reads key exchange group: X25519 on its own, you’re on the classical one.

Step 2

Prove you’re reading it correctly

Don’t trust a field you’ve only seen say the thing you hoped for. Go and find the other value.

Open a few other sites in the same DevTools panel until one shows plain X25519. Smaller sites, self-hosted things, older infrastructure. They’re not hard to find.

Seeing both values with your own eyes is what turns this from a checkbox into a check. Until you’ve seen the panel display a negative, you don’t actually know it would.

Step 3

Know what the hybrid buys you, and what it costs

Hybrid is the important design choice here, and it’s why this could ship early without a fight.

ML-KEM is new. New cryptography is sometimes broken by ordinary mathematicians long before any quantum computer shows up. Pairing it with X25519 means that if ML-KEM turns out to be weak, you’re no worse off than you were, because the classical half still has to be broken too. You’re adding a lock, not swapping one.

The cost is a slightly larger handshake. That’s it. Nothing about this needs a decision from you, which is exactly why it got turned on without asking.

Step 4

Check the half your visitors can’t see

What you read in step 1 is the connection from a browser to your CDN’s edge. There’s a second leg, from that edge back to your actual server, and it’s a separate connection with separate encryption.

For a long time this was the half you had to opt into. That’s changed. Cloudflare’s current documentation says automatic key exchange is on for all existing zones and on by default for new ones, and the old opt-in API for it is now a no-op that changes nothing.

So if you’re behind Cloudflare, both legs are handled. Worth confirming rather than assuming, because if you set something here in 2023, what you set is no longer what’s doing the work.

Step 5

Test your origin directly, if you run one

If you run your own server behind the CDN, you can ask it what it supports:

bssl client -connect yourserver.example.com:443 -curves X25519MLKEM768

That’s BoringSSL’s client, which you’d need to install. Most people won’t, and most people don’t need to. It’s the check for someone who manages the origin and wants to know rather than infer.

If your origin doesn’t support the hybrid, nothing breaks. The server asks for a different key agreement, the handshake retries once, and the connection completes with one extra round trip. Slightly slower, not broken.

Step 6

Know what this doesn’t cover

Key exchange isn’t the whole of TLS, and the other half hasn’t moved yet.

Your certificate, the thing that proves your site is your site, still uses classical signatures. Those are also breakable by a large quantum computer, and they’re being worked on separately and more slowly.

The reason for the different urgency is worth understanding. A recorded key exchange can be attacked years later, so the clock started already. A signature only has to hold while it’s being checked, so a certificate that expires in ninety days can’t be forged retroactively by a machine that doesn’t exist yet. Same threat, very different deadline.

A boundary worth knowing about

Everything above is about traffic in motion, between two machines, for the seconds it’s moving.

It says nothing about the data sitting in your database, in your backups, or in a file on somebody’s laptop. Those are protected by different mechanisms with different timelines, and a green line in DevTools is not a statement about any of them.

The other edge is that you’re reading one visitor’s connection, yours. Someone on an older browser gets the classical exchange from the same server, and their traffic is the recordable kind. You can’t see that from your own DevTools panel, and you can’t fix it from your end either.

If you have staff

Nobody needs to action this. That’s the useful thing to communicate, because “quantum breaks encryption” generates more anxious meetings than work. For traffic in motion, on modern infrastructure, it’s handled.

What is worth a calendar entry is the certificate side, because that one is still moving. Someone should check where your CA stands on post-quantum signatures once a year, and that is genuinely the whole task.

The short version

  1. Chrome, F12, Security tab, click your site under Main origin, read the Connection line
  2. X25519MLKEM768 is hybrid post-quantum. Plain X25519 is classical
  3. Find a site that shows plain X25519, so you know the field can say no
  4. Behind Cloudflare, the edge-to-origin leg is automatic now, and the old opt-in API does nothing
  5. Running your own origin: bssl client -connect host:443 -curves X25519MLKEM768
  6. Certificates are still classical, and that’s a slower problem on purpose

Sources

Written August 2026. Browser and CDN behavior checked against the CheckPQC and Cloudflare documentation on 23 August 2026.

Prints to PDF from your browser — colours and all.