What Is Quantum Computing and Why Does It Threaten Encryption?

For most of the past three decades, the encryption protecting your organization’s data has been anchored in a single bet: factoring large numbers is computationally hard. RSA-2048 is considered secure not because anyone has proved it unbreakable, but because no classical computer has ever come close to cracking it in a practical timeframe. Quantum computing is now posing a credible challenge to that assumption. The concern is not that quantum computers can break modern cryptographic systems today; current quantum hardware remains noisy and far from the scale needed to threaten real-world key sizes. What has changed is the Harvest Now, Decrypt Later (HNDL) threat: data harvested and stored today can be decrypted the moment a capable quantum machine arrives. NIST finalized FIPS 203, 204, and 205 in August 2024, and the recommended action is to begin with a cryptographic asset inventory immediately, because migration planning is impossible without it. For the migration planning steps and implementation checklist, see Unlocking the Quantum Era: Essential Steps for Post-Quantum Cryptography Readiness.

Quick Answer: Why Does Quantum Computing Threaten Encryption?

Quantum computing threatens encryption because Shor’s algorithm, running on a sufficiently scaled quantum computer, reduces integer factoring and discrete logarithm problems to polynomial time. RSA relies on integer factoring; ECC relies on discrete logarithm hardness; both collapse against Shor’s algorithm regardless of key size. The threat is not hypothetical: HNDL means adversaries are archiving encrypted data today for future decryption. NIST finalized three post-quantum cryptography (PQC) standards in August 2024, and CNSA 2.0 sets binding deadlines for National Security Systems starting January 2027. For organizations outside the federal supply chain, HNDL exposure alone makes inaction a risk management failure.

What is Quantum Computing?

Classical computers encode information as bits, with each bit holding exactly 0 or 1 at any given moment. Quantum computers use quantum bits, or qubits, which exploit superposition to exist as a combination of 0 and 1 simultaneously until measured. A system of n qubits can represent exponentially many states at the same time rather than just one.

Entanglement links qubits so that their states are correlated in ways classical bits cannot replicate, and interference amplifies the probability amplitude of correct computation paths while suppressing incorrect ones. These three properties, superposition, entanglement, and interference, give quantum computers a fundamentally different computational profile from anything classical hardware can achieve.

That profile does not make quantum computers universally faster. For most problems, a quantum computer offers no advantage over a classical machine. The gain is specific to problems whose mathematical structure quantum algorithms can directly exploit. The two classes that matter for cryptography are integer factoring and the discrete logarithm problem. RSA relies entirely on integer factoring; elliptic curve cryptography (ECC) rests on the discrete logarithm problem. Both assumptions hold against any known classical algorithm at practical key sizes. They do not hold against a sufficiently scaled quantum computer running Shor’s algorithm.

Who Needs to Act and Why

The quantum threat is not confined to defense agencies or classified systems. Federal agencies subject to FISMA, contractors and vendors supplying products or services to National Security Systems (NSS), and commercial enterprises holding data with long-term confidentiality requirements all face material exposure.

Commercial National Security Algorithm Suite (CNSA) 2.0 requirements flow down through the federal supply chain, meaning a commercial organization supplying software, hardware, or services to an NSS environment inherits PQC compliance obligations regardless of whether it handles classified data directly.

For organizations outside the federal supply chain entirely, the HNDL threat applies independently. Certain industries carry disproportionate HNDL exposure because the data they generate today retains confidentiality value for decades. In healthcare, patient records, genomic data, and clinical trial results are subject to long-term privacy obligations under HIPAA. Financial institutions hold transaction histories, proprietary trading models, and client portfolios whose strategic value persists long after the underlying activity concludes. Law firms manage privileged communications and litigation strategy. Critical infrastructure operators transmit operational and control system data whose exposure could enable targeted disruption of physical systems.

How a Quantum Computer Actually Breaks Encryption

RSA and elliptic curve cryptography have protected sensitive data for decades by relying on mathematical problems that classical computers cannot solve at scale. The algorithm that matters most here is Shor’s algorithm, developed by mathematician Peter Shor in 1994. Shor’s algorithm can factor large integers in polynomial time on a quantum computer.

