Classical Cryptography at Risk | Post-Quantum Cryptography

The Foundations We Built Everything On

Modern digital security rests on a small number of mathematical problems that are easy to compute in one direction and astronomically difficult to reverse. Every TLS handshake, every SSH session, every signed software update, every encrypted email — all of them depend on the assumption that these problems will remain hard. Quantum computing invalidates that assumption.

Before examining what breaks, we need to understand exactly why these systems work and what makes them vulnerable.

RSA: The Integer Factorization Problem

How RSA Works

RSA, published by Rivest, Shamir, and Adleman in 1977, derives its security from the integer factorization problem. The setup is straightforward:

Choose two large primes p and q (each typically 1024–2048 bits).
Compute n = p × q. This is the public modulus.
Compute φ(n) = (p − 1)(q − 1) (Euler’s totient).
Choose a public exponent e (commonly 65537).
Compute the private exponent d ≡ e⁻¹ mod φ(n).

The public key is (n, e). The private key is d. Encryption computes c ≡ mᵉ mod n, and decryption computes m ≡ cᵈ mod n.

The security guarantee: given only n, finding p and q is computationally infeasible for sufficiently large key sizes. The best known classical algorithm for factoring — the General Number Field Sieve (GNFS) — runs in sub-exponential time:

L_n[1/3, (64/9)^(1/3)] ≈ exp((1.923 + o(1))(ln n)^(1/3)(ln ln n)^(2/3))

For a 2048-bit RSA modulus, GNFS would require roughly 2¹¹² operations — beyond the reach of any classical computer for the foreseeable future. This is why RSA-2048 has been considered safe for decades.

Why RSA Breaks Under Quantum Attack

Shor’s algorithm (1994) solves integer factorization in polynomial time on a quantum computer:

O((log n)² × (log log n) × (log log log n))

This is not a marginal speedup. It is a categorical change in complexity class. A sufficiently large, fault-tolerant quantum computer running Shor’s algorithm could factor a 2048-bit RSA modulus in hours, not millennia. Current estimates suggest this requires approximately 4,000–20,000 logical qubits (translating to millions of physical qubits with current error rates).

The critical insight: increasing the key size does not help. Shor’s algorithm scales polynomially with key length, so doubling the RSA key size only modestly increases the quantum computation required. There is no safe RSA key size against a quantum adversary.

Elliptic Curve Cryptography: The Discrete Logarithm Problem

How ECC Works

Elliptic curve cryptography, standardized in the late 1990s, operates over the group of points on an elliptic curve defined by an equation of the form:

y² = x³ + ax + b  (over a finite field F_p)

Points on this curve form an abelian group under a geometric addition operation. The security of ECC relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP):

Given points P and Q = kP on the curve (where kP means adding P to itself k times), find the scalar k.

For well-chosen curves (P-256, P-384, Curve25519, etc.), the best classical algorithms for ECDLP — Pollard’s rho and baby-step giant-step — run in O(√n) time, which means a 256-bit curve provides roughly 128 bits of classical security.

ECC’s advantage over RSA is efficiency: a 256-bit ECC key provides security comparable to a 3072-bit RSA key, with significantly smaller key sizes, faster computations, and lower bandwidth requirements. This is why ECC dominates modern deployments — TLS 1.3 uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) as its primary key exchange mechanism.

Why ECC Breaks Under Quantum Attack

Shor’s algorithm extends to the discrete logarithm problem on elliptic curves. A quantum computer can solve ECDLP in polynomial time, completely destroying ECC’s security advantage.

Worse, because ECC key sizes are already small (256–384 bits), the quantum resources required to break ECC are substantially less than those needed to break equivalent-strength RSA. Breaking P-256 requires roughly 2,330 logical qubits — significantly fewer than the approximately 4,099 logical qubits needed for RSA-2048.

This is a bitter irony: the efficiency that made ECC superior to RSA on classical computers makes it more vulnerable to quantum attack. Organizations that migrated from RSA to ECC for improved performance actually moved closer to quantum vulnerability, not further from it.

Diffie-Hellman Key Exchange: The Discrete Logarithm Problem (Finite Fields)

How DH Works

The Diffie-Hellman protocol (1976) enables two parties to establish a shared secret over an insecure channel. The classical version operates in the multiplicative group of integers modulo a prime p:

Alice and Bob agree on a large prime p and a generator g.
Alice chooses a secret a, computes A = gᵃ mod p, sends A to Bob.
Bob chooses a secret b, computes B = gᵇ mod p, sends B to Alice.
Both compute the shared secret: s = Bᵃ mod p = Aᵇ mod p = gᵃᵇ mod p.

An eavesdropper sees g, p, A, and B, but must solve the Computational Diffie-Hellman (CDH) problem to recover s. This is believed to be as hard as the Discrete Logarithm Problem (DLP) in the group.

Why DH Breaks Under Quantum Attack

Shor’s algorithm also solves the DLP in finite fields in polynomial time. Both classical DH and its elliptic curve variant (ECDH) are completely broken by a sufficiently powerful quantum computer. The same analysis that applies to RSA and ECC applies here — no increase in parameters can restore security.

Where Classical Cryptography Lives Today

The scope of the quantum threat becomes clear only when you map every system, protocol, and application that depends on RSA, ECC, or DH. The answer is: virtually everything.

