The bounded threat: what quantum computing actually breaks

Quantum computing will not break all encryption. The threat is specific and bounded, which makes it more tractable than the headlines suggest, and also more urgent for particular asset classes than most organisations have acknowledged.

Classical computers cannot solve certain mathematical problems at scale. Integer factorisation and discrete logarithm computation take so long on classical hardware that they serve as the practical foundation for RSA, Diffie-Hellman key exchange, and elliptic-curve cryptography (ECC). These algorithms underpin TLS certificates, corporate VPNs, digital signatures, and PKI infrastructure. A quantum computer running Shor's Algorithm, the quantum algorithm for integer factorisation published by Peter Shor in 1994, solves these problems in polynomial time. The practical implication: a fault-tolerant quantum computer of sufficient scale could break RSA-2048 in hours.

Symmetric encryption is a different story. Grover's Algorithm provides a quadratic speedup for unstructured search, halving the effective security parameter of symmetric algorithms. AES-128 drops to approximately 64-bit equivalent security under Grover's attack. AES-256 retains approximately 128-bit equivalent security, which is adequate for the quantum era. SHA-384 and SHA-512 retain adequate integrity margins. SHA-256 is marginal for long-lived data.

The governance-level summary: RSA, ECC, and Diffie-Hellman are specifically and fatally vulnerable to a cryptographically relevant quantum computer. AES-256 and SHA-384/512 are not. This is a precise, bounded threat. Understanding the boundary determines which assets require urgent migration and which have a longer runway. For the conceptual model behind why these algorithm classes are vulnerable, see the quantum computing fundamentals guide. It covers the mechanics of superposition, entanglement, and what Shor's advantage actually requires in hardware.

This topic is covered in depth in Session 1 of the QSECDEF Summer Bootcamp. Register to attend live or access the recording.

The hardware gap and what it means for planning

A quantum computer capable of executing Shor's Algorithm against RSA-2048 does not exist yet. A 2022 paper by Webber et al. in AVS Quantum Science estimated that attacking RSA-2048 with current error-correction codes would require approximately 317 million physical qubits. The most advanced quantum systems operational today have thousands, not millions. The hardware gap is real and currently very large.

The Global Risk Institute's Quantum Threat Timeline Report, compiled annually by Mosca and Piani from expert surveys across the quantum computing research community, places the median estimate for Q-Day, the point at which a cryptographically relevant quantum computer (CRQC) can execute Shor's Algorithm at meaningful key sizes, in the range of 10 to 20 years from the survey date. No mainstream technical position puts Q-Day within five years. None says never. For a full breakdown of what these estimates mean for your organisation's security posture, see our analysis at what Q-Day means for your security programme.

For migration planning, the uncertainty is not symmetric. NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022) treats the early 2030s as a migration cutover deadline for national security systems. That is not a start date. It is an end date. In every enterprise PQC project I have worked on, cryptographic inventory alone takes six to twelve months to complete. That means mapping where RSA, ECC, and Diffie-Hellman are deployed across an organisation's infrastructure, certificate estate, and application layer before a single algorithm is replaced. That is before a single algorithm is replaced. The organisations treating today's hardware gap as a reason to delay are confusing the absence of a CRQC with the absence of a deadline.

Harvest Now, Decrypt Later: why the threat is not fully future-tense

The assumption most organisations carry is that quantum computing risk becomes relevant on Q-Day. For data with short confidentiality requirements, that framing holds. For long-lived sensitive data, the threat window opened years ago.

Harvest Now, Decrypt Later (HNDL) refers to capturing and storing encrypted data today for decryption once a CRQC exists. Nation-state adversaries with long-term intelligence objectives do not need the hardware to mature before beginning collection. The NSA's Quantum Computing and Post-Quantum Cryptography FAQs (August 2021) acknowledged this collection methodology explicitly. HNDL is not a speculative threat category; it is the rational strategy of any adversary who expects CRQC capability within the confidentiality horizon of the data they hold. For sector-by-sector exposure analysis, see our companion piece on HNDL in motion and how to calculate your organisation's exposure.

The secrecy horizon framing is the most direct tool for prioritising HNDL risk. How long does the data encrypted today need to remain confidential? A merger negotiation requires months. A national health record may carry a 75-year statutory horizon. A defence procurement document may require 30 years. The secrecy horizon maps directly to HNDL exposure.

If your most sensitive data has a 15-year confidentiality requirement, and the median Q-Day estimate sits within a 10-to-20-year range, the risk window where an HNDL attack succeeds already overlaps with data your organisation encrypted before 2024. The data exists. It may already be in an adversary's possession. The decryption key is the CRQC they are building.