RSA encryption derives its security entirely from the assumption that factoring large integers is computationally infeasible. A 2048-bit RSA key is considered computationally infeasible to factor using known classical techniques. A sufficiently capable quantum computer running Shor’s algorithm could accomplish the same task in polynomial time. The same applies to ECC: the elliptic curve discrete logarithm problem is similarly reduced to polynomial time by Shor’s algorithm. RSA, ECC including ECDH and ECDSA, and finite-field Diffie-Hellman key exchange all collapse against this single quantum algorithm.

Symmetric cryptography faces a lesser but still meaningful threat. Grover’s algorithm provides a quadratic speedup for brute-force searches, effectively reducing the security of a k-bit symmetric key to roughly k/2 bits against an ideal quantum adversary. AES-256 provides the wider security margin and is the recommended choice for post-quantum contexts. The quantum threat to symmetric algorithms is a problem of key size, not algorithm design. The threat to asymmetric algorithms is existential.

Harvest Now, Decrypt Later Threat

The standard framing of the quantum threat places it in the future: when a cryptographically relevant quantum computer exists, then encryption will be at risk. That framing is accurate but incomplete. It ignores the fact that attackers do not need to break encryption today to benefit from a quantum computer tomorrow. They only need to collect encrypted data today and store it until decryption becomes possible.

This strategy, widely referred to as HNDL, converts a future capability into a present-day risk. Nation-state actors and advanced persistent threat groups are widely assessed to be engaged in bulk interception and archival of encrypted traffic, a threat vector both CISA and NSA have cited in their PQC migration guidance as a primary driver for accelerating migration timelines. Storage costs have dropped to the point where a well-resourced adversary can easily archive intercepted ciphertext at scale.

The HNDL risk has a specific implication for planning: any data that needs to remain confidential beyond the point at which quantum computers become viable is already at risk. If your organization retains sensitive data for years beyond the point at which a capable quantum computer could realistically exist, or if the data your organization transmits today has long-term strategic value, the threat is not something to address in 2030. It requires action now, because the adversary’s collection window is already open.

What the Standards and Government Mandates Actually Require

NIST’s August 2024 publication of FIPS 203, FIPS 204, and FIPS 205 gave the cryptographic community three algorithms to work with. FIPS 203 standardizes ML-KEM, the designated replacement for RSA key transport and ECDH. FIPS 204 standardizes ML-DSA, the primary replacement for ECDSA and RSA signatures. FIPS 205 standardizes SLH-DSA, offering an alternative whose security rests on hash function hardness rather than lattice problems, at the cost of larger signature sizes and slower performance. NIST also selected HQC in March 2025 as a second KEM for standardization based on error-correcting codes rather than lattice problems, providing a non-lattice backup to ML-KEM.

NSA CNSA 2.0, issued in September 2022, sets hard deadlines for National Security Systems. New NSS acquisitions must support CNSA 2.0 algorithms as of January 2027. Software and firmware signing in NSS must use CNSA 2.0 exclusively by 2030. Traditional networking equipment including VPNs and routers must reach exclusive use of CNSA 2.0 algorithms by 2030. By December 31, 2031, CNSA 2.0 algorithms are mandated for use across NSS. Operating systems must use CNSA 2.0 exclusively by 2033. Custom applications and legacy systems must be updated or replaced by 2033. CNSA 2.0 requirements flow down through the federal supply chain.

NIST IR 8547, published November 2024, addresses the deprecation timeline for quantum-vulnerable algorithms. RSA-2048 and ECC P-256 are designated for deprecation by 2030 and full disallowance by 2035.

Quantum Threat: Algorithm-by-Algorithm Decision Table

Algorithm	Type	Quantum threat	Recommended action
RSA (any key size)	Asymmetric (key exchange, signatures)	Broken by Shor’s algorithm	Replace with ML-KEM (key exchange) or ML-DSA (signatures)
ECDSA, ECDH	Asymmetric (signatures, key exchange)	Broken by Shor’s algorithm	Replace with ML-DSA (signatures) or ML-KEM (key exchange)
Diffie-Hellman	Asymmetric (key exchange)	Broken by Shor’s algorithm	Replace with ML-KEM
AES-128	Symmetric	Quadratic speedup via Grover’s algorithm; security reduced to ~64 bits	Upgrade to AES-256 for post-quantum contexts
AES-256	Symmetric	Grover’s algorithm reduces effective security to ~128 bits; remains strong	Retain; recommended for post-quantum contexts
SHA-256, SHA-3	Hash	Minor speedup from Grover’s algorithm; remains secure	Retain; acceptable for post-quantum contexts
ML-KEM (FIPS 203)	PQC key encapsulation	No known quantum attack	Deploy as RSA/ECDH replacement
ML-DSA (FIPS 204)	PQC digital signature	No known quantum attack	Deploy as RSA/ECDSA replacement
SLH-DSA (FIPS 205)	PQC digital signature	No known quantum attack; hash-based security	Deploy for algorithm diversity; larger signatures

