Quantum computing in cybersecurity: the threat to encryption and what to do

Why quantum computers threaten today's encryption

Most secure connections use two kinds of cryptography. Public-key (asymmetric) algorithms let two parties who have never met agree on a secret key and prove who they are: RSA, Diffie-Hellman, elliptic-curve Diffie-Hellman (ECDH, including X25519) and signature schemes such as ECDSA and EdDSA. Symmetric algorithms such as AES then encrypt the data itself with the agreed key, and hash functions such as SHA-256 protect its integrity.

In 1994 Peter Shor described quantum algorithms that factor integers and compute discrete logarithms in a number of steps polynomial in the size of the input. RSA depends on factoring being hard; Diffie-Hellman and every elliptic-curve scheme depend on discrete logarithms being hard. On a large enough quantum computer, Shor's algorithm breaks them all, which is why NIST's draft transition plan lists RSA, ECDSA, EdDSA and the Diffie-Hellman and elliptic-curve key-establishment schemes as vulnerable to Shor's algorithm.

Symmetric cryptography faces a much weaker attack. Grover's algorithm, published in 1996, searches N possibilities in about the square root of N steps: a quadratic speedup, not an exponential one. NIST's draft plan says its symmetric standards, hash functions and block ciphers included, are significantly less vulnerable to known quantum attacks, that approved primitives with at least 128 bits of classical security are believed to meet its lowest post-quantum security category, and that it does not expect to transition away from them. The NSA is more conservative for national security systems: CNSA 2.0 requires AES with 256-bit keys, SHA-384 or SHA-512, ML-KEM-1024 and ML-DSA-87, with LMS or XMSS allowed for signing firmware and software.

A safe cipher does not make a session safe. The AES key for a connection is agreed with public-key cryptography when the connection starts, so whoever breaks that key agreement can decrypt everything that follows. The OpenSSH developers put it bluntly: the privacy of a whole SSH session depends on its key agreement, and the same holds for TLS and IPsec.

How close is a quantum computer that can break RSA?

No quantum computer can break the RSA or elliptic-curve keys used in practice today. The machine that could is called a cryptographically relevant quantum computer (CRQC). NIST describes it as a machine that may be years or decades away. What has changed is the estimate of how big it must be, and it has fallen sharply:

Gidney's 2025 estimate keeps the hardware assumptions of the 2019 one (a 0.1% gate error rate and a one-microsecond error-correction cycle); the gain came from better algorithms and error-correction techniques. Google's figure is about a 20-fold reduction in physical qubits, from circuits that need fewer than 1,200 logical qubits and 90 million Toffoli gates. Google did not publish the circuits: it released a zero-knowledge proof that lets others check the claim without learning the attack. The neutral-atom paper combines reconfigurable atomic qubits with high-rate error-correcting codes, and notes that trapping arrays of more than 6,000 highly coherent qubits have already been demonstrated. Error correction, which builds one reliable logical qubit out of many noisy physical ones, is explained in our guide to quantum circuit design.

For scale, Google's Willow chip, announced in December 2024, has 105 qubits. These papers are resource estimates, not attacks, and in late 2025 Cloudflare summed up the hardware as not yet good enough to crack real-world keys. The estimates still moved plans. In March 2026 Google set 2029 as the deadline for its own migration and put authentication first, and in April 2026 Cloudflare moved its target for full post-quantum security to 2029, citing the Google and neutral-atom results. The real breakthrough, then, is not that encryption has been broken; it is that the estimated cost of breaking it keeps dropping while the replacements are ready.

Harvest now, decrypt later: why the deadline comes before the machine

An attacker does not need a quantum computer today to profit from one later. In a harvest now, decrypt later attack (OpenSSH calls it store now, decrypt later), an adversary records encrypted traffic or copies encrypted files today and keeps them until a CRQC can recover the keys. It is passive eavesdropping with a long wait, and nothing on your side shows that it happened. The only recorded traffic that stays sealed is traffic whose key exchange was already post-quantum on the day it was captured.

