Over Half of Domains Support PQC, But Only 8% Are Truly Quantum-Safe

5 May 2026 5 min read

Since launching our free PQC Domain Checker in late 2025, we’ve analyzed thousands of unique domains across industries, geographies, and company sizes. The results tell a story that should concern every CISO and security engineer: PQC adoption is accelerating, but it’s dangerously incomplete.

Here are the numbers:

  • ~54% of domains we’ve checked negotiate Post-Quantum Cryptography (via X25519MLKEM768)
  • But only ~8% are fully quantum-safe — meaning PQC is active and older TLS versions are disabled
  • The remaining ~46% that support PQC still expose TLS 1.2, TLS 1.1, or even TLS 1.0, leaving the door wide open for protocol downgrade attacks

The takeaway is uncomfortable: deploying PQC without disabling legacy TLS is security theater.

What Is a Downgrade Attack?

A TLS downgrade attack forces a connection to fall back to an older, weaker protocol version (even when both the client and server support a stronger one).

Here’s how it works against a domain that supports PQC but also allows TLS 1.2:

  1. A man-in-the-middle intercepts the TLS handshake
  2. The attacker modifies or blocks the TLS 1.3 ClientHello
  3. The server falls back to TLS 1.2, which uses classical key exchange (ECDHE, RSA)
  4. The session is now vulnerable to quantum decryption AND the PQC protection is entirely bypassed

This is not theoretical. Downgrade attacks have been exploited in the wild for over a decade (POODLE, FREAK, Logjam). Adding PQC to your server while still accepting TLS 1.2 connections is like installing a vault door but leaving the window open.

The Data: Who’s Vulnerable?

Our checker doesn’t stop at detecting PQC, it also probes for older TLS version support and flags the downgrade risk explicitly.

Among the domains that do support PQC, we found that the overwhelming majority still allow older protocols. This includes some of the largest properties on the internet:

Domain PQC Fully Quantum-Safe
google.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
apple.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
microsoft.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
amazon.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
cloudflare.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
github.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
linkedin.com ✅ X25519MLKEM768 ⚠️ Downgrade risk
signal.org ✅ X25519MLKEM768 ⚠️ Downgrade risk

These organizations have invested in deploying ML-KEM, so they are ahead of most of the industry. But by continuing to serve TLS 1.2, they leave a viable quantum-vulnerable path that an adversary (or a future quantum computer paired with a recorded handshake) can exploit.

Why Does TLS 1.2 Still Exist?

The answer is backwards compatibility. A significant portion of the internet’s client population (older browsers, embedded devices, legacy enterprise systems, IoT hardware) cannot negotiate TLS 1.3. Disabling TLS 1.2 today would cut off these clients.

For most consumer-facing services, this trade-off makes practical sense. But it comes at a cryptographic cost: any data exchanged over a downgraded connection is harvestable.

For organizations handling sensitive data (financial services, healthcare, government, defense, intellectual property) this trade-off is increasingly unjustifiable as the quantum threat approaches.

The 8%: What Are They Doing Right?

The domains that achieve full quantum-safety share a common characteristic: they only serve TLS 1.3. No fallback. No compatibility mode.

This is a deliberate security posture. These domains have decided that protecting against quantum-capable adversaries outweighs serving legacy clients. In most cases, these are security-focused services, newer infrastructure, or internal-facing systems where client control is possible.

If your threat model includes nation-state adversaries or long-lived data sensitivity, this is the standard you should target.

What This Means for Your Organization

If You Haven’t Deployed PQC Yet

You’re in the 46% of domains we checked that still rely entirely on classical cryptography. Your data is being harvested today for decryption later.

Check your domain and begin planning your PQC migration.

If You’ve Deployed PQC but Still Allow TLS 1.2

You’ve taken an important first step, but you haven’t finished. Your PQC deployment protects willing clients, but a sophisticated adversary can bypass it entirely via downgrade. Consider:

  • Auditing which clients actually negotiate TLS 1.2 (you may find it’s a negligible percentage)
  • Setting a deprecation timeline for TLS 1.2 on sensitive endpoints
  • Segmenting high-security services onto TLS 1.3-only infrastructure
  • Monitoring for downgrade attempts in your TLS logs

If You’re Fully Quantum-Safe

You’re in the top 8%. Maintain vigilance: PQC standards continue to evolve, and cryptographic agility ensures you can adapt as algorithms are updated.

The Industry Needs to Move Faster

The gap between “PQC deployed” and “fully quantum-safe” is a false sense of security at scale. Organizations are checking the PQC box without addressing the downgrade vector that renders it bypassable.

At QuReady, we believe transparency drives progress. That’s why we built the PQC Domain Checker and why we’re publishing this data.

The quantum threat isn’t abstract, it’s a countdown, and half-measures won’t survive it.


Check your domain’s quantum safety now at quready.com/check, and contact us if you need help closing the gap between partial PQC deployment and true quantum readiness.

Share: