Post-Quantum Hosting: Is Your Host Already Behind on Security?
Your SSL certificate protects traffic today. It will not protect traffic in 2030. That gap is called post-quantum risk, and the hosting industry is split into two camps: providers already shipping quantum-resistant TLS, and providers who have not said a word about it.
This article explains what post-quantum cryptography means for a normal website owner, which providers are actually doing something, and whether you need to act this year or in three.
The short version
- Quantum computers will eventually break RSA and ECC, the algorithms behind every HTTPS session today.
- NIST finalized the first three post-quantum standards in August 2024. The clock started.
- Cloudflare, Google, Meta and AWS are already rolling out hybrid post-quantum TLS. Most shared hosts have not mentioned it.
- "Harvest now, decrypt later" attacks mean any encrypted traffic recorded today could be broken retroactively.
- Check if your CDN or host supports ML-KEM (formerly Kyber) in its TLS handshake. If it does not, you are relying on your upstream provider.
What post-quantum cryptography actually is
Every HTTPS connection negotiates a shared key using algorithms called RSA or elliptic-curve cryptography (ECC). These rely on math problems that classical computers cannot solve in any reasonable time. A sufficiently large quantum computer, running Shor's algorithm, could crack them in hours.
Post-quantum cryptography (PQC) replaces those algorithms with ones based on different math problems: lattices, hash trees, and error-correcting codes. These problems stay hard even for quantum computers, as far as current research can tell.
NIST published the first finalized standards in August 2024:
- ML-KEM (formerly Kyber) for key exchange.
- ML-DSA (formerly Dilithium) for digital signatures.
- SLH-DSA (formerly SPHINCS+) as a backup signature scheme.
That finalization is the signal every serious infrastructure team was waiting for. Cloudflare already serves ML-KEM by default on TLS 1.3 connections. Google Chrome enabled it. Meta described its internal migration in engineering posts. The transition is not theoretical anymore.
Why this matters for a normal website
Two arguments. One urgent, one medium-term.
1. Harvest now, decrypt later
State-level attackers and some criminal groups already record encrypted traffic. They cannot read it today. The bet is that in five to ten years they will. If your site transmits anything worth keeping confidential for a decade (medical data, legal documents, business strategy, personal messages), that traffic is at risk right now unless the TLS handshake already uses a post-quantum key exchange.
2. Compliance timelines are tightening
Google moved its internal PQC deadline up to 2029 after new research papers cut quantum hardware requirements. The EU and US governments have issued migration guidance with 2030 as the outer boundary for critical systems. By the time this filters down to "your hosting provider must prove PQC compliance" it will be 2027 or 2028. Waiting is fine. Waiting without a plan is not.
Who is actually doing it
This is where the industry splits. The providers below are grouped by what they have publicly committed to as of early 2026.
Already shipping hybrid post-quantum TLS
| Layer | Provider | Status |
|---|---|---|
| CDN / proxy | Cloudflare | X25519MLKEM768 enabled by default on TLS 1.3 |
| Cloud infrastructure | AWS | PQ-hybrid key exchange in KMS, ACM, Secrets Manager |
| Browser / application | Google Chrome, Firefox | ML-KEM client support shipped |
| Internal traffic | Meta | Deployed PQC across portions of internal traffic |
Silent so far
Most mainstream shared and WordPress hosts have not made any public statement about post-quantum migration. This does not mean they are doing nothing. It means the information is not available to you as a buyer, and when you ask support, the answer is usually "we will update when upstream providers do."
In practice, that is the honest answer. If your hosting provider uses Cloudflare in front of its network (which many do), you already get PQC on the edge, even if the origin connection is still classical. The critical question becomes: what CDN or proxy sits in front of your site?
How to check your own site in 60 seconds
Open a terminal and run:
curl -v --tls13-ciphers TLS_AES_128_GCM_SHA256 https://yourdomain.com 2>&1 | grep -i "quantum\|mlkem\|kyber"Or use the Cloudflare Research PQC test page, which inspects the key exchange your browser negotiated. If your browser is up to date and your site is behind Cloudflare, you will see X25519MLKEM768.
If the result is plain X25519 or ECDHE, your connection is classical. That is fine for most content. It is not fine for anything you would describe as "private for a decade."
Should a small site care in 2026?
Honestly, most small sites do not. A local bakery does not need post-quantum TLS. Neither does a photography portfolio or a WordPress blog about houseplants. The data transmitted is not valuable enough to harvest.
The sites that should move quickly:
- Anything handling medical, legal, or financial records.
- SaaS products that transmit customer data on behalf of enterprise clients.
- E-commerce stores with long-term customer relationships.
- Developer tools, API platforms, and anything under EU NIS2 or US CISA guidance.
What to do right now, in order
Step 1: Put a PQC-capable CDN in front of your site
The cheapest, fastest move is to route traffic through a CDN that already speaks ML-KEM. Cloudflare's free plan does this. Fastly is working on it. Bunny.net has not publicly shipped it yet.
This alone protects the public-facing leg of every connection. Visitors negotiate a post-quantum key exchange with the CDN edge. The edge-to-origin hop is classical, but it is much harder to intercept at scale and it is a short enough hop that "harvest and decrypt later" becomes impractical.
Step 2: Audit your backend services
Every API call your app makes (payment processors, email providers, databases, analytics) rides on TLS. Check whether those upstream services support hybrid key exchange. Stripe, AWS, and Google Cloud all do. Smaller services are a mixed bag.
Step 3: Pick a host that does not lock you in
When a provider needs to flip the PQC switch, they do it at the server level (nginx, OpenSSL, BoringSSL). Managed hosts handle this for you automatically. Unmanaged VPS users (Hetzner, DigitalOcean, Vultr) will need to wait for the OpenSSL 3.5+ rollout through their distro package manager. That is not a problem. Just something to know.
Step 4: Do not pay a premium for "quantum-safe" marketing
A handful of hosts have started using "quantum-ready" as a sales term. Ask what they actually implement. If the answer is "we use Cloudflare," that is honest. If the answer is vague, the premium is not real.
The providers we watch closely
Rather than recommend a single "post-quantum host" (that category does not really exist for small sites yet), here is how the providers in our comparison database stack up on the practical question: how painful is it to enable PQC once the industry finishes rolling it out?
| Provider | Category | PQC path |
|---|---|---|
| Kinsta | Managed WordPress | Runs on Google Cloud, Cloudflare Enterprise in front. Automatic rollout. |
| Cloudways | Managed cloud | Depends on chosen provider (DO, Vultr, Linode, AWS, GCP). |
| Hetzner | Unmanaged cloud VPS | You control the TLS stack. Update OpenSSL, restart nginx, done. |
| DigitalOcean | Unmanaged cloud | Same as Hetzner. Manual control. |
| Hostinger | Shared | Provider-controlled. Watch for announcements. |
| SiteGround | Shared / managed | Uses its own Google Cloud-backed edge. Should follow Google's timeline. |
| WP Engine | Managed WordPress | Runs on Google Cloud. Cloudflare on premium tiers. |
What will break when PQC goes mainstream
Two things, probably.
First, handshake sizes. Post-quantum key exchange messages are larger than ECDHE. ML-KEM-768 adds roughly 1.2 KB per handshake. This bumps the first-packet size past common MTU limits on some networks, which triggers fragmentation and occasional weird failures. Cloudflare has published data showing a small but measurable tail of failures on older routers. Expect minor connectivity quirks during the transition.
Second, certificate signatures. Once PQC signature algorithms (ML-DSA, SLH-DSA) start appearing in real certificates, certificate chains get significantly larger. This matters for latency-sensitive applications and constrained devices. Not a big deal for websites.
The honest conclusion
Post-quantum hosting is not a product category you shop for in 2026. It is a capability your underlying infrastructure either has or is about to have. If you run anything valuable, put Cloudflare (or an equivalent PQC-ready edge) in front of it today. That single change covers most of the risk at zero cost.
For everything else, pick a host that updates its TLS stack regularly and does not block you from controlling the cert chain. Every provider in our hosting comparison will get there. Some have already arrived.
The quantum Y2K is real. It is also not going to hit you at midnight on January 1, 2030. You have time. Use it to choose infrastructure that will not need replacing, not to panic-buy the first product with "quantum" in its name.
