<p>The terminology around quantum security has drifted badly enough that practitioners working from plausible-sounding assumptions are making procurement decisions, technical designs, and board presentations based on claims that do not hold up. These are not edge cases. The nine misconceptions below appear regularly in peer conversations, vendor materials, and internal risk assessments. Each one has a concrete consequence when acted upon.</p>

<h2>Misconception 1: "PQC and quantum cryptography mean the same thing"</h2>

<p>This is the most structurally damaging confusion because it redirects evaluation effort toward the wrong product category. Post-quantum cryptography (PQC) and quantum cryptography are two separate fields with almost no technical overlap.</p>

<p>PQC is classical mathematics running on classical computers, designed to resist attacks from quantum computers. NIST standardised four algorithms in 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206). These run on standard server hardware, standard network gear, and standard laptops. No photon sources. No quantum channels. No specialised hardware of any kind. Deploying ML-KEM is a software library update.</p>

<p>Quantum cryptography, in technical usage, refers primarily to quantum key distribution (QKD): protocols that use quantum mechanical properties of individual photons to distribute cryptographic keys. BB84, published by Bennett and Brassard in 1984, is the foundational protocol. QKD requires single-photon sources, single-photon detectors, and a dedicated quantum channel. Commercial systems from vendors including ID Quantique operate at distances of approximately 100 to 200 km on unrepeatered fibre. It is not software-deployable. It is not a library upgrade.</p>

<p>A practitioner who uses "quantum cryptography" to mean the PQC migration will evaluate QKD products when their regulatory obligation requires a TLS library upgrade, misinterpret NCSC and NSA guidance, and confuse their board on the cost and complexity of what is actually required. Both the NCSC and the NSA have published explicit position statements advising against relying on QKD as a substitute for PQC migration in most enterprise and government contexts. NCSC cites distance constraints, trusted relay node requirements, hardware supply chain risks, and cost as reasons QKD is unsuitable for most organisational deployments. NSA's CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87 for national security systems; QKD is not listed as an alternative.</p>

<p>The detailed technical treatment of PQC versus QKD is in the companion article <a href="/quantum-news/post-quantum-vs-quantum-cryptography-difference/">Post-Quantum Cryptography vs Quantum Cryptography: What Is the Difference?</a>. The present article proceeds on the basis that the reader understands this distinction and addresses subsequent misconceptions that arise even after it is resolved.</p>

<h2>Misconception 2: "'Quantum-safe' means fully migrated"</h2>

<p>The terms "quantum-proof," "quantum-safe," and "quantum-resistant" have no standardised definitions. No certification body issues a "quantum-safe" mark. No regulation defines the threshold a product must meet to carry the label. Vendors use these terms to describe anything from a product that implements ML-KEM in a single TLS endpoint to a product that has conducted a comprehensive PQC migration across all cryptographic functions.</p>

<p>A product that is "quantum-safe" in its TLS implementation may simultaneously use RSA-2048 for certificate signing, ECDH in its internal key management system, and legacy cipher suites on its management interface. None of those functions are covered by the TLS upgrade. The label is applied to the subset that was migrated, not to the product as a whole.</p>

<p>The right question is not "is this product quantum-safe?" That question cannot be answered by the vendor in any meaningful way without further specification. The question that produces useful information is: which specific cryptographic functions in this product implement which NIST FIPS-standardised post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA, or FN-DSA), at which parameter sets, with which FIPS 140-3 validation status, and which functions remain on classical algorithms? That question requires vendor-specific technical documentation, not marketing material.</p>

<p>NIST IR 8547 (November 2024) provides the authoritative algorithm status designations. RSA, ECDSA, ECDH, and DSA are designated "deprecated" (no new use from 2030) and then "disallowed" (no use from 2035) at all key sizes. A product that continues to use any of these algorithms in any function after those dates is non-compliant with NIST transition requirements, regardless of which components it has migrated.</p>

<h2>Misconception 3: "Longer RSA or ECC keys will protect us"</h2>