Transport Layer Security (TLS)

TLS secures the majority of internet traffic. Every HTTPS connection, every API call, every web application session depends on it.

TLS Component	Classical Algorithm	Function
Key Exchange	ECDHE (X25519, P-256)	Establish session keys
Server Authentication	RSA-2048/4096, ECDSA (P-256)	Prove server identity
Client Authentication	RSA, ECDSA (mutual TLS)	Prove client identity
Certificate Chain	RSA, ECDSA signatures	Validate trust path to CA root

TLS 1.3 mandates ephemeral key exchange (forward secrecy), which protects past sessions from future key compromise — but not from quantum attack. An adversary recording TLS traffic today can decrypt it later once a quantum computer is available. This is the “harvest now, decrypt later” (HNDL) attack, and it means the threat is not future — it is present.

Secure Shell (SSH)

SSH protects remote administration of virtually every server and network device on the internet.

Key Exchange: ECDH (Curve25519), DH (group14, group16)
Host Authentication: Ed25519, ECDSA, RSA host keys
User Authentication: RSA/ECDSA/Ed25519 key pairs, certificates
Session Encryption: AES-256-GCM, ChaCha20-Poly1305 (symmetric — not directly broken, but key exchange is)

An attacker who breaks the key exchange can derive session keys and decrypt all traffic. An attacker who forges host keys can mount man-in-the-middle attacks. An attacker who recovers user private keys gains persistent access to every system those keys authorize.

Virtual Private Networks (VPNs)

Both IPsec and WireGuard depend on classical asymmetric cryptography:

IKEv2/IPsec: RSA or ECDSA certificates for authentication, DH or ECDH for key exchange
WireGuard: Curve25519 for key exchange, authentication via static public keys
OpenVPN: RSA/ECDSA certificates, DH/ECDH key exchange via TLS

VPNs are frequently used to protect the most sensitive corporate and government traffic. A quantum adversary that breaks VPN key exchange gains access to entire internal networks.

Public Key Infrastructure (PKI)

PKI is the trust backbone of the internet. Certificate Authorities (CAs) sign certificates using RSA or ECDSA. The entire X.509 certificate chain — from root CAs to intermediate CAs to leaf certificates — depends on the unforgeability of these signatures.

If an attacker can forge CA signatures, they can:

Issue fraudulent TLS certificates for any domain
Impersonate any server on the internet
Sign malicious software as legitimate
Undermine the entire web-of-trust model

Root CA certificates often have 20–30 year validity periods. Certificates issued today will still be in use when quantum computers may be operational. This is not a theoretical concern — it is a deployment timeline problem.

Code Signing and Software Distribution

Every major operating system and package manager verifies software integrity using digital signatures:

Platform	Signing Algorithm	Impact of Break
Windows Authenticode	RSA-2048/4096, ECDSA	Malware signed as legitimate Microsoft/vendor software
Apple Code Signing	ECDSA (P-256)	Trojanized apps pass Gatekeeper, notarization
Linux Package Managers (APT, RPM)	RSA (GPG), EdDSA	Repository compromise, supply chain attacks
Android APK Signing	RSA, ECDSA	Malicious app updates to billions of devices
Docker Content Trust	ECDSA (P-256)	Compromised container images in production
Firmware (UEFI Secure Boot)	RSA-2048	Persistent rootkits below the OS level

A quantum adversary that can forge code signatures has the most powerful supply chain attack vector ever conceived.

Email Security (S/MIME and PGP)

Encrypted and signed email remains a critical tool for government, legal, healthcare, and financial communications:

S/MIME: RSA or ECDSA certificates for signing and encryption, issued by CAs
PGP/GPG: RSA, DSA, or ECDSA/EdDSA keys in a web-of-trust model

Archived encrypted emails — attorney-client privileged communications, classified government messages, medical records — may retain legal and privacy significance for decades. HNDL attacks on email archives represent one of the highest-value quantum threat scenarios.

Cryptocurrency and Blockchain

Most cryptocurrencies derive address ownership from elliptic curve key pairs:

Bitcoin: secp256k1 (ECDSA)
Ethereum: secp256k1 (ECDSA), transitioning to BLS12-381
Other chains: Various ECC schemes

A quantum attacker who can solve ECDLP can derive private keys from public keys, enabling theft of funds from any address whose public key has been revealed (which occurs upon the first transaction from that address). The total cryptocurrency market represents hundreds of billions of dollars in value secured solely by ECC.

Internet of Things (IoT) and Embedded Systems

IoT devices present unique challenges:

Constrained resources: Many devices use ECC precisely because RSA key sizes are too large for their processors and memory
Long deployment lifetimes: Industrial IoT devices (SCADA, smart grid, medical devices) may operate for 15–30 years without firmware updates
Difficult or impossible to update: Many embedded devices have no secure update mechanism
Scale: Billions of deployed devices, each requiring individual migration

Devices deployed today with ECC-only cryptographic stacks may be vulnerable to quantum attack while still in active service, with no path to remediation.

The Quantum Vulnerability Map

Not all classical cryptographic primitives are equally affected by quantum computing. The impact depends on which quantum algorithm applies.

Shor’s Algorithm: Complete Breaks

