Post-Quantum Encryption for Websites: What Small Businesses Need

Post-quantum encryption for websites sounds like a problem for banks and governments, but it is already protecting most visits to your site, whether or not you did anything. Modern browsers and large CDNs switched on a hybrid post-quantum key exchange during 2024 and 2025, and the UK's National Cyber Security Centre (NCSC) has set 2035 as the date for completing migration, the same year the US government targets for its own systems. This guide explains what the threat actually is, what has changed in TLS, what the NCSC timeline means, and the short list of things a small business should check.

What "harvest now, decrypt later" means

Today's HTTPS connections agree a secret key using elliptic-curve cryptography, usually X25519. A large enough quantum computer running Shor's algorithm could break that maths. No such machine exists yet, but encrypted traffic can be recorded today and stored.

That is the "harvest now, decrypt later" threat, which OpenSSH calls "store now, decrypt later": an attacker may "collect encrypted SSH sessions now and then decrypt them later" once a capable quantum computer arrives. The same logic applies to HTTPS traffic.

The risk is about confidentiality over time, not about your site being hacked tomorrow. It matters most for data that must stay secret for years: health records, legal files, financial details, personal data that would still be damaging in 2035. A café's menu page is not a target. A solicitor's client portal is more interesting.

Key exchange versus certificates

A TLS connection uses public-key cryptography for two different jobs, and post-quantum migration is happening at different speeds for each.

Key exchange is the urgent part, because recorded traffic can be attacked later. A forged certificate only helps an attacker at the moment of connection, so there is more time. The NCSC said in October 2026 that its post-quantum authentication recommendations for TLS will follow "in the coming months".

The new standards: ML-KEM and hybrid key exchange

In August 2024 the US National Institute of Standards and Technology (NIST) published FIPS 203, which standardises ML-KEM, a key-encapsulation mechanism designed to resist quantum attack. It comes in three sizes: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) cover digital signatures.

Rather than trust a new algorithm on its own, the web adopted a hybrid approach. The TLS group called X25519MLKEM768 combines the familiar X25519 exchange with ML-KEM-768. An attacker would have to break both to read the traffic, so even if a flaw were found in the newer algorithm, connections would be no weaker than they are today.

The NCSC's TLS guidance, updated on 15 October 2026 after the IETF published RFC 10024 on hybrid key agreement for TLS 1.3, recommends both hybrid and pure post-quantum options and notes that "the hybrid choices are the most widely deployed in commonly-used libraries".

Only TLS 1.3 gets post-quantum protection

The NCSC is blunt: "TLS 1.3 is the only version that supports PQC; earlier versions will not be upgraded." If your server or any device in front of it still negotiates TLS 1.2 with modern browsers, it cannot use post-quantum key exchange. Making sure TLS 1.3 is enabled is the single most useful thing you can check.

Where X25519MLKEM768 is already switched on

Cloudflare maintains a list of software that uses X25519MLKEM768 by default. As of October 2026 it includes:

How much traffic is already protected

Cloudflare reported on 29 September 2026 that about 70% of browser-generated traffic reaching its network uses hybrid ML-KEM. The other side of the connection lags: only "about 15% of origins that Cloudflare connects to use hybrid ML-KEM".

That gap is the key point for site owners. If you use a CDN, the visitor-to-CDN leg is probably already post-quantum protected. The CDN-to-your-server leg depends on your hosting.

SSH is ahead of the web

OpenSSH added post-quantum key exchange by default in version 9.0 (April 2022), introduced mlkem768x25519-sha256 in 9.9, and made it the default in 10.0 (April 2025). Since version 10.1, the client warns when a connection is "not using a post-quantum key exchange algorithm". If you or your developer see that warning when connecting to your server, the server's OpenSSH is too old or has post-quantum algorithms disabled in KexAlgorithms.

The NCSC migration timeline

The NCSC published its PQC migration timelines in March 2025. It sets three milestones:

1. By 2028: define migration goals, carry out a full discovery exercise of where you use cryptography, and build an initial plan.
2. By 2031: carry out early, highest-priority migration activities and refine the plan into a full roadmap.
3. By 2035: complete migration of all systems, services and products.

In its October 2026 TLS update, the NCSC added that for many organisations protecting data in transit is high priority, so "you should be aiming to make this move now".

For small businesses, the most important line is about commodity IT. The NCSC says SMEs "often use mainly commodity IT, such as standard browsers, operating systems and mobile devices", and that for them "PQC migration will be more straightforward and should happen seamlessly, as services are updated by their vendors". The exception is custom or specialised software, which still needs a plan on the same timetable.

What a small business actually needs to do

For a typical small business website, post-quantum readiness is mostly about staying current. Work through this list once, then make it part of your normal maintenance.

Checklist