NIST's draft plan turns this into arithmetic it calls Mosca's theorem: if data must stay secret for X years and migrating takes Y years, you must start before X plus Y exceeds Z, the years until a CRQC exists. Government secrets and medical records, NIST's own examples, have a large X, as does anything your contracts or regulations require you to keep confidential for a decade or more. NIST also notes that moving from a new algorithm standard to full integration has historically taken 10 to 20 years, which is a large Y.

The attack works against confidentiality only. Apple, OpenSSH and Signal all point out that signatures cannot be broken after the fact: to impersonate a server or forge a login, the attacker needs the quantum computer at the time of the connection. That is why the first wave of deployment protected key exchange. The 2026 estimates changed the emphasis, not the logic: signatures must be replaced before a CRQC exists, and because certificate hierarchies, firmware signing and hardware roots of trust take years to replace, Google and Cloudflare now treat authentication as the priority for their own systems.

The NIST post-quantum standards: ML-KEM, ML-DSA and SLH-DSA

On August 13, 2024, NIST published its first three post-quantum standards, the result of an eight-year process that started with 82 candidate algorithms from 25 countries:

• FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber): the primary standard for establishing shared keys.
• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium): the primary signature standard.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+): a backup signature scheme built on hash functions, a different kind of mathematics from ML-DSA.

NIST told administrators to start integrating them immediately rather than wait for later standards. Two more are coming. In March 2025 NIST selected HQC, a key-encapsulation mechanism based on error-correcting codes, as a backup for ML-KEM, with a draft planned about a year later and a final standard expected in 2027. The same announcement said a draft FIPS 206 for FN-DSA, the signature scheme derived from Falcon, would be released shortly. As of September 2026, NIST's project page, last updated in August 2026, still describes the Falcon and HQC standardization as underway. ML-KEM, ML-DSA and SLH-DSA are the standards to deploy.

The new algorithms are larger than the ones they replace, which matters on the wire:

Sizes are from RFC 10024 for the key exchanges, RFC 8032 for Ed25519, and FIPS 204 and FIPS 205 for the post-quantum signatures.

Why deployments are hybrid

New algorithms get broken. During NIST's process, one candidate turned out to be attackable by a classical computer, so most deployments combine a post-quantum algorithm with a classical one and derive the session key from both secrets; an attacker has to break both. NIST's draft plan allows this and states the goal: derived keys remain secure if at least one component is secure. For TLS 1.3, RFC 10024, published on the IETF Standards Track in August 2026, defines three hybrids: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. X25519MLKEM768 is the one browsers use. Its client key share is 1,216 bytes (1,184 for ML-KEM plus 32 for X25519) and the server's reply is 1,120.

Quantum key distribution is not the alternative

Quantum key distribution (QKD) uses quantum physics and dedicated hardware to share keys. It does not authenticate the parties, so it still depends on other cryptography. The UK NCSC will not support QKD for government or military use and names post-quantum cryptography as the best mitigation, and the NSA does not recommend QKD for national security systems unless its limitations are overcome.

Post-quantum deadlines: NIST, NSA CNSA 2.0, the UK NCSC and others

Governments have converged on 2030 to 2035. As of September 2026:

Industry is moving faster than regulators: Google and Cloudflare both target 2029 for their own systems. Two government actions reach private companies directly. If you sell to US federal agencies, the executive order's contractor rule applies to you by 2030. And in January 2026 CISA published the product categories in which post-quantum products are widely available (cloud platform and infrastructure services, chat and messaging, web browsers and servers, full-disk encryption) and advised organizations to buy only PQC-capable products in them.

What is already post-quantum in 2026

For key exchange, most of the client side is done. Signatures are not.