Shor’s algorithm provides exponential speedup over the best classical algorithms for three specific problems:

Integer Factorization — breaks RSA
Discrete Logarithm (finite fields) — breaks DH, DSA
Elliptic Curve Discrete Logarithm — breaks ECDH, ECDSA, EdDSA

These are not partial weaknesses. Shor’s algorithm reduces the computational cost from sub-exponential or exponential to polynomial. The algorithms are completely broken — no parameter adjustment can restore security.

Grover’s Algorithm: Effective Key-Size Halving

Grover’s algorithm provides a quadratic speedup for unstructured search problems. Its impact on symmetric cryptography and hash functions is significant but manageable:

Primitive	Classical Security	Post-Quantum Security	Mitigation
AES-128	128-bit	64-bit	Upgrade to AES-256
AES-256	256-bit	128-bit	Already sufficient
SHA-256	256-bit (collision: 128-bit)	128-bit (collision: ~85-bit)	Upgrade to SHA-384/SHA-512
SHA-3-256	256-bit	128-bit	Upgrade to SHA-3-384/SHA-3-512
HMAC-SHA-256	256-bit	128-bit	Already sufficient for most uses
ChaCha20	256-bit	128-bit	Already sufficient
Poly1305	128-bit	64-bit	Combine with longer MAC

The mitigation for Grover’s attack is simple: double the key/output size. AES-256 provides 128-bit security against quantum adversaries, which remains well beyond the feasible attack threshold. This is why NIST and NSA guidance already recommends AES-256 and SHA-384 or larger for systems requiring long-term security.

Comprehensive Algorithm Vulnerability Table

Algorithm	Type	Common Key/Parameter Size	Classical Security (bits)	Post-Quantum Security (bits)	Quantum Threat	Status
RSA-2048	Asymmetric (encryption, signature)	2048-bit modulus	~112	0 (broken)	Shor’s	Must replace
RSA-3072	Asymmetric (encryption, signature)	3072-bit modulus	~128	0 (broken)	Shor’s	Must replace
RSA-4096	Asymmetric (encryption, signature)	4096-bit modulus	~140	0 (broken)	Shor’s	Must replace
ECDSA P-256	Digital signature	256-bit curve	~128	0 (broken)	Shor’s	Must replace
ECDSA P-384	Digital signature	384-bit curve	~192	0 (broken)	Shor’s	Must replace
Ed25519	Digital signature	255-bit curve	~128	0 (broken)	Shor’s	Must replace
ECDH (X25519)	Key exchange	255-bit curve	~128	0 (broken)	Shor’s	Must replace
ECDH (P-256)	Key exchange	256-bit curve	~128	0 (broken)	Shor’s	Must replace
DH-2048	Key exchange	2048-bit prime	~112	0 (broken)	Shor’s	Must replace
DSA-2048	Digital signature	2048-bit parameters	~112	0 (broken)	Shor’s	Must replace
AES-128	Symmetric encryption	128-bit key	128	64 (weakened)	Grover’s	Upgrade to AES-256
AES-256	Symmetric encryption	256-bit key	256	128 (adequate)	Grover’s	Sufficient
SHA-256	Hash function	256-bit output	128 (collision)	~85 (collision)	Grover’s	Upgrade to SHA-384+
SHA-384	Hash function	384-bit output	192 (collision)	~128 (collision)	Grover’s	Sufficient
SHA-512	Hash function	512-bit output	256 (collision)	~170 (collision)	Grover’s	Sufficient
HMAC-SHA-256	MAC	256-bit key	256	128 (adequate)	Grover’s	Sufficient

The pattern is stark: every asymmetric algorithm in widespread use is completely broken by Shor’s algorithm. Symmetric algorithms survive with parameter adjustments.

The Dependency Tree of Classical Cryptography

The following diagram illustrates how a quantum break of asymmetric cryptography cascades through modern digital infrastructure:

