Post-quantum TLS already covers two-thirds of web traffic. Your signing keys are the migration nobody automated for you.

In 2026, three separate research groups (Google, IBM, and a Chinese team working with the Zuchongzhi 3.2 processor) confirmed a result quantum researchers had chased for close to thirty years: build a bigger quantum computer, and its error rate goes down, not up. That “below threshold” result is why fault-tolerant quantum computing went from “maybe never” to “a credible engineering roadmap” this year. It also triggered the same question that surfaces every couple of years: is post-quantum cryptography suddenly an emergency?

The honest answer is more useful than yes or no. Part of your stack has probably already migrated to post-quantum cryptography, without anyone on your team filing a ticket for it. Another part hasn't started, has a real deadline attached to it, and will not get fixed by a browser update. Telling those two apart is most of the work.

What actually changed in 2026

Error correction is the reason quantum computers have stayed impractical for so long. Qubits are noisy, and for years, adding more of them made the noise problem worse, not better. You needed thousands of physical qubits to protect a single reliable “logical” qubit, and the overhead kept growing as systems scaled up. The below-threshold result, first demonstrated by Google and extended by multiple groups since, showed the opposite: past a certain point, logical error rates fall exponentially as you add more physical qubits. That's the theoretical condition fault-tolerant quantum computing has needed since the 1990s.

In 2026, that theory turned into hardware. Vendors reported logical qubit counts in the 90 to 100 range, with error-decoding latency down to sub-microsecond levels, fast enough to correct errors as the computation runs rather than after the fact. China's Zuchongzhi 3.2, a 107-qubit processor, reportedly reached the same below-threshold regime using an all-microwave control scheme, showing the result wasn't a single-lab fluke. IBM's public roadmap now targets 200 logical qubits and 100 million reliable operations with its Starling system by 2029, and 2,000 logical qubits with a billion operations by 2033 with Blue Jay.

None of that means a quantum computer can break RSA-2048 today, or this year. Cryptographically relevant attacks on current public-key algorithms are widely estimated to need on the order of a million physical qubits arranged into thousands of error-corrected logical ones, running for hours. The 2026 milestone moved that outcome from “theoretically possible, practically unclear” to “on a roadmap with named hardware and target dates.” That's a meaningfully different kind of news than “quantum computers can now read your email,” even though it gets reported the same way.

Two different threats, two different clocks

The cryptography a quantum computer threatens splits into two categories that behave nothing like each other, and most of the panic conflates them.

The first is key exchange: the handshake that sets up a shared secret at the start of a TLS connection, a VPN tunnel, or an encrypted backup. If someone records that traffic today and a sufficiently capable quantum computer exists in ten or fifteen years, they can go back and derive the key, then decrypt whatever they captured. This is “harvest now, decrypt later,” and it's retroactive: the risk isn't about what happens to new connections after a quantum computer exists, it's about connections happening right now.

The second is digital signatures: the mechanism that proves a piece of software, a certificate, or a document was produced by whoever claims to have produced it. Signatures aren't retroactively broken the same way. A signature made today with RSA or ECDSA doesn't become fraudulent later just because the algorithm eventually gets broken; the risk runs forward, not backward. Once an attacker can break the signing algorithm, they can forge new signatures that claim to be old, or impersonate a signer going forward. For anything that needs to stay verifiable for a long time, such as a root certificate, a piece of firmware, or an archived legal record, that forward-looking risk still matters, but it's a different migration problem with a different urgency curve than harvest-now-decrypt-later.

Why post-quantum cryptography already showed up in your stack

The key-exchange side of this has moved faster than almost anyone building on top of it noticed. Chrome has defaulted to a hybrid key exchange, classical X25519 combined with the NIST-standardised ML-KEM-768, since Chrome 131 in November 2024. Cloudflare reported that the share of browser traffic on its network using post-quantum key agreement climbed from roughly 2% in early 2024 to more than two-thirds by June 2026. Most of that adoption happened through browser updates and CDN defaults, not through application code changes.

If your service sits behind a major CDN and terminates TLS through a recent library or load balancer, there's a good chance a meaningful share of your inbound traffic is already using hybrid post-quantum key exchange, and nobody had to ask for it. That's genuinely good news, and it's also why the panic headlines land oddly: the part of the problem people picture, someone intercepting encrypted traffic, is already substantially mitigated for anyone running current, standard infrastructure.

The caveats matter more than the headline number, though. Internal service-to-service TLS, self-managed VPN and IPsec tunnels, older embedded clients, and custom TLS stacks that pin specific cipher suites are not automatically covered. It's worth checking what a given endpoint actually negotiates rather than assuming:

# Check whether a server offers hybrid post-quantum key exchange
openssl s_client -connect example.com:443 -groups X25519MLKEM768 2>/dev/null \
  | grep -i "server temp key"

