Fix a quantum-vulnerable TLS endpoint (hybrid key exchange)

If Vigil flagged an external endpoint as quantum-vulnerable, the fix is to enable hybrid key exchange (X25519MLKEM768) wherever TLS terminates. On Cloudflare it's already the default; if you control your own edge it's a config change; and if your host terminates TLS for you, you can't set it at all — this guide covers all three cases and how to verify the result.

What the finding means

A row like example.com:443 · External · X25519 · Vulnerable means the endpoint negotiated a purely classical key exchange. X25519, ECDH and RSA key agreement are all breakable by Shor's algorithm once a cryptographically-relevant quantum computer exists.

This is the one class of finding where the clock is already running. An adversary can record your encrypted traffic today and decrypt it years later when the hardware arrives — harvest-now, decrypt-later. Anything with a long confidentiality lifetime crossing that endpoint is already exposed, which is why Vigil ranks these first.

The fix: hybrid key exchange

The remedy is X25519MLKEM768 — a hybrid group that runs classical X25519 and NIST's ML-KEM (FIPS 203) together. It is safe against a quantum attacker (via ML-KEM) and against a flaw in ML-KEM (via X25519), which is why every major deployment starts hybrid rather than PQC-only.

Important: this is a setting on whatever terminates TLS, not on your application. Your app code doesn't choose the key exchange — your edge does.

Path A — Cloudflare (fastest)

Cloudflare terminates with X25519MLKEM768 by default for clients that support it, across plans including free. There is no toggle to hunt for — putting the hostname behind Cloudflare's proxy is the change.

Add the domain to Cloudflare and point its nameservers there (or add the record to an existing zone).
Set the hostname's DNS record to Proxied (the orange cloud). Traffic now terminates at Cloudflare's edge.
Set SSL/TLS → Overview → Full (strict) so the Cloudflare-to-origin leg stays encrypted and certificate-validated.
Verify with the command in the section below — don't take anyone's word for it, including ours.

Honest scope: this protects the browser-to-Cloudflare leg — the one exposed to mass interception on the open internet. The Cloudflare-to-origin leg remains classical unless your origin also supports hybrid. That's a large reduction in harvestable surface, not an elimination.

Path B — you control the edge

nginx / HAProxy — build against OpenSSL 3.5+ (ML-KEM is built in as of 3.5, no patching) and add X25519MLKEM768 to the configured groups.
Windows Server 2025 — supports hybrid key exchange natively.
Cloud load balancers — support is arriving unevenly across AWS, Azure and GCP. Check your provider's current docs rather than trusting a blog post, then verify with the command below.

Path C — your platform terminates TLS for you

This is the case most guides miss. If you run on a managed platform — Fly.io, Vercel, Render, Heroku, App Runner and similar — the platform's edge terminates TLS and you have no setting to change. Advice to "enable hybrid key exchange on your load balancer" simply doesn't apply: there's no load balancer you can reach.

Two real options: front the hostname with a PQ-capable CDN (Path A), or press your provider and track their roadmap. Verify rather than assume — some platforms have shipped support quietly, and others haven't shipped it despite it being asked for.

We hit exactly this dogfooding Vigil: our own app runs on a managed platform whose edge refuses X25519MLKEM768 today, so the only lever available was fronting it with a PQ-capable CDN.

Verify it actually worked

Requires OpenSSL 3.5 or newer (openssl version) — older builds don't know the group and will give you a false negative.

Force the hybrid group. If the endpoint supports it you'll see the group echoed back; if it doesn't, the handshake fails with an alert:

openssl s_client -connect example.com:443 -servername example.com -groups X25519MLKEM768 </dev/null 2>&1 | grep "Negotiated TLS1.3 group"
Supported → Negotiated TLS1.3 group: X25519MLKEM768
Not supported → tls alert handshake failure / SSL alert number 40

Re-run Vigil's sweep after the change and the row should flip from Vulnerable to Hybrid — that's your evidence the window is closed, recorded with a date.

What this does and doesn't fix

Fixes: the harvest-now-decrypt-later exposure on that endpoint's key exchange — the urgent part.
Doesn't fix: certificates. No public CA issues PQC certificates yet, so certificate signatures stay classical for now. That exposure is structural and not yet actionable — keep validity short and issuance automated so the eventual swap is a re-issue, not a project.
Doesn't fix: internal and long-lived traffic (backups, replication, internal service-to-service). Those are still harvestable and need the same treatment on their terminating service.
Client side: hybrid only engages for clients that support it. Current Chrome, Edge and Firefox do; older clients quietly fall back to classical, which is why hybrid is safe to enable.

Coverage modes & how your grade is calculated Connect AWS Connect Microsoft 365

Paliton Networks is a Cloudflare MSSP partner. If Vigil surfaced quantum-vulnerable endpoints across your estate and you'd rather not work through each edge yourself, we can scope and implement the mitigation — then re-scan so you have dated, verified evidence the exposure is closed.Talk to us