graph TD
    QUANTUM["⚛️ Cryptographically Relevant<br/>Quantum Computer (CRQC)"]

    QUANTUM -->|"Shor's Algorithm"| FACTOR["Integer Factorization<br/>Broken"]
    QUANTUM -->|"Shor's Algorithm"| ECDLP["Elliptic Curve DLP<br/>Broken"]
    QUANTUM -->|"Shor's Algorithm"| DLP["Discrete Logarithm<br/>Broken"]

    FACTOR --> RSA["RSA<br/>(All key sizes)"]
    ECDLP --> ECC["ECC / EdDSA<br/>(All curves)"]
    DLP --> DH["DH / DSA<br/>(All parameters)"]

    RSA --> TLS_AUTH["TLS Server/Client<br/>Authentication"]
    RSA --> PKI["X.509 PKI<br/>Certificate Chains"]
    RSA --> CODE_SIGN["Code Signing<br/>(Windows, Linux, Firmware)"]
    RSA --> EMAIL_RSA["S/MIME & PGP<br/>Email Encryption"]
    RSA --> SSH_RSA["SSH Host &<br/>User Auth (RSA)"]

    ECC --> TLS_KX["TLS 1.3<br/>Key Exchange (ECDHE)"]
    ECC --> SSH_ECC["SSH Key Exchange<br/>(Curve25519, ECDH)"]
    ECC --> VPN["VPN Key Exchange<br/>(WireGuard, IPsec)"]
    ECC --> CRYPTO_COIN["Cryptocurrency<br/>Wallet Ownership"]
    ECC --> CODE_SIGN_ECC["Code Signing<br/>(Apple, Android, Docker)"]
    ECC --> IOT["IoT Device<br/>Authentication"]

    DH --> TLS_LEGACY["Legacy TLS<br/>Key Exchange"]
    DH --> IPSEC["IKEv2/IPsec<br/>Key Exchange"]

    TLS_AUTH --> WEB["Web Security<br/>(HTTPS for all sites)"]
    TLS_KX --> WEB
    PKI --> WEB
    PKI --> CODE_SIGN
    PKI --> CODE_SIGN_ECC
    PKI --> EMAIL_RSA

    WEB --> ECOMMERCE["E-Commerce &<br/>Online Banking"]
    WEB --> API["API Security<br/>(REST, gRPC, GraphQL)"]
    WEB --> HEALTH["Healthcare Systems<br/>(HIPAA data)"]
    WEB --> GOV["Government Services<br/>(Citizen portals)"]

    SSH_RSA --> ADMIN["Server &<br/>Network Administration"]
    SSH_ECC --> ADMIN
    ADMIN --> CI_CD["CI/CD Pipelines"]
    ADMIN --> CLOUD["Cloud Infrastructure<br/>Management"]

    VPN --> CORP["Corporate Network<br/>Access"]
    IPSEC --> CORP
    CORP --> INTERNAL["Internal Applications<br/>& Databases"]

    CODE_SIGN --> SUPPLY["Software Supply Chain"]
    CODE_SIGN_ECC --> SUPPLY
    SUPPLY --> UPDATES["OS & Application<br/>Updates (billions of devices)"]

    IOT --> SCADA["Industrial Control<br/>Systems (SCADA/ICS)"]
    IOT --> SMART_GRID["Smart Grid &<br/>Energy Infrastructure"]
    IOT --> MEDICAL["Medical Devices"]

    CRYPTO_COIN --> DEFI["DeFi Protocols &<br/>Digital Assets"]

    style QUANTUM fill:#ff4444,color:#fff
    style FACTOR fill:#ff6666,color:#fff
    style ECDLP fill:#ff6666,color:#fff
    style DLP fill:#ff6666,color:#fff
    style RSA fill:#ff8888,color:#000
    style ECC fill:#ff8888,color:#000
    style DH fill:#ff8888,color:#000

The diagram reveals a critical architectural flaw in modern cybersecurity: a single mathematical breakthrough (Shor’s algorithm on a CRQC) cascades through every layer of digital trust. There are no firewalls between these dependencies. The asymmetric cryptography layer is a single point of failure for the entire digital ecosystem.

What Happens If We Do Nothing

The consequences of failing to migrate are not abstract. They follow a predictable sequence that security professionals must understand and communicate to leadership.

Phase 1: Harvest Now, Decrypt Later (Happening Now)

Nation-state adversaries are already collecting encrypted traffic at scale. Intelligence agencies — particularly those of major powers — have the storage capacity, collection infrastructure (submarine cable taps, ISP partnerships, satellite intercepts), and strategic motivation to archive:

Diplomatic communications
Military command and control traffic
Corporate intellectual property (M&A discussions, trade secrets, research data)
Healthcare records and genetic data
Financial transaction data
Attorney-client privileged communications

This is not speculation. The operational value of signals intelligence is well established, and the marginal cost of storing additional encrypted traffic is negligible. Every day that passes generates more encrypted data that will become readable once a CRQC is operational.

The data most vulnerable to HNDL attacks is information that retains value for decades: state secrets (classified for 25–75 years), medical records (lifetime relevance), intellectual property (long-term competitive advantage), and personal communications (permanent privacy implications).

Phase 2: First Demonstrations (Estimated 2028–2035)

When the first cryptographically relevant quantum computer demonstrates factoring of a key size used in production systems (even a reduced-strength demonstration), the impact will be immediate:

Market panic in financial sectors dependent on PKI and digital signatures
Regulatory scramble as compliance frameworks (PCI DSS, HIPAA, FedRAMP) rush to mandate PQC
Insurance implications as cyber insurance policies re-evaluate coverage for quantum-vulnerable systems
Trust collapse in certificate authorities whose root keys may be compromised

Organizations that have not begun migration will face a crisis timeline measured in months, not years.

Phase 3: Operational Quantum Attacks (Estimated 2030–2040)

Once CRQCs are operational and accessible (initially to nation-states, later to well-funded threat actors):

TLS interception at scale: All recorded HTTPS traffic becomes readable. No retroactive protection is possible.
PKI collapse: Certificate authorities must be re-established with quantum-resistant algorithms. The transition period creates a window where trust cannot be reliably established.
Identity infrastructure failure: Every digital identity system based on asymmetric cryptography (federation, SSO, FIDO2 with ECC) must be rebuilt.
Cryptocurrency theft: Addresses whose public keys have been exposed (any address that has sent a transaction) become vulnerable. Trillions in notional value could be at risk.
Firmware and boot chain compromise: Secure Boot signatures become forgeable. Persistent, undetectable rootkits become feasible at a scale previously impossible.

