Is My TLS Quantum-Safe? How to Check in 5 Minutes

Published

The fastest way to know if your systems are protected against harvest-now-decrypt-later attacks: check whether your TLS connections negotiate X25519MLKEM768 (hybrid post-quantum key exchange). If they do, new sessions are quantum-safe. If they do not, your traffic can be recorded today and decrypted later.

This guide shows three ways to check, from a 10-second browser test to a full infrastructure scan.

Method 1: Browser DevTools (10 seconds)

The quickest test for a single website.

Chrome or Edge

  1. Open the website you want to test
  2. Open DevTools (F12 or Cmd+Opt+I)
  3. Go to the Security tab
  4. Click Overview
  5. Look at the Connection section

If you see X25519MLKEM768 in the key exchange field, the connection is using hybrid post-quantum key exchange. If you see X25519 or P-256 alone, it is classical only (not quantum-safe).

Firefox

  1. Open DevTools (F12)
  2. Go to the Network tab
  3. Click any HTTPS request (with the padlock icon)
  4. Go to the Security sub-tab
  5. Look at the Connection details

Same interpretation: X25519MLKEM768 = quantum-safe, X25519 alone = classical.

What you are actually seeing

The key exchange algorithm in DevTools tells you how the session key was established. If it is X25519MLKEM768, both classical X25519 and post-quantum ML-KEM-768 contributed to the shared secret. An adversary would need to break both to decrypt stored traffic later.

Important: This only shows the key exchange algorithm. The certificate signature (RSA, ECDSA) is still classical in almost all cases in 2026. This is expected. Key exchange protects against harvest attacks. Certificate signatures are a separate migration path (see our migration checklist).

Method 2: Cloudflare Radar (30 seconds)

Cloudflare provides a free online tool that checks whether a server supports PQ key exchange:

URL: radar.cloudflare.com/post-quantum

Enter any hostname. The tool initiates a TLS handshake and reports whether the server negotiated X25519MLKEM768. It also shows what percentage of global traffic to that host uses PQ key exchange.

Additionally, the same page has a browser check button that tells you whether your own browser supports X25519MLKEM768 when connecting to Cloudflare.

What Cloudflare Radar tells you

  • Whether the server supports PQ (does it accept X25519MLKEM768 when offered?)
  • Whether your browser supports PQ (does it offer X25519MLKEM768 in the ClientHello?)
  • What percentage of traffic to that domain uses PQ key exchange

If your server is behind Cloudflare, PQ key exchange is already enabled by default on the Cloudflare-to-client leg. The Cloudflare-to-origin leg may or may not use PQ depending on your origin configuration.

Method 3: Command-line tools (full diagnostic)

For infrastructure teams that need to test servers programmatically or at scale.

Apple macOS Tahoe (26+)

Starting with macOS Tahoe, Apple provides a built-in diagnostic:

nscurl --tls-diagnostics https://your-server.example.com

This reports the negotiated key exchange algorithm and whether X25519MLKEM768 was used.

OpenSSL 3.5+

openssl s_client -connect your-server.example.com:443 -groups X25519MLKEM768 2>/dev/null | grep -i "Server Temp Key\|Peer signing"

If the connection succeeds and reports X25519MLKEM768 in the temp key line, the server supports PQ key exchange. If it falls back to X25519 or P-256, it does not.

pqfetch (Rust tool)

A dedicated TLS post-quantum readiness scanner that checks one or many hosts:

# Install
cargo install pqfetch

# Check a single host
pqfetch your-server.example.com

# Check multiple hosts from a file
pqfetch -f hostlist.txt

Output is one line per host: quantum-safe or classical. Useful for scanning your entire infrastructure.

curl with verbose TLS output

curl -vvv https://your-server.example.com 2>&1 | grep -i "SSL connection\|Cipher\|group"

Look for X25519MLKEM768 in the TLS group negotiation. If present, PQ is active.

Method 4: Testing your own server’s support

If you want to confirm that your server offers PQ key exchange to clients:

Nginx (OpenSSL 3.5+)

Check your ssl_conf_command or ssl_ecdh_curve directive:

# In your server block or http block:
ssl_conf_command Groups X25519MLKEM768:x25519:secp256r1;

If X25519MLKEM768 is listed in the groups, your server offers PQ. If it is not listed (or you are using an older OpenSSL), you need to upgrade.

Quick test after configuration

# From another machine, test if your server accepts PQ:
openssl s_client -connect your-server.example.com:443 -groups X25519MLKEM768

If the handshake completes, your server supports PQ key exchange.

What the results mean