• Confirm TLS 1.3 is enabled on your website and any CDN in front of it.
• Keep your hosting stack current. Ask your host which OpenSSL version and web server they run. OpenSSL 3.5 or later supports X25519MLKEM768 by default.
• Use a CDN that supports post-quantum key exchange if you handle sensitive data and cannot control your server.
• Update managed devices. Current versions of Chrome, Edge, Firefox and Safari already use hybrid key exchange.
• Update OpenSSH on any server you manage and act on post-quantum warnings.
• List bespoke software that does its own encryption: custom apps, payment integrations, old VPN appliances. Ask the suppliers about their PQC plans.
• Stop accepting very old protocols. Anything that still needs TLS 1.0 or 1.1 is a problem today, not in 2035.

Platform notes

Shopify, Wix and Squarespace. You do not manage TLS on these platforms, so there is nothing to configure. The provider controls the TLS stack.

WordPress on shared hosting or cPanel. The server's OpenSSL and web server version decide what is possible. Ask your host whether TLS 1.3 is on and when they plan to move to OpenSSL 3.5 or later. You cannot fix this with a plugin.

Cloudflare in front of your site. Visitor connections use hybrid key exchange automatically with supporting browsers. For the Cloudflare-to-origin leg, Cloudflare says that "when an origin supports both classical and post-quantum options, Cloudflare prefers post-quantum key agreement". Its September 2026 update added a TLS key exchange card under Analytics > HTTP Traffic, so you can see which key exchange groups your visitors use.

Your own Nginx or Caddy server. Use a current distribution package built against OpenSSL 3.5 or later, or Caddy 2.10 or later, and keep TLS 1.3 enabled:

server {
    listen 443 ssl;
    ssl_protocols TLSv1.2 TLSv1.3;
    # With OpenSSL 3.5+, X25519MLKEM768 is offered by default.
    # Only set ssl_ecdh_curve if you need to pin an explicit list:
    # ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
}

Leaving the default curve list in place is usually the safest choice, because a hand-written list can accidentally drop the hybrid group after future upgrades.

How to check whether your site uses post-quantum TLS

1. In Chrome or Edge: open your site, press F12 and open the Privacy and security panel (called Security in older versions), then look at the connection details. A post-quantum connection shows X25519MLKEM768 as the key exchange.
2. From a terminal with OpenSSL 3.5+:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "group"

If the handshake succeeds and reports the hybrid group, your server supports it. If it fails, the server does not.

3. Cloudflare users: check the TLS key exchange card under Analytics > HTTP Traffic.

While you are checking, run our SSL checker (free account required) to confirm your certificate is trusted, in date and matches your hostnames. A post-quantum key exchange is pointless if visitors are greeted by an expired certificate. Our guide to SSL certificate lifetime changes explains why renewals are becoming more frequent, and HSTS makes sure visitors always use HTTPS in the first place. To review TLS, headers and other basics together, run a free website audit.

Frequently asked questions

Do I need to buy a post-quantum SSL certificate?

No. Post-quantum protection on today's web comes from the key exchange, which your server software and CDN handle. Public post-quantum certificates are not yet in general use, and the NCSC has said its post-quantum authentication guidance for TLS is still to come.

Will post-quantum encryption slow my website down?

The hybrid key share is larger, which makes the first handshake message bigger, but the impact on page load is small. Cloudflare notes that if a server needs a different key share it can ask for a retry, which "adds one network round trip but does not break the connection".

What is X25519MLKEM768?

It is a hybrid TLS key exchange group that combines the classical X25519 algorithm with ML-KEM-768, the post-quantum algorithm standardised by NIST in FIPS 203. An attacker would need to break both to decrypt the traffic.

When do businesses have to be post-quantum ready?

In the UK, the NCSC's target is to complete migration by 2035, with discovery and planning by 2028 and high-priority work by 2031. For most SMEs using standard software and hosted platforms, the NCSC expects migration to happen through normal vendor updates. In the US, National Security Memorandum 10 sets 2035 as the goal for federal systems.

Does TLS 1.2 support post-quantum encryption?

No. The NCSC states that TLS 1.3 is the only version that supports post-quantum cryptography and earlier versions will not be upgraded, so organisations still relying on TLS 1.2 should move to TLS 1.3.

Related reading

• TLS 1.3 Explained: What Website Owners Need to Know: TLS 1.3 explained for website owners: what changed from TLS 1.2, the faster handshake, 0-RTT risks, disabling TLS 1.0 and 1.1, and how to check your server.

Sources

• NCSC: Timelines for migration to post-quantum cryptography
• NCSC: Post-quantum updates to our TLS guidance (15 October 2026)
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• Cloudflare docs: Post-quantum cryptography support
• Cloudflare docs: Post-quantum between Cloudflare and origin servers
• Cloudflare blog: Is your domain using post-quantum encryption? (29 September 2026)
• OpenSSH: Post-quantum cryptography