Quantum computers have been ten years away for about thirty years, and it is tempting to file the whole subject under things to worry about later. There is one specific reason not to, and it has nothing to do with when a useful quantum computer actually arrives.
Encrypted traffic can be captured now and stored. If the encryption protecting it is the kind a future quantum computer can break, then recording it today and decrypting it in 2035 works perfectly well. Nothing has to be broken now. Whoever is doing it only has to be patient and have somewhere to put the disks.
This is called harvest now, decrypt later, and it turns an abstract future problem into a present one, but only for data that still matters years from now. Payment card numbers largely do not, because the cards expire. Login credentials might, because people reuse passwords for a decade. Medical records, legal correspondence, contracts and anything with a personal history attached certainly do.
So the honest version of the question is not whether quantum computers will break encryption. It is whether anything sent through your website would still be sensitive in eight years. For a shop selling garden furniture, mostly no. For a counselling practice, a solicitor or anyone handling health information, mostly yes.
Two separate pieces of cryptography protect a web connection, and they are worth keeping apart because they are in very different states.
Key agreement is how your browser and the website agree on a secret key that nobody watching can work out. This is the one that matters for harvested traffic, because breaking it later unlocks the recording.
Authentication is how your browser confirms the site is really who it claims to be, using the certificate. Breaking that in 2035 lets somebody impersonate a site in 2035, which is a problem for 2035 and not a reason to re-record anything today.
Key agreement is where the industry has concentrated, and it is considerably further along than most coverage suggests.
The current answer is a hybrid. In TLS 1.3 the modern group is called X25519MLKEM768, and the important word is hybrid: it performs two key exchanges at once and combines the results. One is the classical elliptic curve exchange that has protected the web for years. The other is ML-KEM, a lattice-based algorithm standardised by NIST as FIPS 203 and designed to resist quantum attack.
The combined key is safe as long as at least one of the two halves holds. That is a deliberately conservative design. If a weakness turns up in the new algorithm, and new cryptography does sometimes disappoint, the classical half is still there. If quantum computers arrive, the lattice half is still there. Belt and braces, at almost no cost.
Roughly seventy per cent of browser traffic now negotiates it, which is a remarkable figure for something most site owners have never heard of.
Almost certainly nothing, and this is the part worth knowing.
There is no post-quantum switch to find. If your site is served over TLS 1.3, and the visitor’s browser supports the hybrid group, it is negotiated automatically. No certificate change, no configuration, no cost. Most modern browsers prefer it.
The one hard requirement is TLS 1.3. Post-quantum key agreement does not exist in TLS 1.2 or anything older. If a site is still capped at TLS 1.2, that is now a second reason to move, on top of all the existing ones.
Every website we host is served over TLS 1.3, so if your site is with us, visitors using a current browser are already getting post-quantum key agreement, and have been without anyone needing to ask for it. That is the useful thing about this particular piece of security work: it arrived quietly, through software everyone was already updating.
You do not have to take anyone’s word for this, including ours.
If you see X25519MLKEM768, that connection was protected with post-quantum key agreement. If you see X25519, P-256 or P-384, it was classical. Try it on your own site and on a few others. It is the quickest way to see how far along this actually is.
If your own site never shows the hybrid group, the first thing to check is that TLS 1.3 is enabled, because that is the usual reason.
A site can show a lot of classical connections without anything being wrong. Automated traffic, API clients, older libraries and monitoring tools often do not support TLS 1.3 at all, let alone the newer group, and on a small site they can account for a large share of the requests. What matters is what real browsers negotiate, which is why the check above tells you more than a percentage would.
There are two legs to every request that passes through a security network or content delivery network: the visitor to the network, and the network back to the web server. The first leg is the one that is largely solved. The second lags a long way behind, at something like fifteen per cent across the internet.
For most small business sites this is a much smaller exposure, because that leg runs between two data centres rather than across the public wifi in a coffee shop. It is worth knowing about rather than worrying about, and it is a fair question to put to your host rather than something to configure yourself.
Post-quantum certificates are the genuinely unfinished part. The signature algorithms exist, the certificates are substantially larger than the ones in use now, and the industry is still working out how to fit them into a handshake without making every connection slower. New certificate formats designed for the problem are expected in production during 2027.
None of this needs your attention. When it changes, it will change through your certificate provider, in the same way the move to shorter certificate lifetimes has.
NIST has said that RSA and elliptic curve cryptography should be deprecated by 2030, and regulators in several countries have lined up behind that date. Large infrastructure providers are aiming to be fully post-quantum a year or so ahead of it.
For a small business, 2030 is not a deadline you need a project for. It is a date by which the software you already use will have moved, provided you keep it current. The practical implications are unglamorous: stay on supported software, keep TLS 1.3 on, and do not leave a site running on a platform that has stopped receiving updates. The measures that actually matter have not changed because of any of this.
If you host with us and would like us to confirm exactly what your site is negotiating, open a ticket. It is a quick check and a more useful answer than a general reassurance.