<p>The intuition is reasonable: if RSA-2048 is not enough, use RSA-4096. Against a classical attacker, that intuition is correct. RSA-4096 is approximately four times harder to break classically than RSA-2048 (superexponential classical complexity). Against Shor's algorithm on a cryptographically relevant quantum computer (CRQC), that intuition breaks down entirely.</p>

<p>Shor's algorithm provides an exponential speedup specifically for factoring large integers (breaking RSA) and solving the elliptic curve discrete logarithm problem (breaking ECDSA and ECDH). The critical technical point is that Shor's algorithm is polynomial in the key length. Factoring a 2048-bit number and a 4096-bit number are both polynomial-time problems once a CRQC can execute Shor's algorithm. More precisely, Shor's algorithm requires approximately O(n³) logical gate operations to factor an n-bit number, where n is the bit length of the modulus. This means moving from RSA-2048 to RSA-4096 roughly increases the quantum circuit depth by a factor of 8 (2³) — a manageable overhead for a sufficiently capable quantum computer, not a security category change. The polynomial factor between them is manageable with a larger, but not fundamentally different, quantum computer. The security scaling of RSA against quantum attack is polynomial; the security scaling of RSA against classical attack is superexponential. These are different mathematical regimes.</p>

<p>NIST IR 8547 (November 2024) confirms this by deprecating RSA at all key sizes from 2030. Not RSA-2048. All RSA. The same applies to ECDH and ECDSA at all curve sizes. The table in NIST IR 8547 does not include any RSA key length under the heading of post-quantum acceptable algorithms. There is no column for RSA-8192 with a note saying "acceptable until 2040." The algorithm category is deprecated. Key length is irrelevant.</p>

<p>The deeper technical treatment of why Shor's algorithm breaks RSA and ECC at all key sizes is in the companion article <a href="/quantum-news/shors-algorithm-rsa-ecc-quantum/">Shor's Algorithm: How RSA and ECC Are Broken by Quantum Computers</a>.</p>

<h2>Misconception 4: "AES-256 is broken by quantum computers"</h2>

<p>AES-256 is not broken by quantum computers under current understanding. The quantum attack on symmetric ciphers is Grover's algorithm, which provides a quadratic speedup for unstructured search problems. Applied to AES-256, Grover's algorithm reduces the effective security from 256 bits to approximately 128 bits. This is not a break. 128-bit symmetric security is a well-regarded security margin that the cryptographic community treats as strong for most applications.</p>

<p>AES-128 fares worse under Grover's analysis: effective security drops from 128 bits to approximately 64 bits, which is considered marginal. That is why NIST recommends AES-256 rather than AES-128 for post-quantum contexts, and NIST IR 8547 (November 2024) retains AES-256 as acceptable for post-quantum use.</p>

<p>The misconception is harmful because it misdirects attention. Organisations that believe AES-256 is broken will conclude that all their at-rest data is exposed and require a complete re-encryption operation. Neither conclusion is correct. What organisations should actually focus on is the key management layer: if their AES-256 data-at-rest keys are wrapped or distributed using RSA or ECDH, the AES-256 encryption is only as strong as its quantum-vulnerable key distribution mechanism. The encryption algorithm is secure; the key wrapping is the exposure. That is a different migration target, and a more tractable one.</p>

<h2>Misconception 5: "SHA-256 is broken by quantum computers"</h2>

<p>SHA-256 is not broken by quantum computers. The Grover speedup applies to preimage search: finding an input that produces a given hash output. Grover's algorithm reduces SHA-256's preimage resistance from 256 bits to approximately 128 bits. That remains a strong security margin for preimage resistance. Collision resistance, which relies on the birthday bound and requires different attack techniques, is not substantially improved by Grover's algorithm in the collision attack context.</p>

<p>NIST IR 8547 (November 2024) retains SHA-256 as acceptable for post-quantum use. SHA-384 and SHA-512 provide conservative post-quantum margins for applications that require additional headroom. SHA-1 was deprecated before post-quantum considerations arose, for classical cryptanalytic reasons; that deprecation is independent and stands.</p>

<p>The practical implication is the same as for AES: SHA-256 does not need to be replaced. The migration workload concentrates on asymmetric algorithms and key management infrastructure, not on hash functions used in existing systems.</p>