Phase 4: Cascading Failures

The deepest danger is cascade. Modern systems are interconnected, and cryptographic failures propagate:

A forged CA certificate enables a fraudulent TLS certificate
The fraudulent certificate enables a man-in-the-middle attack on a software update server
The MITM attack delivers malware signed with a forged code-signing certificate
The malware compromises CI/CD pipelines, which push trojanized builds to production
Compromised production systems leak credentials for cloud infrastructure
Cloud infrastructure compromise exposes databases, backups, and disaster recovery systems

Each step leverages the previous cryptographic failure. The entire chain of trust unravels from the single point of asymmetric cryptography failure.

The Cryptographic Debt Problem

The software industry is familiar with “technical debt” — the accumulated cost of expedient decisions that defer proper engineering. Cryptographic debt is the same concept applied to deployed cryptographic systems, and it is vastly more dangerous because it cannot be repaid incrementally.

Dimensions of Cryptographic Debt

Temporal debt: Cryptographic systems deployed years or decades ago use algorithms and key sizes that were appropriate at the time but are now approaching vulnerability. RSA-1024 certificates still exist in internal PKI deployments. Many organizations have no inventory of where classical cryptography is used.

Embedded debt: Cryptographic implementations baked into firmware, hardware security modules (HSMs), smart cards, and IoT devices cannot be easily updated. A manufacturing plant running PLCs with 15-year-old firmware has no migration path that does not involve physical replacement.

Protocol debt: Standards like X.509, S/MIME, and IPsec were designed around RSA and ECC. Post-quantum replacements have larger key sizes and different performance characteristics that may not fit within existing protocol message size limits, latency budgets, or bandwidth constraints.

Supply chain debt: Organizations do not control the cryptography in their third-party dependencies. A company may migrate its own systems to PQC, but remain vulnerable through a vendor’s VPN appliance, a partner’s API gateway, or a cloud provider’s internal infrastructure.

Knowledge debt: The cryptographic engineering talent pool is small. Most development teams lack the expertise to evaluate PQC algorithms, implement hybrid schemes correctly, or validate that a migration has not introduced new vulnerabilities. The demand for PQC expertise will far exceed supply during the transition.

Quantifying the Debt

Consider a mid-size enterprise with:

500 TLS certificates across internal and external services
10,000 SSH key pairs for system administration
200 VPN tunnels connecting offices and cloud infrastructure
50 code-signing certificates for internal tools and configurations
5,000 IoT devices with embedded ECC keys
3 hardware security modules storing root keys
20 third-party SaaS integrations using mutual TLS

Every one of these items must be inventoried, assessed, scheduled for migration, tested, and deployed — without disrupting operations. The enterprise must also coordinate with CAs, hardware vendors, cloud providers, and SaaS partners on their migration timelines.

This is not a weekend project. Realistic migration timelines for large organizations span 5–10 years. Given current quantum computing trajectory estimates, organizations that have not started planning are already behind.

The Timeline Is Shorter Than You Think

A common objection to PQC migration urgency is that large-scale quantum computers are “decades away.” This argument fails on multiple grounds:

Mosca’s Theorem provides a clear framework. If:

x = the number of years you need your data to remain confidential
y = the number of years it will take to migrate your systems to PQC
z = the number of years until a CRQC is available

Then you must begin migration when x + y > z.

For data that must remain confidential for 20 years (health records, state secrets, long-lived IP) and systems that will take 10 years to migrate, the migration trigger fires when a CRQC is expected within 30 years. By most estimates, we have already passed this threshold.

gantt
    title Mosca's Theorem — Why Migration Must Start Now
    dateFormat YYYY
    axisFormat %Y

    section Data Sensitivity Window (x)
    Classified data confidentiality requirement (25 years)    :data, 2026, 2051

    section Migration Duration (y)
    Cryptographic inventory & assessment                      :crit, inv, 2026, 2028
    Standards finalization & vendor support                   :std, 2027, 2029
    Implementation & testing                                  :crit, impl, 2028, 2032
    Full deployment & legacy retirement                       :crit, deploy, 2031, 2036

    section Quantum Threat Window (z)
    Optimistic CRQC estimate                                  :crit, done, quantum_opt, 2033, 2035
    Moderate CRQC estimate                                    :quantum_mod, 2035, 2040
    Conservative CRQC estimate                                :quantum_con, 2040, 2045

    section HNDL Exposure
    Data harvested today decryptable upon CRQC arrival        :crit, hndl, 2026, 2035

The Gantt chart makes the urgency visible: the migration window and the threat window already overlap under optimistic quantum timelines. Under moderate timelines, organizations beginning migration today will complete it with little margin. Under conservative timelines, there is still time — but no organization can afford to bet its security posture on the most optimistic estimate of adversary capability.

Real-World Threat Scenarios

Understanding the quantum threat in the abstract is insufficient. Security professionals need concrete scenarios to drive risk assessments and board-level conversations.

Scenario 1: Retroactive Diplomatic Espionage

A nation-state intelligence agency has been recording encrypted diplomatic cable traffic between allied governments since 2015. The traffic is protected by TLS 1.2 with ECDHE-RSA key exchange and AES-256-GCM. The symmetric encryption (AES-256) will remain secure post-quantum, but the key exchange (ECDHE) is vulnerable.