HNDL Risk Window Matrix 10yr (optimistic) 15yr (median) 25yr (pessimistic) <1yr 5yr 10yr 15yr 25yr 30yr+ Data confidentiality requirement Estimated Q-Day horizon 25yr 15yr 10yr Press release M&A docs IP / R&D Health records Defence comms HNDL RISK ZONE Data lifetime exceeds Q-Day estimate Active HNDL exposure Low HNDL exposure
HNDL risk window: data confidentiality requirements plotted against Q-Day horizon estimates. Data points in the highlighted zone are currently exposed to HNDL risk regardless of when Q-Day arrives.

What your security programme should be doing in 2026

The migration path is published and available. In August 2024, NIST finalised three post-quantum cryptographic standards: FIPS 203 defines ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), replacing RSA and ECC for key exchange. FIPS 204 defines ML-DSA (Module-Lattice-Based Digital Signature Algorithm), for digital signatures. FIPS 205 defines SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), providing hash-based signature assurance as a conservative complement. A fourth standard, FIPS 206 covering FN-DSA (lattice-based signatures derived from the FALCON algorithm), was not finalised alongside the three August 2024 standards and remains in final review as of mid-2026, with NIST targeting publication in late 2026 or early 2027. The question for most organisations is no longer which standards to migrate to. It is where they are in the programme.

The NCSC published updated guidance in 2024 recommending UK organisations begin cryptographic discovery and migration planning immediately, aligned to the NIST standards. NIST IR 8547, published in initial public draft in November 2024 with a transition roadmap covering deprecation of RSA and ECC in new federal systems by 2030 and full disallowance by 2035, has since been reinforced at the executive level. On 22 June 2026, Executive Order 14412 mandated that federal agencies complete transition of their most sensitive systems to post-quantum encryption by 31 December 2030, and directed federal contractors to comply with FIPS standards on the same timeline. These are now compliance deadlines, not proposals. The NIST FIPS 203, 204, and 205 implementation guide covers what these standards require in practice and what implementation decisions they leave open. For a deeper look at the algorithms being adopted, the companion article on post-quantum cryptography covers the algorithm selection layer in full. It addresses why lattice-based schemes dominate the NIST selections, what parameter sets apply to different system classes, and where hybrid deployments are recommended.

For a security leader preparing a board briefing, the governance checklist below is a minimum starting position. Each item requires active confirmation rather than assumption:

  • Risk register entry. A named board risk register entry creates the resource allocation authority needed to fund a migration programme.
  • Data secrecy horizon audit. Identify the data your organisation holds with the longest confidentiality requirements. That is where HNDL exposure is highest.
  • CISO status question. What is the current status of the cryptographic inventory? If the answer is "not yet started," that is material information for the risk register.
  • HNDL exposure identification. Which data created before 2024 has a confidentiality requirement longer than 10 years? That data is currently exposed to HNDL risk regardless of Q-Day timing.
  • Vendor migration roadmaps. Request post-quantum readiness roadmaps from your top software and infrastructure suppliers. Vendors without a published PQC roadmap in 2026 represent a supply chain risk, not merely a product gap.

QSECDEF's Q-Day timeline risk calculator lets security teams model the risk window against their organisation's specific data classifications and retention periods. We cover the programme management layer in depth in the QSECDEF Summer Bootcamp: how to structure a PQC migration programme, where projects typically stall, and how to build the business case for board approval.

The question I am most often asked at this stage of a board briefing is: "Should we be worried?" For some of your data, the honest answer is yes, and that concern should have already translated into a named programme with a budget owner. For the majority of your data, no. The threat is bounded and the response is available. The organisations that will face the most painful recovery in the 2030s are the ones that confused "no imminent Q-Day" with "no urgent action required."

Session 1 of the QSECDEF Summer Bootcamp covers this material in full. Register for the bootcamp →

Sources

  1. NIST IR 8105, "Report on Post-Quantum Cryptography," April 2016. doi:10.6028/NIST.IR.8105
  2. Shor, P.W., "Algorithms for quantum computation: Discrete logarithms and factoring," IEEE FOCS 1994. doi:10.1109/SFCS.1994.365700
  3. Webber, M. et al., "The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime," AVS Quantum Science, 2022. doi:10.1116/5.0073075
  4. NIST FIPS 203 (ML-KEM), August 2024. doi:10.6028/NIST.FIPS.203
  5. NIST FIPS 204 (ML-DSA), August 2024. doi:10.6028/NIST.FIPS.204
  6. NIST FIPS 205 (SLH-DSA), August 2024. doi:10.6028/NIST.FIPS.205
  7. NSA, "Commercial National Security Algorithm Suite 2.0," September 2022. NSA CNSA 2.0
  8. NSA, "Quantum Computing and Post-Quantum Cryptography FAQs," August 2021. NSA Quantum FAQs
  9. NCSC, "Next steps in preparing for post-quantum cryptography," 2024. ncsc.gov.uk
  10. GRI / evolutionQ, Quantum Threat Timeline Research Report 2025, Mosca and Piani, December 2025. globalriskinstitute.org
  11. White House, Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," 22 June 2026. whitehouse.gov