<h2>Misconception 6: "Post-quantum algorithms are mathematically unproven and risky"</h2>

<p>The four NIST-standardised PQC algorithms are not unproven. They completed an eight-year competitive public evaluation process running from 2016 to 2024. The process included multiple rounds of open submission, external cryptanalysis, and community scrutiny from university departments, national laboratories, and independent researchers. The algorithms that survived were standardised after several candidates were eliminated or withdrawn following successful attacks in earlier rounds. The process was designed to surface weaknesses.</p>

<p>ML-KEM security rests on the hardness of the Module Learning With Errors (MLWE) lattice problem. ML-DSA security relies on MLWE and Module Short Integer Solution (MSIS). SLH-DSA is the most conservative of the four: its security reduces to the collision resistance and pseudorandomness of the underlying hash functions, well-understood properties that do not depend on novel mathematical assumptions.</p>

<p>The objection "no formal proof of hardness" is technically accurate but misleading in context. RSA security relies on the presumed hardness of integer factoring, which is also not formally proved. The distinction that actually matters is not "proved hard" versus "not proved hard." It is "resilient to known quantum attacks" versus "broken by Shor's algorithm." ML-KEM and ML-DSA fall in the first category. RSA and ECDSA fall in the second. No known quantum algorithm attacks the MLWE problem. Shor's algorithm breaks RSA in polynomial time on a sufficiently capable quantum computer. Those are not equivalent positions.</p>

<h2>Misconception 7: "Once we deploy PQC, we're done"</h2>

<p>PQC migration addresses the vulnerability of key exchange and digital signature algorithms to quantum attack. It does not address side-channel attacks, which are distinct from algorithmic vulnerability and require separate countermeasures at the implementation level. Lattice-based algorithms have had timing vulnerabilities demonstrated in non-constant-time implementations. ML-KEM and ML-DSA both require careful constant-time implementation to prevent timing leakage; this is an engineering requirement, not an automatic consequence of using the correct algorithm.</p>

<p>NIST IR 8547 (November 2024) explicitly acknowledges that future algorithm transitions are likely. The document recommends cryptographic agility as a design principle: the ability to update cryptographic algorithms and key sizes across a system without requiring architectural rebuild. Organisations that implement ML-KEM in a hard-coded, non-agile way will face the same migration complexity in the future if standards evolve further. Building for agility is the architectural lesson from this migration cycle, and it remains relevant after the immediate PQC migration is complete.</p>

<p>Key management infrastructure, certificate chains, hardware security modules, and long-lived signing keys all require explicit attention beyond the initial protocol migration. NIST NCCoE SP 1800-38B describes the scope of a complete migration programme; the TLS layer is an early step, not a conclusion.</p>

<h2>Misconception 8: "Only asymmetric cryptography is affected"</h2>

<p>This misconception contains a kernel of truth but is operationally misleading in its typical consequences. The accurate statement is: symmetric encryption at AES-256 and hash functions at SHA-256 and above retain acceptable security margins against Grover's algorithm. The misleading implication practitioners often draw is therefore: "our data-at-rest encryption is fine, only the TLS layer needs attention."</p>

<p>That conclusion ignores the dependency chain. Symmetric key exchange uses asymmetric cryptography to distribute the symmetric key. An AES-256-encrypted database whose data encryption key (DEK) is wrapped by an RSA-2048 key encryption key (KEK) stored in an HSM is not post-quantum secure. The AES-256 layer is secure. The RSA-2048 key wrapping is not. A CRQC running Shor's algorithm on the harvested RSA-2048 public key material reconstructs the private key, unwraps the DEK, and decrypts the AES-256-protected data. The Grover analysis of AES-256 is irrelevant at that point.</p>

<p>The practical implication: organisations that have implemented AES-256 for data-at-rest encryption and believe their migration work is limited to TLS need to audit their key management layer. HSMs, key management servers, certificate authorities, and code-signing infrastructure are the components where asymmetric cryptography wraps the symmetric layer. That is the highest-priority migration target in many organisations. NIST NCCoE SP 1800-38B identifies key management infrastructure as a priority migration target precisely because of this dependency chain.</p>

<h2>Misconception 9: "Quantum computers are already breaking RSA"</h2>

