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

> Quantum computers will break RSA and elliptic-curve cryptography, not AES. What is at risk, NIST's post-quantum standards, the deadlines and a migration plan.

- URL: https://computese.com/quantum-computing-in-cybersecurity-breakthrough/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-08-19
- Updated: 2026-09-25
- Topics: Security, Cloud

## In short
- A large, error-corrected quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography. AES and SHA-2 are far less exposed: Grover's algorithm gives only a square-root speedup.
- Traffic recorded today can be decrypted once such a machine exists (harvest now, decrypt later), so the key exchange that protects long-lived secrets has to move to post-quantum algorithms now.
- NIST published ML-KEM, ML-DSA and SLH-DSA (FIPS 203, 204 and 205) on August 13, 2024. Its draft transition plan deprecates 112-bit RSA and elliptic-curve keys after 2030 and disallows all of them after 2035.
- Hybrid ML-KEM key exchange is already on by default in major browsers (X25519MLKEM768), OpenSSL 3.5 and OpenSSH 10.0, yet in September 2026 only 12.8% of the origin servers Cloudflare scanned supported it.
- Start with a cryptographic inventory, rank systems by how long their data must stay secret, ask vendors for PQC roadmaps, test hybrid TLS on your own servers, and plan certificates, PKI and HSMs.

Quantum computing matters to cybersecurity for one main reason: a large, error-corrected quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography, the public-key algorithms behind TLS, VPNs, SSH and code signing. Symmetric ciphers such as AES and hash functions such as SHA-256 are far less affected. The defence is post-quantum cryptography, deployed before such a machine exists.

This guide explains why only public-key cryptography falls, how close a cryptographically relevant quantum computer is after the research results of 2025 and 2026, why recorded traffic makes the deadline earlier than the machine, NIST's post-quantum standards, the deadlines set by NIST, the NSA, the UK NCSC and others, what is already deployed, and a migration plan for an organization. For how quantum computers work, read [what a quantum computer is, and whether it is really faster](https://computese.com/quantum-computer-a-new-faster-type-of-computing/). For what quantum computing changes for IT teams beyond cryptography, read [how quantum computing could transform IT](https://computese.com/how-quantum-computing-could-transform-it/).

## 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](https://arxiv.org/abs/quant-ph/9508027) 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](https://csrc.nist.gov/pubs/ir/8547/ipd).