Once a CRQC is available, the agency can:

Extract the ECDHE ephemeral public keys from recorded TLS handshakes
Solve the ECDLP for each handshake to recover the shared secret
Derive the AES session keys from the recovered shared secret
Decrypt every recorded session

Result: A decade of diplomatic communications — negotiating positions, intelligence assessments, military planning — becomes readable overnight. Forward secrecy, which was designed to protect against classical key compromise, provides zero protection against quantum key recovery because the ephemeral keys themselves are broken.

Scenario 2: PKI Root Key Compromise

A certificate authority’s RSA-4096 root key has been in service since 2018, with a 30-year validity period expiring in 2048. A quantum adversary factors the root key’s modulus and can now:

Issue certificates for any domain, signed by the compromised root
These certificates will be trusted by every browser and operating system that includes the root in its trust store
Mount transparent MITM attacks against any HTTPS service
Sign malware that passes operating system code-signing verification (if the root is cross-signed with code-signing capabilities)

Result: The entire trust chain beneath this root — potentially millions of certificates — becomes untrustworthy. Revocation of a root CA is an extraordinary event that cascades across the internet, breaking legitimate services that depend on certificates chained to that root.

Scenario 3: Cryptocurrency Mass Theft

Bitcoin’s ECDSA implementation on secp256k1 exposes public keys when addresses are reused or when transactions are broadcast to the mempool but not yet confirmed. A quantum attacker can:

Monitor the Bitcoin mempool for unconfirmed transactions
Extract the sender’s public key from the transaction
Compute the private key via Shor’s algorithm on the ECDLP
Create a competing transaction sending the funds to an attacker-controlled address with a higher fee
The attacker’s transaction confirms first, stealing the funds

For addresses that have previously sent transactions (public key already on the blockchain), the attacker does not even need to race — they can derive the private key at leisure and sweep the balance at any time.

Result: Addresses holding an estimated 4–5 million BTC (those with exposed public keys) become immediately vulnerable. The market impact would be catastrophic, potentially destroying confidence in all ECC-based cryptocurrencies simultaneously.

Scenario 4: IoT Infrastructure Attack

A nation’s smart grid deployment uses ECDSA P-256 for device authentication between smart meters, substations, and the utility’s control center. The devices were deployed starting in 2020 with a planned 20-year service life. They have no remote firmware update capability — a deliberate security design decision to prevent remote code execution attacks.

A quantum adversary derives the ECDSA private keys for substation controllers and can:

Impersonate legitimate control messages
Issue commands to disconnect load, alter voltage regulation, or disable protective relays
Coordinate attacks across multiple substations simultaneously
Cause cascading grid failures affecting millions of people

Result: Critical infrastructure with no remediation path short of physical replacement of every device. The cost runs into billions; the timeline for replacement spans years; the vulnerability window remains open throughout.

Quantum Computing Progress: Where Are We?

Security professionals must track quantum computing milestones to calibrate urgency. As of early 2026, the landscape is as follows:

Current State of Quantum Hardware

Vendor	Qubit Count (Physical)	Qubit Type	Key Milestone
IBM	1,121 (Condor, 2023)	Superconducting	Targeting 100,000+ qubits by 2033
Google	105 (Willow, 2024)	Superconducting	Demonstrated quantum error correction below threshold
Quantinuum	56 (H2, 2024)	Trapped ion	Highest reported quantum volume
Microsoft	Logical qubits demonstrated (2025)	Topological	Claimed topological qubit breakthrough
PsiQuantum	Targeting >1M physical qubits	Photonic	Fab partnership with GlobalFoundries
Atom Computing	1,200+ (2023)	Neutral atom	Largest qubit count (neutral atom)
IonQ	36 algorithmic qubits (2024)	Trapped ion	Focus on error-corrected logical qubits

The Gap Between Current Hardware and Cryptographic Relevance

Current quantum computers cannot break any cryptographic system in production use. The gap is enormous but closing:

To break RSA-2048: Estimated 4,099 logical qubits, each requiring 1,000–10,000 physical qubits depending on error correction overhead. Total: ~4 million to 40 million physical qubits.
To break ECC P-256: Estimated 2,330 logical qubits with similar overhead. Total: ~2 million to 23 million physical qubits.
Current largest quantum computers: ~1,000–1,200 physical qubits with error rates far above what is needed for Shor’s algorithm.

The gap is roughly three to four orders of magnitude in qubit count, plus a significant improvement in error rates and coherence times. However, the field has historically advanced faster than predictions:

In 2019, experts estimated quantum advantage (for any problem) was 5–10 years away. Google demonstrated it months later.
Error correction breakthroughs in 2023–2025 (Google Willow, Microsoft topological claims) have accelerated timelines.
Major governments (US, China, EU) are investing tens of billions in quantum computing R&D, with explicit goals of achieving cryptographic relevance.

Classified Programs

Public quantum computing progress represents the lower bound of the state of the art. Intelligence agencies and military research programs operate classified quantum computing efforts with budgets that dwarf academic and commercial programs. The NSA’s public statements urging PQC migration since 2015 may reflect knowledge of classified progress that narrows the publicly estimated timeline.

Security professionals must plan against the possibility of faster-than-expected progress, not the median estimate.