The effect shows up in traffic. In April 2026 Cloudflare reported that over 65% of human traffic to its network was post-quantum encrypted. The server side lags: in September 2026 Cloudflare reported that 12.8% of the origin servers it scans supported post-quantum key exchange, up from 0.5% in 2023. Browsers are ready; many web servers, load balancers and appliances are not, and those are the part you own.

Post-quantum signatures are the unfinished half. CISA's January 2026 list notes that even its widely available categories have mostly implemented PQC for key exchange rather than for signatures and authentication, and it lists hardware security modules, certificate authorities, PKI management software, network hardware and operating systems as still transitioning.

How to plan a post-quantum migration

The joint CISA, NSA and NIST factsheet and the NCSC's migration guidance describe the same sequence. For a typical organization:

1. Give the migration an owner and a scope.
2. Build a cryptographic inventory.
3. Rank systems by how long their secrets must last.
4. Ask vendors for their post-quantum roadmaps.
5. Turn on and test hybrid key exchange.
6. Plan certificates, PKI and HSMs.
7. Build crypto agility, then switch the old algorithms off.

Give the migration an owner and a scope

CISA recommends a project team that plans and scopes the migration, with cybersecurity and privacy risk managers who can decide what matters most, and IT and OT procurement people who deal with suppliers. The NCSC's first milestone is to define your migration goals. The US executive order requires each federal agency to name a PQC migration lead who owns the cryptographic inventory and a prioritized plan; the same role works in a company.

Build a cryptographic inventory

You cannot migrate what you have not found. CISA's factsheet recommends discovery tools that look for quantum-vulnerable algorithms in network protocols, in applications and libraries on servers and end-user systems (including how firmware and software updates are signed), and in code and dependencies in the CI/CD pipeline. It warns that discovery tools may not see cryptography embedded inside products, so ask vendors for a list. The NCSC adds the data view: record what data you hold, its expected lifetime, its value to an adversary, and how it is protected in transit and at rest.

Places to look:

• TLS everywhere: public websites and APIs, internal services, load balancers, CDNs, mail servers.
• Remote access: IPsec and TLS VPNs, SSH to servers and network devices.
• Certificates and PKI: public certificates, internal certificate authorities, device and user certificates, code-signing keys.
• Key management: hardware security modules, cloud key management services, secrets managers.
• Software: which TLS and crypto libraries run at which versions, including inside containers; a software bill of materials, covered in our secure coding checklist, answers most of this.
• Long-lived devices: IoT and OT equipment, firmware signing, hardware roots of trust.

Record the result in a format tools can read. CycloneDX, for example, defines a cryptography bill of materials (CBOM) for exactly this inventory. For the internet-facing part, our security scanning service discovers the domains, subdomains, IP ranges and certificates you expose and checks their TLS configuration on a schedule.

Rank systems by how long their secrets must last

CISA adds high impact systems, industrial control systems and anything with long-term confidentiality needs to the top of the list.

Ask vendors for their post-quantum roadmaps

Most organizations will receive post-quantum cryptography from suppliers rather than build it, and the NCSC says your plan should not involve writing your own implementations. CISA asks organizations to request roadmaps that chart when vendors will test and ship PQC, for on-premises and cloud products alike, and to update contracts so new products arrive with PQC built in and older ones are upgraded. Useful questions:

• Which products already support hybrid ML-KEM in TLS, SSH and IPsec, and in which version?
• When will they support ML-DSA or SLH-DSA signatures, for certificates, firmware and software updates?
• Is the post-quantum implementation inside a FIPS 140-3 validated module, or when will it be?
• For cloud services: is PQC on by default, or is it a configuration change or an application update?

For small organizations on commodity IT, the NCSC expects the migration to arrive largely through vendor updates. Keeping software current is the plan.

Turn on and test hybrid key exchange