<p>As of knowledge cutoff August 2025, no quantum computer has broken RSA-2048 or any operationally relevant RSA key size. Current quantum computers, including IBM's 1,000+ qubit processors and Google's Willow processor, are NISQ (Noisy Intermediate-Scale Quantum) devices. NISQ hardware lacks the error correction required to execute fault-tolerant logical qubit operations at the scale Shor's algorithm requires against RSA-2048. Gidney and Ekerå (2021) estimated that breaking RSA-2048 using a fault-tolerant quantum computer would require approximately 20 million noisy physical qubits. Current hardware is orders of magnitude below that threshold.</p>

<p>This misconception generates two opposite and equally unhelpful responses. The first is unnecessary immediate panic: organisations rush toward emergency spending based on a threat that does not yet exist. The second is complacency: people discover that current quantum computers cannot break RSA and conclude the threat is distant and manageable, reducing migration urgency.</p>

<p>Both responses are wrong for the same reason: the relevant threat is not current quantum capability. It is the harvest-now-decrypt-later (HNDL) model. Adversaries who collect encrypted data today for decryption once a CRQC exists create a migration urgency that is present now, well before a CRQC appears. The consensus estimate for CRQC arrival is approximately 2033 to 2035. Data with confidentiality requirements extending into that window is at risk from collection occurring today. Both facts are simultaneously true: current hardware cannot break RSA, and organisations with long-lived sensitive data must migrate now.</p>

<hr />

<h2>Summary reference: nine misconceptions and the corrections</h2>

<table>
  <thead>
    <tr>
      <th>Misconception</th>
      <th>The correction</th>
      <th>Key source</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>PQC and QKD mean the same thing</td>
      <td>PQC is classical maths on classical hardware; QKD is quantum physics on quantum hardware</td>
      <td>NIST FIPS 203/204/205/206; Bennett and Brassard (1984)</td>
    </tr>
    <tr>
      <td>"Quantum-safe" means fully migrated</td>
      <td>The label has no standardised definition; audit by algorithm, function, and FIPS 140-3 status</td>
      <td>NIST IR 8547 (November 2024)</td>
    </tr>
    <tr>
      <td>Longer RSA keys provide quantum protection</td>
      <td>Shor's algorithm scales as O(n³) in key length; RSA-4096 costs ~8x RSA-2048 in gate count, not exponentially more; all RSA key sizes deprecated from 2030</td>
      <td>Shor (1994); NIST IR 8547 (November 2024)</td>
    </tr>
    <tr>
      <td>AES-256 is broken by quantum computers</td>
      <td>Grover reduces effective security to 128 bits; AES-256 is not broken; key management is the exposure</td>
      <td>NIST IR 8547 (November 2024); Grover (1996)</td>
    </tr>
    <tr>
      <td>SHA-256 is broken by quantum computers</td>
      <td>Grover reduces preimage resistance to 128 bits; SHA-256 is retained in NIST IR 8547</td>
      <td>NIST IR 8547 (November 2024)</td>
    </tr>
    <tr>
      <td>PQC algorithms are mathematically unproven</td>
      <td>Eight-year NIST evaluation; no known quantum attack on MLWE; RSA is equally "unproved" yet broken by Shor</td>
      <td>NIST FIPS 203/204/205; Shor (1994)</td>
    </tr>
    <tr>
      <td>Deploying PQC completes the migration</td>
      <td>Side-channel risks remain; cryptographic agility is required for future transitions</td>
      <td>NIST IR 8547; NIST NCCoE SP 1800-38B</td>
    </tr>
    <tr>
      <td>Only asymmetric cryptography is affected</td>
      <td>AES-256 is secure; its key management layer (RSA/ECDH-wrapped KEKs) is the exposure</td>
      <td>NIST NCCoE SP 1800-38B</td>
    </tr>
    <tr>
      <td>Quantum computers are already breaking RSA</td>
      <td>Current NISQ hardware cannot run Shor's at RSA-2048 scale; the threat is HNDL, not current capability</td>
      <td>Gidney and Ekerå (2021); Mosca (2018)</td>
    </tr>
  </tbody>
</table>