Timeline Estimates and Confidence Intervals

The cryptographic community uses the concept of a Cryptographically Relevant Quantum Computer (CRQC) — a quantum computer capable of running Shor’s algorithm against production key sizes in a practical timeframe. Estimates for CRQC arrival vary widely:

Source / Community	Earliest Estimate	Most Likely Estimate	Latest Estimate
Quantum computing vendors	2029–2032	2033–2037	2040+
Academic researchers	2033–2035	2038–2045	2050+
Intelligence community (public statements)	“Sooner than expected”	Not disclosed	Not disclosed
Global Risk Institute annual survey	2030 (17% likelihood)	2035 (33% likelihood)	2040+

The variance in these estimates reflects genuine uncertainty in engineering timelines, not disagreement about the physics. The underlying mathematics of Shor’s algorithm is settled — the question is purely about hardware engineering. Given the level of global investment and the strategic importance of the technology, security planning should use the 25th percentile estimate (aggressive timeline) rather than the median.

One additional factor is often overlooked: a CRQC does not need to be publicly announced to be a threat. A nation-state that achieves cryptographic relevance first has every incentive to keep the capability classified and exploit it covertly. The first indication that a CRQC exists may not be a press release — it may be an intelligence breach whose root cause is never publicly attributed.

The Cryptographic Inventory Challenge

Before any migration can begin, organizations must answer a deceptively simple question: where is classical cryptography used in our environment? In practice, this is one of the hardest problems in PQC migration because cryptographic usage is pervasive, implicit, and poorly documented.

What a Cryptographic Inventory Must Capture

A complete inventory includes:

Certificates: Every X.509 certificate (TLS, client auth, code signing, S/MIME), its algorithm, key size, issuer, validity period, and what systems depend on it
Key pairs: SSH keys, GPG/PGP keys, API signing keys, JWT signing keys, with their algorithms and locations
Protocol configurations: TLS cipher suite configuration for every endpoint, SSH algorithm negotiation settings, VPN key exchange parameters
Hardware: HSMs, TPMs, smart cards, and their supported algorithm lists and firmware update capabilities
Third-party dependencies: Cloud provider encryption settings, SaaS integrations using mutual TLS, CDN TLS termination configurations
Embedded and IoT: Firmware cryptographic libraries, bootloader signature verification algorithms, device identity key types
Data at rest: Encrypted databases, encrypted backups, encrypted archives — what algorithm protects them and where are the keys stored?
Custom applications: Internal applications that perform cryptographic operations directly (signing, encryption, key exchange) rather than relying on TLS

Discovery Approaches

Method	Coverage	Effort	Limitations
Network scanning (TLS enumeration)	External-facing TLS endpoints	Low	Misses internal services, non-TLS protocols
Certificate manager inventory	Managed certificates	Low	Misses self-signed, developer, and legacy certificates
Code scanning (SAST for crypto APIs)	Application-level crypto	Medium	Misses dynamically loaded libraries, configuration-driven crypto
Configuration audit (SSH, VPN, IPsec)	Infrastructure crypto	Medium	Requires access to all devices and configurations
Vendor questionnaires	Third-party dependencies	High	Depends on vendor transparency and accuracy
Binary analysis	Firmware and embedded systems	Very High	Requires reverse engineering expertise
HSM/KMS audit	Hardware-protected keys	Medium	May require vendor support for full enumeration

No single method provides complete coverage. A thorough cryptographic inventory typically requires all of these approaches combined, iterated over months, with ongoing monitoring for new deployments.

The Visibility Gap

Most organizations discover during inventory that their cryptographic footprint is 3–10 times larger than initially estimated. Shadow IT, developer-created certificates, legacy systems with hardcoded keys, and third-party integrations consistently surprise even well-managed enterprises. This visibility gap is itself a security risk — you cannot protect what you cannot see, and you cannot migrate what you have not inventoried.

Regulatory and Compliance Landscape

The regulatory environment is shifting to mandate PQC preparation:

NSA CNSA 2.0 (2022): National Security Systems must begin PQC migration. Software and firmware signing must use PQC by 2025. Web servers and cloud services by 2025. VPNs and routers by 2026. Legacy systems fully migrated by 2030–2033.
NIST SP 800-208 (2020): Recommendation for stateful hash-based signature schemes (XMSS, LMS) for firmware signing.
NIST FIPS 203, 204, 205 (2024): Finalized PQC standards for ML-KEM, ML-DSA, and SLH-DSA.
White House National Security Memorandum NSM-10 (2022): Directs federal agencies to inventory quantum-vulnerable cryptographic systems and develop migration plans.
European Union: ENISA and BSI guidance recommending PQC readiness assessments and hybrid deployments.
Financial Sector: PCI DSS and banking regulators are expected to issue PQC guidance as NIST standards mature.

Organizations in regulated industries that have not begun cryptographic inventory and PQC planning are accumulating compliance risk in addition to security risk.

What Comes Next

Understanding the threat is necessary but not sufficient. The remainder of this topic provides the knowledge and tools to act:

