The 10 Most Common Cyberattacks: How Quantum Computing Changes Which Ones to Fear
The quantum security press has a fear problem. Every week brings another warning that quantum computers will break encryption and render every cyberattack more dangerous. Security teams reading this coverage could be forgiven for thinking that post-quantum migration is the only item on the agenda. The reality is considerably more nuanced, and considerably less alarming for most attack categories.
<p>The honest answer is that the vast majority of enterprise cyberattacks do not change because of quantum computing. Phishing, SQL injection, DDoS, zero-day exploits, credential stuffing, cryptojacking: all of these operate on mechanisms that a cryptographically relevant quantum computer (CRQC) cannot touch. Three categories genuinely require architectural attention. Two of those three responses are already overdue. One is happening right now whether organisations acknowledge it or not.</p>
<p>This article maps quantum relevance against the 10 most common attack types, assigns a verdict to each, and focuses the available depth on the attacks that actually matter. If you leave with a clearer sense of where not to spend quantum-specific budget, the article has done its job.</p>
Quantum Relevance at a Glance
Four verdicts are used throughout this article. No quantum change: the attack mechanism is unaffected by CRQC capability. Marginal: a peripheral element creates a long-tail exposure but the core attack path is unchanged. Significant: a primary mechanism is directly vulnerable to Shor's algorithm and requires architectural migration now. Fundamental: the attack category is predicated on future CRQC existence; the threat model itself is quantum-dependent.
<table>
<thead>
<tr>
<th>Attack</th>
<th>Quantum relevance</th>
<th>Core reason</th>
</tr>
</thead>
<tbody>
<tr>
<td>Phishing</td>
<td>No quantum change</td>
<td>Human exploitation, not cryptography</td>
</tr>
<tr>
<td>Ransomware</td>
<td>Marginal</td>
<td>Symmetric file encryption unaffected; TLS exfiltration channel is HNDL-adjacent</td>
</tr>
<tr>
<td>Man-in-the-Middle (MITM)</td>
<td>Significant</td>
<td>TLS ECDHE key exchange broken by Shor's algorithm</td>
</tr>
<tr>
<td>SQL Injection</td>
<td>No quantum change</td>
<td>Application logic flaw, no cryptographic component in attack path</td>
</tr>
<tr>
<td>DDoS</td>
<td>No quantum change</td>
<td>Volumetric/protocol, not cryptographic</td>
</tr>
<tr>
<td>Zero-Day Exploits</td>
<td>No quantum change</td>
<td>Software vulnerability exploitation; Grover not practically applicable</td>
</tr>
<tr>
<td>Credential Stuffing</td>
<td>No quantum change</td>
<td>Password reuse/list-based, not a cryptographic attack</td>
</tr>
<tr>
<td>Supply Chain</td>
<td>Significant</td>
<td>Code-signing (ECDSA/RSA) broken by Shor; CBOM migration required</td>
</tr>
<tr>
<td>Cryptojacking</td>
<td>No quantum change</td>
<td>Proof-of-work mining; Grover offers no net advantage</td>
</tr>
<tr>
<td>Nation-State HNDL</td>
<td>Fundamental</td>
<td>Attack model is predicated on future CRQC existence</td>
</tr>
</tbody>
</table>
<p>A CRQC (cryptographically relevant quantum computer) is one capable of running Shor's algorithm at scale. Current hardware from IBM, Google, and others is in the NISQ era: noisy, limited qubit count, no fault tolerance sufficient for cryptanalytic work. Gidney and Ekerå (2021) calculated that breaking RSA-2048 requires approximately 20 million physical qubits running for around 8 hours. Webber et al. (2022, AVS Quantum Science) put the requirement for a one-hour attack at approximately 317 million physical qubits. No hardware in existence approaches either figure. The <a href="/quantum-news/crqc-timeline-when-quantum-computers-real-threat">Global Risk Institute's 2024 assessment</a> places the probability of a CRQC capable of threatening RSA-2048 or ECC-256 at 14 to 34% by 2033. That window is the basis for urgency in the three categories that actually change.</p>
1. Phishing
Quantum relevance: No quantum change
<p>Phishing exploits the gap between how email looks and what it actually is. A CRQC does not help an attacker write a more convincing subject line, impersonate a CFO, or manufacture urgency in a wire transfer request. Business email compromise fraud and credential-harvesting campaigns run entirely on social engineering and identity trust failures. Neither is a cryptographic problem.</p>
<p>One technical nuance is worth noting without overstating it. DKIM email authentication uses RSA or ECDSA signatures to verify that a message originated from an authorised mail server. Both RSA and ECDSA are vulnerable to Shor's algorithm. This creates a genuine, if peripheral, concern for email authentication infrastructure: a CRQC could theoretically forge valid DKIM signatures, undermining one layer of the anti-spoofing stack. That is an email infrastructure migration concern, not a phishing-as-attack-vector concern. The core phishing threat model does not change.</p>
2. Ransomware
Quantum relevance: Marginal
<p>Ransomware encrypts files using symmetric algorithms. AES (typically AES-128 or AES-256-GCM for bulk file encryption) is not broken by Shor's algorithm, which applies to integer factorisation and discrete logarithm problems. Grover's algorithm, which provides a quadratic speedup for unstructured search, effectively halves the security of symmetric keys: AES-128 is reduced to approximately 64-bit equivalent security under Grover. NIST SP 800-57 Part 1 Rev 5 sets 112-bit minimum security strength for newly deployed systems; the post-Grover effective strength of AES-128 falls below that floor, which is why AES-256-GCM is the correct choice for any new symmetric deployment. Modern ransomware groups have moved toward AES-256-GCM for file encryption; older or less sophisticated variants still use AES-128. The symmetric file-encryption layer is not materially changed by quantum for correctly specified deployments.</p>
<p>The marginal exposure sits in the asymmetric layer. Ransomware operators wrap the per-victim symmetric key using RSA or ECC public-key cryptography. <a href="/quantum-news/shors-algorithm-rsa-ecc-quantum">Shor breaks both</a>. A theoretical concern arises from the double-extortion model: groups that exfiltrate data before encrypting it do so over TLS, and TLS uses ECDHE key exchange that is vulnerable to Shor. In principle, an attacker who captured the TLS exfiltration sessions could decrypt them with a future CRQC. In practice, ransomware operators want payment now, not forensic capability years later. The HNDL model applied to ransomware exfiltration is theoretically valid but operationally implausible for most threat actors. The real implication is that PQC migration of TLS key exchange is the correct response to this marginal exposure, and that response is warranted regardless of the ransomware context.</p>
3. Man-in-the-Middle (MITM)
Quantum relevance: Significant
<p>MITM is the most technically direct quantum-relevant entry in this list. The mechanism matters here more than the category name.</p>
<h3>Why TLS ECDHE is the specific vulnerability</h3>
<p>TLS 1.3 (RFC 8446) uses ECDHE for key exchange: specifically X25519 or P-256/P-384. ECDHE security rests on the elliptic curve discrete logarithm problem. Shor's algorithm solves discrete logarithm problems in polynomial time on a CRQC. A CRQC with sufficient qubit count could therefore recover the session key from captured TLS handshake traffic. The record layer uses AES-GCM, which is not broken by Shor. The vulnerability is specific to the key exchange phase, not to TLS as a whole.</p>
<p>The implication for MITM is in what is being captured today. Traffic recorded now can be stored and decrypted later once CRQC capability exists. This is the harvest-now-decrypt-later (HNDL) model applied to MITM at network scale. TLS MITM interception is already a present-day attack; the quantum dimension adds a future-decryption risk to sessions that appear secure today.</p>
<h3>The architectural response</h3>
<p>The response to this exposure is hybrid key exchange: deploying ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardised as FIPS 203 in August 2024) alongside X25519 so that both algorithms must be broken to compromise the session. NIST finalised ML-KEM in August 2024. Hybrid TLS implementations combining X25519 with ML-KEM are in active deployment at major cloud providers and in Chrome. The X25519Kyber768Draft00 configuration established early interoperability across the ecosystem; this remains an IETF draft rather than a published RFC, but practical deployment is underway.</p>
<p>MITM via TLS stripping or certificate substitution is an existing, present-day attack that falls in the no-quantum-change category. The quantum-specific concern is forward secrecy failure in ECDHE sessions: the value of harvested traffic increases as CRQC capability approaches. For MITM specifically, hybrid TLS key exchange is the migration priority.</p>
4. SQL Injection
Quantum relevance: No quantum change
<p>SQL injection exploits input validation failures in application code. There is no cryptographic component in its attack path. A CRQC does not help an attacker discover an unparameterised query or construct a UNION-based payload. Data at rest in a compromised database may be encrypted with RSA-wrapped keys, which creates a marginal HNDL concern for exfiltrated material, but that is a data-at-rest question, not a SQL injection question. Parameterised queries, ORM usage, and least-privilege database accounts require no quantum-specific changes.</p>
5. Distributed Denial of Service (DDoS)
Quantum relevance: No quantum change
<p>DDoS attacks flood network capacity, exhaust connection tables, or overwhelm application endpoints. Quantum computing offers no meaningful speedup for generating high-volume traffic, constructing amplification reflectors, or coordinating botnet infrastructure. Mitigation operates on BGP blackholing, scrubbing centres, Anycast routing, and rate limiting, none of which are cryptographically dependent. Some C2 infrastructure uses TLS, but that creates the same ECDHE exposure present across all TLS deployments, not a DDoS-specific quantum concern.</p>
6. Zero-Day Exploits
Quantum relevance: No quantum change
<p>The bottleneck in zero-day discovery is code comprehension, vulnerability analysis, and exploit engineering. None of these are bottlenecked by computational search. Grover's algorithm could in principle accelerate fuzzing by a square-root factor, but vulnerability research is constrained by the cognitive work of understanding complex codebases and writing weaponisable exploits. Quantum computing does not change that. Patch management, EDR, memory-safety mitigations, and network segmentation require no quantum-specific revision.</p>
7. Credential Stuffing
Quantum relevance: No quantum change
<p>Credential stuffing tests previously leaked username and password pairs against other services. The attack is authentication-layer exploitation, not a cryptographic one. Obtaining the credential list requires a prior breach; testing it requires HTTP requests to login endpoints. A CRQC is irrelevant to either step. Password hashing with Argon2 or bcrypt introduces memory-hard operations that further constrain any Grover speedup. Multi-factor authentication makes credential stuffing largely moot regardless of credential provenance.</p>
8. Supply Chain Attacks
Quantum relevance: Significant
<p>Supply chain attacks compromise software or hardware before it reaches the target. SolarWinds, NotPetya, XZ Utils: the attack surface is the integrity of the software delivery chain. That integrity rests on code-signing infrastructure, and code-signing infrastructure uses ECDSA and RSA.</p>
<h3>Why Shor's algorithm changes the supply chain threat model</h3>
<p>Software packages, firmware updates, and container images are signed to verify authenticity. The signing algorithms are ECDSA (P-256, P-384), EdDSA (Ed25519, Ed448), and RSA. All are broken by Shor's algorithm. On a CRQC of sufficient scale, forging a valid signature under any of these schemes becomes computationally feasible. A supply chain attacker with CRQC access could sign a malicious package with a forged certificate that passes standard verification, bypassing the integrity check that the entire supply chain security model depends on.</p>
<p>The standards response is migration of code-signing infrastructure to FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Standard) or FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Standard), both finalised in August 2024. SLH-DSA is a hash-based scheme; its security does not rest on factoring or discrete logarithm, so Shor's algorithm cannot attack it. ML-DSA offers better performance for high-volume signing operations. Both are NIST-standardised and are the correct targets for new code-signing infrastructure.</p>
<h3>The CBOM dependency</h3>
<p>An organisation cannot migrate its code-signing infrastructure to post-quantum algorithms if it does not know which components are signed with which algorithms. The cryptographic bill of materials (CBOM) is the inventory required to drive migration. The NTIA minimum elements for SBOM (July 2021) established baseline software component transparency; CBOM extends that model to cryptographic dependency tracking. CycloneDX 1.6 (April 2024) added native CBOM support, and tooling integrations are in development across the ecosystem. Organisations that have not yet built a <a href="/insights/cbom-foundation-pqc-readiness">cryptographic asset inventory</a> cannot realistically scope their code-signing migration effort.</p>
<p>The regulatory pressure here is layered. NIS2 Article 21(2)(d) imposes supply chain security obligations on operators of essential services within the EU and EEA. The EU Cyber Resilience Act's Annex I Part II point (1) includes SBOM requirements for products with digital elements. UK organisations under the UK NIS Regulations 2018 (SI 2018/506) face equivalent supply chain obligations through a separate legislative framework. The <a href="/insights/container-image-signing-pqc-supply-chain">container image signing migration</a> problem is a practical implementation case for all of these requirements.</p>
9. Cryptojacking
Quantum relevance: No quantum change
<p>Cryptojacking uses victim compute to mine cryptocurrency. Bitcoin mining uses SHA-256; Grover's algorithm could in theory accelerate this by a square-root factor. Two things limit this. First, the qubit and gate-depth requirements are far beyond near-term hardware. Second, proof-of-work networks adjust difficulty dynamically, so a Grover speedup available to all miners produces no net advantage for the attacker; difficulty recalibrates upward. The threat is unauthorised resource consumption. Endpoint detection and process monitoring require no quantum-specific changes.</p>
10. Nation-State Harvest-Now-Decrypt-Later (HNDL)
Quantum relevance: Fundamental
<p>HNDL is the only entry in this list where quantum computing is not a modifier to an existing threat but the foundational condition for the threat itself. The model: a nation-state adversary intercepts and stores encrypted traffic today, government communications, financial transactions, defence contractor data, genomic databases, with the intent to decrypt it once a CRQC becomes available. The data is worth collecting now precisely because of what it will reveal in the future.</p>
<p>The analytical framework for urgency is Mosca's inequality. Let X represent the estimated time until a CRQC exists; Y the time required to migrate cryptographic infrastructure; Z the required secrecy lifetime of the data. If Y plus Z exceeds X, the migration should already be under way. For data with a secrecy lifetime extending to 2033 or beyond, and with the GRI 2024 assessment placing the probability of a CRQC at 14 to 34% by that date, the Mosca calculation is not hypothetical. It is a present-day risk management decision. The <a href="/insights/mosca-inequality-calculator-walkthrough-cisos">Mosca inequality walkthrough</a> covers how to apply this calculation to specific data categories.</p>
<p>The scope of current HNDL collection is not public, but the operational logic is straightforward: nation-state signals intelligence programmes that already intercept traffic at scale have a clear incentive to archive encrypted material that resists current decryption. NCSC, NSA, and their allied counterpart agencies have all published guidance acknowledging this threat as current and active. NSM-10 (4 May 2022) directed US federal agencies to prioritise migration of high-value assets specifically because of the HNDL exposure, with focus on data whose secrecy lifetime extends into the CRQC risk window.</p>
<p>The relevant migrations are two. First, hybrid TLS key exchange (ML-KEM-768 per FIPS 203 alongside X25519) for all traffic carrying long-lived sensitive data, to provide forward secrecy against future CRQC decryption. Second, re-encryption of stored sensitive data that was previously encrypted with RSA or ECC-wrapped keys. An HNDL attacker already has the ciphertext; the question is whether they will have the compute to decrypt it. <a href="/quantum-news/state-actor-hndl-campaigns-known-suspected">Known and suspected HNDL campaigns</a> and the specific data categories at greatest risk are covered in the linked analysis.</p>
<p>The "don't worry yet because CRQCs don't exist" framing is only valid for attacks that require present-day CRQC capability. For HNDL, data collection is happening now. The CRQC is the deferred decryption mechanism, not the prerequisite for the collection phase.</p>
Three Misconceptions Worth Naming
<p><strong>Quantum computers will break all encryption.</strong> Shor's algorithm breaks asymmetric encryption and discrete-logarithm key exchange. It does not break symmetric encryption. AES-256-GCM is not broken by Shor. Grover's algorithm halves effective symmetric key length, weakening AES-128 to around 64-bit equivalent security; NIST SP 800-57 Part 1 Rev 5 sets a 112-bit minimum security strength floor for newly deployed systems, which AES-128 no longer meets under Grover. AES-256-GCM remains materially intact. "All encryption breaks" is a simplification that leads security teams to misallocate effort.</p>
<p><strong>We do not need to act until CRQCs exist.</strong> This is only valid for attack categories requiring real-time CRQC capability. For HNDL, data is being collected now. A secrecy lifetime extending to 2033 or beyond means the harvest window is open regardless of whether a CRQC exists today.</p>
<p><strong>Quantum speedup is uniform across attack types.</strong> It is not. Shor applies to integer factorisation and discrete logarithm. Grover applies to unstructured search. Neither provides meaningful speedup for social engineering, application logic exploitation, volumetric flooding, or software vulnerability research. Seven of these ten attack categories are not quantum-relevant in any material sense.</p>
Assessing Your Own Exposure
<p>The three categories that require action (MITM, supply chain, HNDL) all require knowing what cryptographic algorithms are deployed across your estate before migration can begin. Discovery is the prerequisite. The <a href="/insights/cryptographic-inventory">cryptographic inventory guide</a> covers what a discovery programme looks like in practice. For a rapid assessment of where your organisation sits on the quantum exposure timeline, the Q-Day Timeline Risk Calculator on the QSECDEF tools page helps apply the Mosca inequality inputs to your specific data categories and migration capacity.</p>
<p>If you are working through the prioritisation question or scoping a PQC migration programme for your organisation, the team at Quantum Security Defence works directly with CISOs and security programme managers on exactly this sequencing challenge. Get in touch through the contact page.</p>