# A hybrid group name in the output (e.g. X25519MLKEM768) means the
# handshake negotiated post-quantum key exchange. Nothing in the output,
# or a connection error, usually means the server's OpenSSL build or
# load balancer configuration hasn't caught up yet.

For anything that returns nothing, the fix is usually a library and configuration update, not a rewrite. That's the easy half of this problem.

The half that didn't get fixed for you

Signatures and the public key infrastructure underneath them are the part nobody's CDN quietly upgraded. That includes code-signing keys, root and intermediate certificate authorities, firmware signed at manufacture time on devices that will still be running in a decade, and any archive of signed records with a long retention requirement.

This is a slower and more disruptive migration than the key-exchange story for a few concrete reasons. Certificate authorities and root trust hierarchies change carefully, because the failure mode of a botched signature migration is broken trust chains across an entire fleet, not a slightly slower handshake. Hardware security modules and cloud key management services, the systems that actually hold signing keys in regulated environments, are unevenly ready: some vendors support the new NIST-standardised signature algorithms in 2026, many don't yet, and switching HSM or KMS vendors is not a weekend project. And devices that embed a certificate at manufacture time, from point-of-sale terminals to industrial sensors, can't necessarily be patched at all; they get replaced on a hardware refresh cycle that may run into the 2030s.

None of that is reason to panic. It is reason to know, concretely, where your organisation signs things, and how long each of those signatures needs to remain trustworthy.

The deadlines that are already real

NIST finalised its first three post-quantum standards in August 2024: FIPS 203 for key encapsulation (ML-KEM), FIPS 204 for digital signatures (ML-DSA), and FIPS 205 for a hash-based signature backup (SLH-DSA). Those standards are what Chrome, Cloudflare, and everyone else building hybrid TLS have been implementing against.

The more concrete pressure comes from the NSA's Commercial National Security Algorithm Suite 2.0, which sets a timeline for US national security systems and their suppliers. Reported dates include exclusive use of approved post-quantum algorithms for new software and firmware signing from January 2027, legacy equipment transitioning off classical algorithms by 2030, operating systems and cloud services reaching exclusive post-quantum use by 2033, and full quantum resistance across national security systems by 2035.

Those dates formally apply to a narrow slice of organisations: government systems and the contractors who build for them. In practice, requirements like this rarely stay contained to their original scope. SOC 2 wasn't a legal requirement for most SaaS companies either, until enough enterprise customers made it a precondition of the sale. Post-quantum support in vendor security questionnaires is likely to follow the same path, well before any law forces the issue for a typical B2B SaaS company.

A practical first inventory

For a team that hasn't touched this yet, the useful starting point isn't “migrate everything to post-quantum algorithms.” It's an inventory, in this order:

• Find every place you terminate TLS and confirm what key exchange actually gets negotiated, rather than assuming your CDN or load balancer already handles it. The command above is one way to check.
• List everything that signs something on your behalf, including code-signing certificates, document or record signing, firmware, and internal certificate authorities, and note how long each signature needs to stay trustworthy. A code-signing cert that rotates every year is a very different problem from a record that has to hold up in an audit a decade from now.
• Ask your HSM, cloud KMS, or certificate authority for a written post-quantum signature support roadmap. A verbal “we're working on it” from a sales call isn't a roadmap.
• Check whether the cryptography libraries and language runtimes you actually use expose ML-KEM and ML-DSA yet. Support varies significantly across ecosystems in 2026, and some teams discover the gap only when they try to use it.
• For anything new you're building now, store algorithm choices as configuration rather than hardcoding a cipher suite. There will be a next cryptographic transition, and it should not require touching every call site again.

What this isn't

This isn't a reason to rip out RSA and ECC across your stack this quarter. No quantum computer that exists today, or that's credibly expected in the next few years, can break current public-key cryptography. The 2026 milestone is about the trajectory becoming credible, not about a working attack existing. Teams that respond to “below threshold” headlines by treating this as a today-emergency are solving the wrong problem at the wrong speed.

But “no urgency” and “nothing to do” are different claims, and the gap between them is exactly the signature and PKI migration described above. That one runs on a multi-year clock with dates already published, vendor roadmaps already lagging, and hardware that will still be in the field well past 2030. The organisations that end up scrambling in three or four years will mostly be the ones that treated the entire topic as either solved, because their browser traffic looked fine, or irrelevant, because no quantum computer can break anything today. Both of those are true about the part that already got fixed. Neither is true about the part that didn't.

The interesting part of 2026 wasn't that quantum computers suddenly threaten anyone's data. It's that the cryptographic transition underneath the internet split into two migrations running at completely different speeds — one that mostly happened without anyone deciding to do it, and one that's going to require someone to actually decide.