Building the Foundation for PQC Migration

The complexity of PQC migration is often underestimated. The transition from SHA-1 to SHA-2 took over a decade to complete across the enterprise landscape. PQC migration is considerably more complex: it requires replacing the underlying asymmetric algorithms across every system that performs key exchange or digital signing: TLS endpoints, certificate authorities, code signing infrastructure, PKI hierarchies, hardware security modules, and VPN gateways, many of which have hard dependencies on specific algorithm support in firmware or hardware that cannot be updated in place.

The starting point is a cryptographic asset inventory. You cannot migrate what you have not mapped. A practical inventory effort, combining automated discovery tooling, network traffic analysis, and manual review of configuration files and certificate stores, identifies every algorithm in use, the key sizes and expiration dates of deployed certificates, the hardware and software dependencies that constrain which algorithms can be swapped in, and the data flows that carry asymmetric-encrypted traffic. That inventory forms the foundation for risk prioritization: systems handling long-lived sensitive data or facing significant HNDL exposure are typically addressed first.

Crypto agility is the architectural principle that determines how much it will cost to change it. An environment designed with algorithm flexibility can absorb PQC migration incrementally. An environment built with hardcoded algorithms and tightly coupled dependencies requires a much more disruptive overhaul.

Phased Migration Steps

1. Complete the cryptographic inventory: use automated discovery tooling and CBOM generation to map every algorithm, key, and certificate across all environments. Identify HNDL-exposed systems and flag them for priority migration.
2. Conduct the PQC risk assessment: evaluate each system against its HNDL exposure, regulatory deadline pressure, and hardware/software constraints. Produce a prioritized remediation list.
3. Develop the migration roadmap: assign systems to migration waves based on priority and complexity; define internal deadlines that provide buffer before regulatory cutover dates; design for hybrid mode (classical plus PQC) during the transition.
4. Confirm HSM and TLS library readiness: verify that your HSM vendor’s roadmap includes FIPS 140-3 validated firmware supporting ML-KEM and ML-DSA; confirm TLS 1.3 library versions support PQC key exchange groups.
5. Pilot in a staging environment: deploy ML-KEM and ML-DSA in staging; validate interoperability with counterparties; measure performance impact of larger key and signature sizes on affected protocols.
6. Deploy hybrid mode in production: run classical and PQC algorithms together for a session to maintain interoperability with non-PQC counterparties while protecting against quantum-capable adversaries.
7. Complete the migration and retire quantum-vulnerable algorithms: once all counterparties and systems support PQC, remove classical algorithm fallback; update PKI hierarchy to issue PQC certificates; decommission RSA and ECC keys.
8. Establish continuous cryptographic governance: maintain a live CBOM to track the evolving cryptographic inventory; set policy-based alerts for quantum-vulnerable algorithm use; prepare for future algorithm transitions.

Testing Evidence and Implementation Checklist

Testing evidence for PQC migration should include the following:

• Cryptographic inventory report showing all quantum-vulnerable algorithms identified and their locations
• Risk assessment output with HNDL exposure ratings and remediation priority assignments
• Pilot test results from staging environment: algorithm compatibility, handshake sizes, performance benchmarks against baseline
• Interoperability test records with counterparty systems (TLS endpoints, PKI integrations, API consumers)
• HSM vendor certification records confirming FIPS 140-3 validated firmware supporting ML-KEM and ML-DSA
• Migration wave completion records with dates and responsible teams
• Updated certificate inventory reflecting PQC certificate issuance
• CNSA 2.0 compliance mapping for federally regulated or supply chain organizations
• CBOM tracking records for ongoing cryptographic governance post-migration

How Encryption Consulting Can Help