On servers, the change is usually a library upgrade. OpenSSL 3.5.0 and later, GnuTLS 3.8.9 and later, and Go 1.24 and later enable hybrid post-quantum key exchange by default. Nginx's default ssl_ecdh_curve auto uses the list built into OpenSSL, so linking against OpenSSL 3.5 brings the hybrid group in; if your configuration pins its own list, that list replaces the default, so add X25519MLKEM768 to it. Check load balancers, CDNs and TLS-terminating appliances too, since TLS often ends there rather than on the server.

Test from outside with a client that offers only the hybrid group. With OpenSSL 3.5 or later, the handshake completes and names X25519MLKEM768 if the server supports it, and fails with a handshake failure alert if it does not:

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

On macOS Tahoe 26, Apple documents the same check with the TLS diagnostics option of nscurl, and Cloudflare Radar offers a hostname test. Watch for breakage: the hybrid key share pushes the ClientHello past one network packet, and Apple warns that some legacy servers fail to read it. In an earlier scan, about 0.34% of origins failed the handshake when sent a post-quantum key share first, so test firewalls that inspect TLS, web application firewalls and older load balancers before and after the upgrade.

For SSH, OpenSSH 9.0 and later support sntrup761x25519-sha512, 9.9 and later support mlkem768x25519-sha256, and since 10.1 the client warns when a connection does not use post-quantum key exchange. If a current server does not negotiate one, check that KexAlgorithms has not removed them:

ssh -Q kex | grep -E "mlkem|sntrup"          # what this client supports
sudo sshd -T | grep -i kexalgorithms         # what this server will offer

For site-to-site and remote-access VPNs, ask the vendor whether its IKEv2 implementation supports hybrid ML-KEM and from which firmware version.

Plan certificates, PKI and HSMs

Signatures are harder than key exchange because they sit in chains that other people validate. A first visit to Cloudflare's own site carries five signatures and two public keys, and Cloudflare estimates that swapping in ML-DSA-44 adds about 15 kB to such a handshake. It also found that some clients and middleboxes fail on certificate chains larger than 10 kB, which is why Cloudflare and Chrome set out to test Merkle Tree Certificates, a design that sends far fewer signatures. The public web's approach is still being settled; your internal PKI does not have to wait. RFC 9881 (October 2025) defines how ML-DSA keys and signatures appear in X.509 certificates.

For an enterprise PKI, the NCSC describes three models: a new post-quantum root of trust running in parallel with the old PKI, a one-step move in tightly controlled environments, or a new root that cross-signs the old one. In every model, authentication is not quantum-secure until the migration is complete and the old certificates have expired or been revoked. The NCSC also asks you to identify long-lived hardware roots of trust in your 2028 plan.

Hardware security modules deserve early attention because they last. Ask your HSM vendor for its ML-KEM and ML-DSA firmware plan and validation status, and make sure hardware you buy now can take new algorithms by software update: the NSA's CNSA 2.0 FAQ asks for enough memory and processing power to run new algorithms for exactly this reason. Shorter certificate lifetimes help too; if certificates are already renewed automatically, as in our guide to renewing an SSL certificate, a new algorithm becomes a change to the issuing profile rather than a project.

Build crypto agility, then switch the old algorithms off

NIST defines crypto agility as the ability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while keeping systems secure and running. In practice that means terminating TLS in a few places you control, choosing algorithms in configuration rather than code, using maintained libraries, and automating how keys and certificates are replaced.

Agility also has an end state. The NCSC tells organizations to decide the criteria for ending support for traditional algorithms, and says you are fully protected only once nothing depends solely on them. Cloudflare adds two steps that are easy to forget: turn off quantum-vulnerable algorithms where you can, so an attacker cannot force a downgrade, and then rotate passwords and tokens that were exposed while they were in use.

Some systems are cheaper to move than to upgrade in place; the NCSC lists re-platforming as one of the migration strategies. If that is your route, our cloud transformation service moves workloads onto a landing zone whose identity, networks, policies and clusters are defined in Terraform and Git, with GitOps delivery so that a release is a merge rather than an event.