Post-Quantum Cryptography and Your Website: What You Need to Know

Post Quantum Cryptography

Your HTTPS padlock is under pressure from a computer that doesn’t fully exist yet. That sounds like a problem for another decade. The thing is, some of the work to defend against it is already done, some is already scheduled, and one part needs your attention right now.

In this article
  1. What Is Post-Quantum Cryptography? (The Short Version)
  2. Why the Threat Isn’t Theoretical Anymore
  3. What’s Already Changed on Your Website (Without You Knowing)
  4. What’s Not Available Yet: Post-Quantum SSL Certificates
  5. What’s Still Coming: Shorter Certificate Lifetimes
  6. Does Your Hosting Provider Handle Any of This for You?
  7. What You Actually Need to Do Right Now
  8. Frequently Asked Questions

Post-quantum cryptography is moving fast in 2026, and the coverage of it ranges from “don’t worry, nothing has changed” to “your encryption is already broken.” Neither is accurate. This guide cuts through both and tells you exactly where things stand for ordinary website owners.

What Is Post-Quantum Cryptography? (The Short Version)

The HTTPS connection between your visitor’s browser and your server depends on encryption. Specifically, it depends on mathematical problems that are easy to set up but practically impossible to reverse. RSA and elliptic curve cryptography (ECC) are the two most common systems doing this work today.

The problem is that a sufficiently powerful quantum computer could solve those problems much faster than any classical machine. An algorithm called Shor’s algorithm can, in theory, break RSA and ECC encryption.

Post-quantum cryptography refers to a new generation of encryption algorithms designed to resist that attack, even from a quantum computer.

The US National Institute of Standards and Technology (NIST) finalised the first set of post-quantum standards in 2024. The one you’ll hear most often in a hosting or web context is ML-KEM, which protects the key exchange that happens at the start of every HTTPS connection.

Why the Threat Isn’t Theoretical Anymore

No publicly known quantum computer has broken cryptographically relevant encryption. Small-scale factoring has been demonstrated in lab conditions, and Google’s 2026 research reduced the estimated qubit requirement for cracking RSA-2048 by an order of magnitude. The hardware still doesn’t exist at that scale, at least not openly.

So why does this matter now?

Because of something called “harvest now, decrypt later.”

Nation-state actors and sophisticated threat groups are already intercepting and storing encrypted traffic. They can’t read it today. But the “harvest now, decrypt later” strategy only makes sense if you believe the capability is coming within a useful timeframe for the data you’re collecting. Governments clearly do believe that, which is why the NSA mandates all new national security systems be quantum-safe by January 2027.

Communications, financial records, login sessions, anything transmitted over HTTPS right now could become readable in the future. That changes the risk calculation. It’s not just a future problem. It’s a problem today for any data that will still be sensitive in a decade.

What’s Already Changed on Your Website (Without You Knowing)

Here’s the reassuring part. If your site is behind Cloudflare, hosted on a major managed platform, or running through a large CDN, your TLS handshakes may already use hybrid post-quantum key exchange.

Google Chrome, Firefox, Cloudflare, AWS, Microsoft Azure, and Google Cloud have all deployed ML-KEM in TLS 1.3 handshakes. This is the layer that protects the session key negotiation at the start of each HTTPS connection. Hybrid means the connection uses both the classical algorithm and the post-quantum one simultaneously. If the post-quantum component has any issue, the classical encryption still protects the session.

You didn’t have to configure anything for this. It happened at the infrastructure level.

You can check whether your hosting provider supports post-quantum TLS by looking at their security documentation or CDN configuration. If you use our SSL Checker tool, you can see your current certificate details, though TLS handshake configuration sits below the certificate level.

Worth knowing: if your site uses Cloudflare in front of it (free plan or otherwise), you’re almost certainly already covered at the handshake layer.

What’s Not Available Yet: Post-Quantum SSL Certificates

This is where it gets important to separate two different things, because a lot of coverage conflates them.

Post-quantum key exchange in TLS handshakes: already widely deployed (see above).

Post-quantum digital signatures in publicly trusted SSL certificates: not yet available to general website owners.

Post-quantum availability

Your SSL certificate contains a digital signature that proves it was issued by a trusted Certificate Authority. Currently, those signatures still use RSA or ECC. The CA/Browser Forum, the industry body that governs what Certificate Authorities are allowed to do, hasn’t yet updated its Baseline Requirements to permit post-quantum signature algorithms like ML-DSA in publicly trusted certificates.

So your certificate itself isn’t post-quantum. But for most website owners, the certificate signature is the lower priority of the two layers. The TLS handshake, which is what “harvest now, decrypt later” attacks actually target, is already being protected.