Encryption Consulting works with organizations at every stage of PQC migration, from initial cryptographic asset discovery and CBOM architecture through PKI modernization, hybrid certificate deployment, and algorithm transition planning.

PQC Advisory Services

Encryption Consulting delivers PQC advisory services in five structured steps: Cryptographic Discovery and Inventory; PQC Assessment (identifying RSA- and ECC-dependent systems with risk severity ratings); PQC Strategy and Roadmap (phased migration plan aligned to your risk appetite and regulatory requirements); Vendor Evaluation and Pilot Testing; and Full Implementation (deploying hybrid classical and quantum-safe models across PKI and infrastructure with ongoing cryptographic health monitoring).

CBOM Secure

A successful post-quantum transition begins with visibility. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services. Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment, providing visibility into what is deployed, where it is running, and how cryptographic dependencies evolve over time.

Conclusion

Quantum computing is not a distant, theoretical problem. The standards are finalized. The government deadlines are published. Nation-state actors are almost certainly collecting encrypted data today under the assumption that a capable quantum computer will arrive within their operational planning horizon. The HNDL threat alone makes inaction in 2026 a risk management failure, not a conservative posture.

The transition to post-quantum cryptography will be one of the largest coordinated infrastructure changes the security industry has ever undertaken. The organizations that begin the work now with a structured inventory, a clear understanding of their HNDL exposure, and a migration plan tied to NIST and CNSA 2.0 timelines will complete that transition without disruption. Those who wait until deprecation deadlines arrive will find themselves compressing a multi-year program into an insufficient window. For migration planning steps, standards details, and an implementation checklist, see Unlocking the Quantum Era: Essential Steps for Post-Quantum Cryptography Readiness.

Frequently Asked Questions

How does a quantum computer break RSA and ECC encryption?

A quantum computer breaks RSA and ECC using Shor’s algorithm, which reduces integer factoring and the elliptic curve discrete logarithm problem to polynomial time. RSA-2048, infeasible to break on classical hardware, becomes breakable at any key size once a sufficiently scaled quantum machine exists. ECDH, ECDSA, and finite-field Diffie-Hellman all collapse against the same algorithm. Symmetric algorithms face a lesser threat: Grover’s algorithm reduces a k-bit symmetric key to k/2 bits of effective security.

What is the Harvest Now, Decrypt Later threat and is it active today?

HNDL is the strategy of collecting encrypted data today and archiving it until a cryptographically relevant quantum computer exists to decrypt it. It is active today. Nation-state actors are assessed by CISA and NSA to be engaged in bulk interception and archival of encrypted traffic. Any data that must remain confidential beyond the point at which a capable quantum computer could realistically exist is already at risk.

What are the NIST PQC standards finalized in August 2024?

NIST finalized FIPS 203 (ML-KEM, the replacement for RSA key transport and ECDH), FIPS 204 (ML-DSA, the primary replacement for ECDSA and RSA signatures), and FIPS 205 (SLH-DSA, a conservative alternative based on hash function hardness). NIST selected HQC in March 2025 as a second KEM based on error-correcting codes; standardization is ongoing.

What does CNSA 2.0 require and who must comply?

CNSA 2.0 sets hard deadlines for National Security Systems: new acquisitions must support CNSA 2.0 as of January 2027; software/firmware signing and networking equipment must use CNSA 2.0 exclusively by 2030; all NSS must use CNSA 2.0 by December 31, 2031; operating systems and custom applications must reach exclusive use by 2033. Requirements flow through the federal supply chain to commercial organizations supplying products or services to NSS environments.

What is a cryptographic asset inventory and why is it the first step in PQC migration?

A cryptographic asset inventory identifies every algorithm in use, key sizes and certificate expiration dates, hardware and software dependencies, and data flows with long-term confidentiality requirements. It is the required first step because you cannot migrate what you have not mapped. The inventory output prioritizes systems by quantum risk exposure, with HNDL-exposed workloads addressed first.

What is crypto agility and why does it matter for PQC migration?

Crypto agility is the architectural principle that cryptographic primitives can be updated without rewriting applications or replacing hardware. An environment designed with algorithm flexibility can absorb PQC migration incrementally. An environment built with hardcoded algorithms and tightly coupled dependencies requires a much more disruptive overhaul. Building for crypto agility now also positions the organization to absorb future algorithm transitions efficiently.