Symmetric cryptography faces a much weaker attack. [Grover's algorithm](https://arxiv.org/abs/quant-ph/9605043), 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](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF) 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.

| Algorithm family                     | Where you use it                              | Quantum attack                          | What replaces it                                  |
| ------------------------------------ | --------------------------------------------- | --------------------------------------- | ------------------------------------------------- |
| RSA                                  | Certificates, signatures, older key transport | Shor's algorithm breaks it              | ML-KEM for keys, ML-DSA or SLH-DSA for signatures |
| Diffie-Hellman, ECDH (X25519, P-256) | Key exchange in TLS, SSH and IPsec VPNs       | Shor's algorithm breaks it              | Hybrid key exchange with ML-KEM                   |
| ECDSA, EdDSA (Ed25519)               | Certificates, code signing, SSH keys, tokens  | Shor's algorithm breaks it              | ML-DSA or SLH-DSA                                 |
| AES                                  | Encrypting data in transit and at rest        | Grover's algorithm: square-root speedup | Keep it; AES-256 where CNSA 2.0 applies           |
| SHA-2, SHA-3                         | Hashing, HMAC, key derivation                 | Significantly less vulnerable           | Keep it; SHA-384 or SHA-512 under CNSA 2.0        |

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](https://www.openssh.com/pq.html), 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](https://csrc.nist.gov/projects/post-quantum-cryptography). What has changed is the estimate of how big it must be, and it has fallen sharply:

| Published                                                                                                                                    | Target                  | Estimated machine                                                                              |
| -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------- |
| 2019, Gidney and Ekerå                                                                                                                       | 2048-bit RSA            | 20 million noisy qubits, eight hours                                                           |
| May 2025, [Gidney](https://arxiv.org/abs/2505.15917)                                                                                         | 2048-bit RSA            | Fewer than a million noisy qubits, less than a week                                            |
| March 2026, [Google Quantum AI](https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/) | 256-bit elliptic curves | Fewer than 500,000 physical qubits, a few minutes                                              |
| March 2026, [Cain and colleagues](https://arxiv.org/abs/2603.28627)                                                                          | P-256 and 2048-bit RSA  | As few as 10,000 reconfigurable atomic qubits; P-256 in a few days with 26,000 physical qubits |

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](https://computese.com/advancements-in-quantum-circuit-design/).

For scale, Google's Willow chip, announced in December 2024, has [105 qubits](https://blog.google/innovation-and-ai/technology/research/google-willow-quantum-chip/). 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](https://blog.cloudflare.com/pq-2025/). The estimates still moved plans. In March 2026 Google set [2029 as the deadline for its own migration](https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/) and put authentication first, and in April 2026 Cloudflare [moved its target for full post-quantum security to 2029](https://blog.cloudflare.com/post-quantum-roadmap/), 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](https://computese.com/understanding-eavesdropping-attacks-how-they-work/) 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.

![A tap copies padlocked envelopes from a laptop-to-server line into a storage cabinet. Later a quantum computer opens the single padlocks, but an envelope with an extra orange padlock stays shut.](https://computese.com/images/blog/quantum-computing-in-cybersecurity-breakthrough/harvest.abd4805f3d-1536.webp)

*Traffic is only as safe as the key exchange used on the day it was recorded, so the upgrade has to come before the machine.*

[NIST's draft plan](https://csrc.nist.gov/pubs/ir/8547/ipd) 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](https://security.apple.com/blog/imessage-pq3/), [OpenSSH](https://www.openssh.com/pq.html) and [Signal](https://signal.org/blog/pqxdh/) 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](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-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](https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption), 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](https://csrc.nist.gov/projects/post-quantum-cryptography), 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:

| Algorithm         | Type                                | Public key (bytes) | Ciphertext or signature (bytes) |
| ----------------- | ----------------------------------- | ------------------ | ------------------------------- |
| X25519            | Classical key exchange              | 32                 | 32                              |
| ML-KEM-768        | Post-quantum key encapsulation      | 1,184              | 1,088                           |
| Ed25519           | Classical signature                 | 32                 | 64                              |
| ML-DSA-44         | Post-quantum signature (lattice)    | 1,312              | 2,420                           |
| SLH-DSA-SHA2-128s | Post-quantum signature (hash-based) | 32                 | 7,856                           |

Sizes are from [RFC 10024](https://www.rfc-editor.org/rfc/rfc10024.html) for the key exchanges, [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032.html) for Ed25519, and [FIPS 204](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) and [FIPS 205](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf) 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](https://signal.org/blog/pqxdh/), 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](https://www.rfc-editor.org/rfc/rfc10024.html), 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.

![A laptop sends a server two key shares, a small grey key and a larger orange lattice block. Under each device, both secrets feed into a funnel that outputs one session key, identical on both sides.](https://computese.com/images/blog/quantum-computing-in-cybersecurity-breakthrough/hybrid.3544c04fc1-1536.webp)

*A hybrid handshake stays secure as long as either of its two key exchanges holds, which is why it is the default while ML-KEM is young.*

### 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](https://www.ncsc.gov.uk/paper/quantum-networking-technologies) and names post-quantum cryptography as the best mitigation, and the NSA [does not recommend QKD](https://www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/) 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:

| Source                                                                                                                                                        | Applies to                                           | Milestones                                                                                                                                                                                                              |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd), initial public draft (November 2024, still the current version)                                       | US federal agencies, industry, standards bodies      | Quantum-vulnerable algorithms at 112-bit security strength deprecated after 2030; RSA, ECDSA, EdDSA and (EC)DH at every strength disallowed after 2035                                                                  |
| [Executive Order 14412](https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/) (June 22, 2026)  | US federal high value assets and high impact systems | Post-quantum key establishment by December 31, 2030; post-quantum signatures by December 31, 2031; a proposed rule requiring covered contractors to comply with NIST's FIPS, including PQC, by December 31, 2030        |
| NSA [CNSA 2.0 FAQ](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF) (December 2024)                                            | US national security systems                         | New acquisitions CNSA 2.0 compliant from January 1, 2027; equipment that cannot support it phased out by December 31, 2030; CNSA 2.0 algorithms mandatory from December 31, 2031; all systems quantum-resistant by 2035 |
| [UK NCSC](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines) (March 2025)                                                                              | UK organizations (guidance)                          | Discovery and an initial migration plan by 2028; highest-priority migrations by 2031; all systems by 2035                                                                                                               |
| [Canadian Centre for Cyber Security](https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001) (June 2025) | Government of Canada systems                         | Departmental plans by April 2026; high-priority systems by the end of 2031; the rest by the end of 2035                                                                                                                 |

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](https://www.cisa.gov/resources-tools/resources/product-categories-technologies-use-post-quantum-cryptography-standards) 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.

> [!IMPORTANT]
> Plan against the earliest deadline that applies to you, not the latest. NIST's own draft notes that moving from a new standard to full integration has historically taken 10 to 20 years, and in September 2026, 2035 is nine years away.

## What is already post-quantum in 2026

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

| Product                               | Post-quantum feature                                                                      | Since                                                                                                 |
| ------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Chrome                                | Hybrid key share X25519MLKEM768 (TLS codepoint 0x11EC), replacing an earlier Kyber hybrid | [Chrome 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html)                |
| Firefox                               | mlkem768x25519 key exchange for TLS 1.3                                                   | [Firefox 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/), October 29, 2024            |
| iOS, iPadOS, macOS Tahoe and visionOS | TLS 1.3 connections advertise X25519MLKEM768 automatically                                | [Version 26](https://support.apple.com/en-us/122756)                                                  |
| OpenSSL                               | ML-KEM, ML-DSA and SLH-DSA; X25519MLKEM768 in the default key shares                      | [OpenSSL 3.5.0](https://openssl-library.org/news/openssl-3.5-notes/), April 8, 2025                   |
| OpenSSH                               | Post-quantum key exchange by default; mlkem768x25519-sha256 is the default since 10.0     | [9.0, April 2022; 10.0, April 2025](https://www.openssh.com/pq.html)                                  |
| iMessage                              | PQ3: hybrid Kyber and elliptic-curve keys at setup, plus periodic post-quantum rekeying   | [iOS 17.4 and macOS 14.4](https://security.apple.com/blog/imessage-pq3/), announced February 21, 2024 |
| Signal                                | PQXDH at chat setup; SPQR adds a post-quantum ratchet (the Triple Ratchet)                | [September 2023](https://signal.org/blog/pqxdh/) and [October 2025](https://signal.org/blog/spqr/)    |

The effect shows up in traffic. In April 2026 Cloudflare reported that [over 65% of human traffic](https://blog.cloudflare.com/post-quantum-roadmap/) to its network was post-quantum encrypted. The server side lags: in September 2026 Cloudflare reported that [12.8% of the origin servers](https://blog.cloudflare.com/automatic-key-exchange-for-origins/) 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](https://www.cisa.gov/resources-tools/resources/product-categories-technologies-use-post-quantum-cryptography-standards) 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](https://www.cisa.gov/sites/default/files/2023-08/Quantum%20Readiness_Final_CLEAR_508c%20%283%29.pdf) and the [NCSC's migration guidance](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines) 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.

![A magnifying glass moves along a row of devices: a web server, a VPN gateway, a laptop, a database and a hardware security module. Lines lead to a clipboard of rows, and the database's row is orange.](https://computese.com/images/blog/quantum-computing-in-cybersecurity-breakthrough/inventory.07d35b52e4-1536.webp)

*The inventory decides the order of the migration: the data that must stay secret longest goes first.*

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](https://computese.com/best-practices-for-secure-coding/), 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)](https://cyclonedx.org/capabilities/cbom/) for exactly this inventory. For the internet-facing part, our [security scanning](https://computese.com/services/security-testing/) 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

| Priority | Examples                                                                                                    | Why                                                                                                                                                                                                                |
| -------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| First    | Confidential data crossing public networks that must stay secret for years                                  | Exposed to harvest now, decrypt later today; Canada's Cyber Centre makes such systems [high priority](https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001) |
| Next     | Root and intermediate CAs, code and firmware signing keys, API authentication keys, hardware roots of trust | Cloudflare expects the first attackers to go after [long-lived keys](https://blog.cloudflare.com/post-quantum-roadmap/) that give lasting access, and hardware takes years to replace                              |
| Later    | Short-lived data, systems due to be retired before the early 2030s                                          | The NCSC lists retiring a service or running it to end of life as valid strategies                                                                                                                                 |

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](https://blog.cloudflare.com/radar-origin-pq-key-transparency-aspa/). Nginx's default `ssl_ecdh_curve auto` [uses the list built into OpenSSL](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), 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:

```bash
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](https://support.apple.com/en-us/122756) 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](https://blog.cloudflare.com/automatic-key-exchange-for-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](https://www.openssh.com/pq.html) 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:

```bash
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](https://blog.cloudflare.com/pq-2025/) 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](https://www.rfc-editor.org/rfc/rfc9881.html) (October 2025) defines how ML-DSA keys and signatures appear in X.509 certificates.

For an enterprise PKI, the [NCSC describes](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines) 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](https://computese.com/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](https://csrc.nist.gov/pubs/cswp/39/considerations-for-achieving-cryptographic-agility/final) 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](https://blog.cloudflare.com/post-quantum-roadmap/) 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](https://computese.com/services/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.

## Key terms
- **Cryptographically relevant quantum computer (CRQC)**: A quantum computer large and reliable enough to run Shor's algorithm against key sizes used in practice, such as 2048-bit RSA or P-256. None exists as of September 2026. The NSA and CISA call it cryptanalytically relevant.
- **Shor's algorithm**: Peter Shor's 1994 quantum algorithm for factoring integers and computing discrete logarithms in polynomial time. It breaks RSA, Diffie-Hellman and elliptic-curve cryptography.
- **Grover's algorithm**: Lov Grover's 1996 quantum search algorithm. It finds an item among N in about the square root of N steps, which weakens symmetric ciphers far less than Shor's algorithm weakens public-key cryptography.
- **Post-quantum cryptography (PQC)**: Public-key algorithms that run on ordinary computers and are designed to resist attack by both classical and quantum computers, such as ML-KEM, ML-DSA and SLH-DSA. Also called quantum-safe or quantum-resistant cryptography.
- **Harvest now, decrypt later**: Recording encrypted traffic or copying encrypted data today in order to decrypt it once a capable quantum computer exists. Also called store now, decrypt later.
- **ML-KEM**: The Module-Lattice-Based Key-Encapsulation Mechanism in FIPS 203, derived from CRYSTALS-Kyber. It replaces RSA key transport and Diffie-Hellman for establishing shared keys.
- **ML-DSA and SLH-DSA**: The post-quantum signature standards: ML-DSA in FIPS 204 (lattice-based, from CRYSTALS-Dilithium) and SLH-DSA in FIPS 205 (hash-based, from SPHINCS+). They replace RSA, ECDSA and EdDSA signatures.
- **Hybrid key exchange**: A handshake that runs a classical and a post-quantum key exchange together and derives the session key from both, such as X25519MLKEM768 in TLS 1.3. It stays secure as long as either part holds.
- **Crypto agility**: NIST's term for the ability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.
- **Cryptographic inventory (CBOM)**: A record of where and how an organization uses cryptography: algorithms, keys, certificates, protocols, libraries and devices. A cryptography bill of materials (CBOM) is a machine-readable format for it.

## Common questions

### Can a quantum computer break encryption today?

No. As of September 2026 no quantum computer can break the RSA or elliptic-curve keys used in practice. Google's Willow chip has 105 qubits, while a 2025 estimate for factoring 2048-bit RSA assumes fewer than a million noisy qubits running for less than a week. Those estimates keep falling, which is why migration has to start before the hardware exists.

### Is AES-256 quantum-safe?

As far as anyone knows, yes. Grover's algorithm gives only a square-root speedup on key search, and NIST's draft transition plan says symmetric algorithms with at least 128 bits of classical security, AES-128 included, are believed to hold. The NSA still requires AES-256 for national security systems under CNSA 2.0.

### What is the difference between post-quantum cryptography and quantum cryptography?

Post-quantum cryptography is new mathematics that runs on the computers and networks you already have. Quantum cryptography, such as quantum key distribution (QKD), uses quantum physics and dedicated hardware, and does not authenticate the parties on its own. The UK NCSC will not support QKD for government or military use, and the NSA does not recommend it for national security systems.

### When do we have to finish migrating to post-quantum cryptography?

It depends on who you answer to. NIST's draft plan disallows RSA and elliptic-curve algorithms after 2035. The UK NCSC asks for discovery by 2028, priority systems by 2031 and everything by 2035. A June 2026 US executive order sets December 31, 2030 for post-quantum key establishment on federal high value systems and December 31, 2031 for signatures. Google and Cloudflare target 2029 for their own systems.

### Does a small business need to do anything?

If you run only commodity IT (current browsers, operating systems, phones and SaaS), the NCSC expects the change to arrive mostly through vendor updates, so keep everything updated and ask suppliers about their plans. Custom software, your own web servers and VPNs, and devices that stay in service for many years need a plan of their own.

### Will post-quantum TLS slow my website down?

Hybrid key exchange adds about 1.2 kB from client to server and 1.1 kB back. Cloudflare reports that Chrome measured about a 4% slower TLS handshake from it, and the practical risk is old servers or middleboxes that fail on a ClientHello larger than one packet. Post-quantum certificates cost far more bytes, and how to deploy them on the public web is still being worked out.

## Sources
1. [Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer](https://arxiv.org/abs/quant-ph/9508027), arXiv (Peter Shor, 1995; FOCS 1994)
2. [NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd), NIST
3. [A fast quantum mechanical algorithm for database search](https://arxiv.org/abs/quant-ph/9605043), arXiv (Lov Grover, 1996; STOC 1996)
4. [The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ (December 2024)](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF), National Security Agency
5. [Post-Quantum Cryptography: SSH](https://www.openssh.com/pq.html), OpenSSH
6. [Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography), NIST Computer Security Resource Center
7. [How to factor 2048 bit RSA integers with less than a million noisy qubits](https://arxiv.org/abs/2505.15917), arXiv (Craig Gidney, 2025)
8. [Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly](https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/), Google Research
9. [Shor's algorithm is possible with as few as 10,000 reconfigurable atomic qubits](https://arxiv.org/abs/2603.28627), arXiv (Cain et al., 2026)
10. [Meet Willow, our state-of-the-art quantum chip](https://blog.google/innovation-and-ai/technology/research/google-willow-quantum-chip/), Google
11. [State of the post-quantum Internet in 2025](https://blog.cloudflare.com/pq-2025/), Cloudflare
12. [Google's timeline for PQC migration](https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/), Google
13. [Cloudflare targets 2029 for full post-quantum security](https://blog.cloudflare.com/post-quantum-roadmap/), Cloudflare
14. [iMessage with PQ3: The new state of the art in quantum-secure messaging at scale](https://security.apple.com/blog/imessage-pq3/), Apple Security Research
15. [Quantum Resistance and the Signal Protocol](https://signal.org/blog/pqxdh/), Signal
16. [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards), NIST
17. [NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption](https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption), NIST
18. [RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3](https://www.rfc-editor.org/rfc/rfc10024.html), IETF
19. [RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)](https://www.rfc-editor.org/rfc/rfc8032.html), IETF
20. [FIPS 204: Module-Lattice-Based Digital Signature Standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf), NIST
21. [FIPS 205: Stateless Hash-Based Digital Signature Standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf), NIST
22. [Quantum networking technologies](https://www.ncsc.gov.uk/paper/quantum-networking-technologies), UK National Cyber Security Centre
23. [Post-Quantum Cybersecurity Resources](https://www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/), National Security Agency
24. [Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks](https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/), The White House
25. [Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines), UK National Cyber Security Centre
26. [Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)](https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001), Canadian Centre for Cyber Security
27. [Product Categories for Technologies That Use Post-Quantum Cryptography Standards](https://www.cisa.gov/resources-tools/resources/product-categories-technologies-use-post-quantum-cryptography-standards), CISA
28. [A new path for Kyber on the web](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html), Google Online Security Blog
29. [Firefox 132.0 release notes](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/), Mozilla
30. [Prepare your network for quantum-secure encryption in TLS](https://support.apple.com/en-us/122756), Apple Support
31. [OpenSSL 3.5 release notes](https://openssl-library.org/news/openssl-3.5-notes/), OpenSSL Library
32. [Signal Protocol and Post-Quantum Ratchets](https://signal.org/blog/spqr/), Signal
33. [Automatic Key Exchange: faster, post-quantum secure origin handshakes](https://blog.cloudflare.com/automatic-key-exchange-for-origins/), Cloudflare
34. [Quantum-Readiness: Migration to Post-Quantum Cryptography (factsheet)](https://www.cisa.gov/sites/default/files/2023-08/Quantum%20Readiness_Final_CLEAR_508c%20%283%29.pdf), CISA, NSA and NIST
35. [Cryptography Bill of Materials (CBOM)](https://cyclonedx.org/capabilities/cbom/), OWASP CycloneDX
36. [Bringing more transparency to post-quantum usage, encrypted messaging, and routing security](https://blog.cloudflare.com/radar-origin-pq-key-transparency-aspa/), Cloudflare
37. [Module ngx_http_ssl_module](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), nginx
38. [RFC 9881: Algorithm Identifiers for ML-DSA in the Internet X.509 PKI](https://www.rfc-editor.org/rfc/rfc9881.html), IETF
39. [CSWP 39: Considerations for Achieving Cryptographic Agility](https://csrc.nist.gov/pubs/cswp/39/considerations-for-achieving-cryptographic-agility/final), NIST