Result What it means Risk level
X25519MLKEM768 negotiated Connection is quantum-safe (hybrid) Protected against harvest attacks
X25519 only Classical key exchange, no PQ protection Vulnerable to harvest-now-decrypt-later
P-256 (ECDHE) Classical, older cipher suite Vulnerable, also potentially weaker classically
RSA key exchange Classical, no forward secrecy Vulnerable, should be disabled regardless of PQC

What if my connections are not quantum-safe?

The fix depends on which side is the limitation:

Client does not support PQ (old browser/OS):

  • Chrome/Edge: update to version 124+ (2024) for automatic X25519MLKEM768 support
  • Firefox: update to latest (PQ support shipped 2025)
  • Safari/iOS/macOS: update to iOS 26 / macOS Tahoe (2026) for X25519MLKEM768 in the ClientHello
  • Older clients: no fix, they will negotiate classical only

Server does not support PQ:

  • Cloudflare users: already enabled by default, no action needed
  • Self-hosted (Nginx/Apache): upgrade OpenSSL to 3.5+ and add X25519MLKEM768 to your groups configuration
  • AWS ALB/CloudFront: check current TLS policy support (evolving, check AWS docs for latest)
  • Managed services: contact your provider about PQ key exchange support

Both support PQ but negotiation fails:

  • Check for middleboxes (firewalls, IDS/IPS) that reject the larger ClientHello
  • Some corporate proxies strip unknown TLS extensions, breaking PQ negotiation
  • Test with openssl s_client directly to the server (bypassing middleboxes) to isolate the issue

The iOS 26 / macOS Tahoe change

Apple announced in 2026 that iOS 26, iPadOS 26, macOS Tahoe, and visionOS 26 will include X25519MLKEM768 in the supported_groups TLS extension by default. This means every Apple device on the latest OS will request PQ key exchange from every server it connects to.

Impact for server operators: If you have not enabled PQ support on your servers, Apple devices will still connect (they fall back to classical), but you will not be protecting those connections against harvest attacks. The Apple documentation recommends verifying your servers accept X25519MLKEM768 before the OS ships widely.

Automated monitoring

For ongoing visibility rather than one-time checks:

  • Certificate Transparency + TLS monitoring: tools like Keyfactor or Venafi can monitor negotiated cipher suites across your fleet
  • Custom: run pqfetch on a cron job against your server list, alert on any host that stops negotiating PQ
  • CDN dashboards: Cloudflare, Fastly, and AWS expose PQ negotiation rates in their analytics

FAQ

Does quantum-safe TLS key exchange mean my entire connection is quantum-safe?

It means the session key establishment is quantum-safe (harvest-now-decrypt-later is defeated for that session). The certificate signature is typically still classical (RSA or ECDSA) in 2026. Both matter for complete quantum safety, but key exchange is the more urgent fix because it directly prevents harvest attacks.

My browser says X25519 only, is that still safe today?

Yes, against classical attacks. X25519 is not broken by today’s computers. The risk is future quantum decryption of recorded traffic. If the data transmitted in that session will not be sensitive in 10 years, the urgency is lower. If it will be, you want PQ key exchange now.

Why does Cloudflare show PQ but my server does not?

If your site is behind Cloudflare, the client-to-Cloudflare leg uses PQ (Cloudflare enables it by default). The Cloudflare-to-your-origin leg may use classical only. The first leg is what protects against network-level harvest attacks, but the full path should ideally be PQ end-to-end.

Can I force PQ-only (disable classical fallback)?

Not recommended in 2026. Many clients still do not support X25519MLKEM768 (older browsers, IoT devices, corporate proxies). If you disable classical key exchange, those clients cannot connect at all. Keep both available, prefer PQ when both sides support it.

How do I check if my VPN is quantum-safe?

VPN PQ support depends on the VPN protocol and implementation. See our Best Post-Quantum VPNs 2026 guide for which providers and protocols support PQ key exchange today.

Related articles

Cloudflare Post-Quantum Setup: What Is Enabled and What You Still Need to Do

Cloudflare enables PQ key exchange by default for client-to-edge traffic. But origin connections need manual configuration. Here is the full picture.

OpenSSL Quantum-Safe Configuration: Enable PQ TLS on Your Server

Step-by-step guide to enabling post-quantum TLS key exchange on your server with OpenSSL 3.5+. Nginx and Apache configurations included.

NIST PQC Standards Explained: ML-KEM, ML-DSA, and SLH-DSA for Practitioners

The three finalized NIST post-quantum standards with parameter sets, key sizes, signature sizes, and when to use which. For security engineers, not academics.

What Is Post-Quantum Cryptography? A Practical Explanation for Security Engineers

Post-quantum cryptography replaces algorithms that quantum computers will break. What is actually changing, why now, and what harvest now decrypt later means.