What’s Still Coming: Shorter Certificate Lifetimes

This is the part that does require your attention, and it’s already started.

The CA/Browser Forum approved a schedule that’s progressively reducing how long SSL certificates can be valid:

  • From March 15, 2026: maximum validity is 200 days (already in effect)
  • From March 15, 2027: maximum validity drops to 100 days
  • From March 15, 2029: maximum validity drops to 47 days

If you’re still renewing your SSL certificate manually once a year, that window is already gone. And it’s only going to get tighter.

Shorter Certificate Lifetimes

The reason this is accelerating is partly post-quantum preparation. Shorter certificate lifetimes mean that if a certificate is compromised or an algorithm becomes vulnerable, the exposure window is shorter.

The fix is automated certificate renewal via ACME (Automated Certificate Management Environment). Let’s Encrypt uses ACME by default. Most managed hosting providers handle this for you. If you’re on shared hosting, check whether your host auto-renews via cPanel’s AutoSSL or an equivalent.

Our earlier piece on the end of the one-year SSL certificate covers the timeline in full if you want more detail. And if your SSL certificate is already showing errors, our guide to why your SSL certificate isn’t working walks through the most common causes.

To understand the TLS layer that underpins all of this, our TLS glossary entry is a good starting point.

Does Your Hosting Provider Handle Any of This for You?

The short answer is: it depends on the type of hosting you’re on.

Managed WordPress hosting providers like SiteGround and Kinsta handle SSL renewal automatically and run their platforms behind hardened infrastructure, often with Cloudflare integration baked in. You don’t touch certificates. You don’t configure TLS. It’s done.

Shared hosting varies. Most major providers auto-renew Let’s Encrypt certificates, but you should verify this in your control panel rather than assume. If your host uses cPanel, look for AutoSSL in the SSL/TLS section.

VPS hosting puts more on you. If you’re self-managing Nginx or Apache on a VPS, you’re responsible for setting up Certbot or equivalent renewal automation. The 47-day endpoint in 2029 is not a future problem for your to-do list. It’s a project to plan for now.

A CDN also helps. If you want to understand what a CDN actually does for your site’s security and performance.

What You Actually Need to Do Right Now

Most website owners need to do two things, and only two.

1. Verify your SSL certificate renews automatically. Log into your hosting control panel and check when your certificate expires. If it’s within a few months and you’ve never set up renewal, sort it now. If you’re on a managed host, this is almost certainly already handled, but confirming takes 30 seconds.

2. Don’t replace your certificate for post-quantum reasons. Post-quantum signature algorithms aren’t yet permitted in publicly trusted certificates. There’s nothing to upgrade to yet. Any service selling you “post-quantum SSL certificates” for your public website right now is selling you something that isn’t standardised and won’t be trusted by browsers. Wait for the CA/Browser Forum to update the Baseline Requirements.

If you run infrastructure at scale, VPS or cloud hosting with TLS termination you manage yourself, check whether your server or load balancer supports ML-KEM in TLS 1.3. Google Cloud, for instance, is enabling post-quantum key exchange by default on load balancers from October 2026. If you’re on AWS or Azure, post-quantum key exchange is already available and enabled in their CDN and load balancer products.

Frequently Asked Questions

Do I need to replace my SSL certificate for post-quantum security? No, not yet. Post-quantum signature algorithms aren’t permitted in publicly trusted SSL certificates as of 2026. The CA/Browser Forum is working on this, but there’s no action to take on certificates specifically. Focus on automated renewal instead.

What is “harvest now, decrypt later”? It’s an attack strategy where encrypted traffic is captured and stored today, with the intention of decrypting it once quantum computers are powerful enough to break current encryption algorithms. It makes post-quantum preparation relevant now, even though quantum computers can’t yet break RSA or ECC at scale.

How do I know if my hosting provider already supports post-quantum TLS? Check their documentation for ML-KEM or X25519MLKEM768 in TLS 1.3. Cloudflare, AWS CloudFront, Google Cloud, and Azure all support it. If your site is behind any of these, you’re covered at the handshake layer. Most managed WordPress hosts are also protected through their CDN integrations.

When do SSL certificates need to be renewed more frequently? The CA/Browser Forum schedule already reduced maximum validity to 200 days from March 2026. It drops to 100 days in March 2027 and 47 days in March 2029. Set up automated renewal via ACME now if you haven’t already.

Does Cloudflare protect against quantum threats? For the TLS handshake layer, yes. Cloudflare has deployed ML-KEM in TLS 1.3 connections, which protects the key exchange against harvest-now-decrypt-later attacks. Your SSL certificate itself is separate and not yet post-quantum, but that’s a lower priority threat for most website owners.