From 20% to Full PQC-Readiness in 24 Hours: SSLBoard.com

We were only 20% PQC ready

When we ran our own domain through QCReady’s assessment, the result was 20% PQC readiness. That’s better than the 8.6% industry average among the top million websites, but not great for a platform that helps security teams monitor TLS certificates. We needed to fix it.

TL;DR: We moved SSLBoard from partial to full PQC readiness in a day by shifting TLS termination to Cloudflare Tunnel. A practical migration path exists without rebuilding everything in-house.

The problem: Kubernetes couldn’t do PQC easily

Our architecture was typical: Kubernetes cluster with ingress-nginx handling TLS termination, cert-manager handling certificates. Reliable setup, but it couldn’t support post-quantum cryptography without significant work. Getting to PQC readiness would have meant complex ingress-nginx upgrades with uncertain PQC support, cert-manager modifications for quantum-resistant algorithms, potential downtime during the transition, and no guarantee of browser compatibility.

The fix: Cloudflare Tunnel

We were already using Cloudflare for frontend hosting. It turned out their Tunnel technology could sidestep the entire PQC bottleneck.

Step 1: Deploy Cloudflare Tunnel

We replaced our traditional ingress controller with Cloudflare Tunnel as the Kubernetes ingress. The tunnel creates an encrypted outbound connection from our cluster to Cloudflare’s edge network.

Step 2: PQC comes free

Cloudflare’s edge already supports hybrid PQC key exchange using X25519MLKEM768 (the IETF-standardized combination of X25519 and ML-KEM-768). Once we switched, all client connections automatically negotiated quantum-resistant handshakes.

Step 3: End-to-end coverage

The tunnel itself uses PQC for cluster-to-Cloudflare communication, so the entire data path gets quantum protection.

Results

We re-ran the QCReady assessment right after switching. Before: 20% of our hosts were PQC ready. After: 100%. Chrome, Firefox, and other PQC-capable browsers now automatically negotiate hybrid key exchange with our domain.

Why the adoption gap matters

F5 research shows that 57.4% of browser-based transactions could support PQC, but actual website adoption is low. Only 8.6% of the top million websites support it. Healthcare sits at 8.5%, finance at 7.7%, government at 7.1%. The browser side is ready. The server side isn’t keeping up.

How hybrid key exchange works

Cloudflare uses the IETF-standardized X25519MLKEM768 hybrid key exchange, which combines X25519 elliptic curve Diffie-Hellman with ML-KEM-768 (Kyber) quantum-resistant key encapsulation. You get a 64-byte shared secret protected against both classical and quantum attacks.

Side benefits we didn’t expect

The architecture change also gave us zero inbound connections to our Kubernetes cluster, lower resource consumption without ingress controller overhead, automatic certificate management through Cloudflare, and requests served from 300+ edge locations worldwide.

If you want to do the same thing

Our experience suggests this doesn’t require a big infrastructure overhaul. If you’re running traditional ingress controllers:

Check your current readiness with QCReady’s free tool
Look at Cloudflare Tunnel as an ingress replacement
Test the switch in staging first
Monitor your PQC coverage after deploying

Harvest-now-decrypt-later attacks make this worth doing sooner rather than later. The standards are set, the tooling works, and in our case the whole migration took a day.

Check your PQC readiness at qcready.com.

SSLBoard is a certificate intelligence platform used by security teams to audit, monitor, and manage TLS certificates at scale. Learn more at sslboard.com