NIST Post-Quantum Standards — The finalized algorithms (ML-KEM, ML-DSA, SLH-DSA) and their design rationale
Lattice-Based Cryptography — Deep dive into the mathematical foundations of ML-KEM and ML-DSA
Hash-Based Signatures — How SLH-DSA and XMSS achieve quantum resistance from hash functions alone
Code-Based and Other Schemes — McEliece, BIKE, and alternative PQC families
Hybrid Cryptography — Combining classical and post-quantum algorithms for defense in depth
PQC in TLS and Web PKI — Practical deployment in the protocol that secures the web
Migration Strategy and Planning — Frameworks for organizational PQC transition
Cryptographic Agility — Designing systems that can swap algorithms without rebuilding
Implementation and Performance — Benchmarks, side channels, and engineering considerations

The quantum threat to classical cryptography is not a question of if but when. The only variable organizations control is whether they will be ready.

Frequently Misunderstood Aspects of the Quantum Threat

Several misconceptions about the quantum threat persist even among experienced security professionals. Addressing them directly is important for accurate risk assessment.

”We Can Just Increase Key Sizes”

This is true for symmetric algorithms (AES-128 to AES-256) and hash functions (SHA-256 to SHA-384), where Grover’s algorithm provides only a quadratic speedup. It is completely false for asymmetric algorithms. Shor’s algorithm achieves a super-polynomial speedup — moving from sub-exponential classical complexity to polynomial quantum complexity. Doubling an RSA key from 2048 to 4096 bits increases the quantum computation required by a small polynomial factor, not an exponential one. There is no RSA key size that is safe against Shor’s algorithm on a sufficiently large quantum computer.

”Quantum Computers Will Never Be Large Enough”

This argument conflates engineering difficulty with impossibility. Transistor counts in classical processors have scaled from thousands to billions over 50 years. Quantum computing is on a steeper growth curve in its early stages. More importantly, security decisions cannot be based on the assumption that an adversary’s capability will plateau. The history of cryptanalysis is a history of “impossible” attacks becoming routine.

”Symmetric Cryptography Is Fine, So Most Data Is Safe”

While AES-256 is quantum-resistant, the session keys for AES are established using asymmetric key exchange (ECDHE, RSA key transport). Breaking the key exchange reveals the symmetric key. The strength of the symmetric cipher is irrelevant if the key derivation is compromised. This is why TLS traffic encrypted with AES-256-GCM is still vulnerable — the AES key was negotiated via ECDHE, and that negotiation is quantum-breakable.

”This Only Matters for Government and Military”

The quantum threat affects every entity that uses public-key cryptography, which is every entity on the internet. Healthcare organizations have patient data with lifetime confidentiality requirements. Law firms have privileged communications. Manufacturers have trade secrets and industrial control systems. Financial institutions have transaction records and authentication infrastructure. The threat is universal; only the urgency varies based on data sensitivity and system lifespan.

”Post-Quantum Algorithms Are Not Proven Yet”

While PQC algorithms have shorter track records than RSA (published 1977) or ECC (published 1985), the NIST PQC standardization process ran from 2016 to 2024 — eight years of intensive global cryptanalysis. ML-KEM and ML-DSA are based on lattice problems that have been studied since the 1990s. SLH-DSA relies on hash function security, which is among the best-understood areas of cryptography. No cryptographic algorithm carries zero risk, but the standardized PQC algorithms have been scrutinized far more rigorously before standardization than RSA or ECC were at their time of initial deployment. The risks of not migrating now far exceed the risks of adopting NIST-standardized PQC.

”Quantum Computers Will Break Everything, Including AES”

This conflation of asymmetric and symmetric vulnerability leads to either paralysis (“nothing is safe, so why bother migrating”) or misallocated resources (rebuilding symmetric infrastructure that does not need replacement). Grover’s algorithm provides a quadratic speedup against symmetric primitives, effectively halving the security level. AES-256 retains 128-bit security against quantum adversaries — a level that remains computationally infeasible. The actionable insight is narrow and specific: replace asymmetric algorithms, upgrade symmetric key sizes where they are below 256 bits, and leave the rest alone.

”We Have Plenty of Time Because Quantum Computers Are Years Away”

This argument ignores two critical factors. First, migration takes years — cryptographic inventory, vendor coordination, testing, deployment, and legacy retirement for a large enterprise is a 5–10 year program. Second, the HNDL threat is current — adversaries are collecting encrypted data now for future decryption. For any data that must remain confidential beyond the estimated CRQC arrival date, the migration deadline has already passed. The correct framing is not “when will quantum computers arrive?” but “when will the data I am protecting today lose its sensitivity?” For most organizations, the answer to the second question is “long after quantum computers arrive.”

Key Takeaways

RSA, ECC, and DH are completely broken by Shor’s algorithm — no parameter increase can save them.
Symmetric algorithms survive quantum attack with doubled key sizes (AES-256, SHA-384+).
The threat is already active — harvest now, decrypt later means today’s encrypted traffic is at risk.
Cryptographic debt is real — decades of deployed systems cannot be migrated overnight.
Mosca’s Theorem demonstrates that migration must begin now for any data with long-term confidentiality requirements.
The cascade risk is the most dangerous aspect — a single cryptographic break propagates through the entire digital trust infrastructure.

The first step is always the same: know what you have. A complete cryptographic inventory — every key, certificate, algorithm, and protocol in your environment — is the foundation of any migration strategy. Without it, you are planning a journey without a map.