Skip to content

47-Day Certificates Are Coming. Are You Ready?

Act Now →

What Is Quantum Computing and Why Does It Threaten Encryption?

PQC

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 secure not because anyone has proved it unbreakable, but because no classical computer has ever come close to cracking it in a practical timeframe. That assumption has held long enough that most enterprises have built their entire security readiness around it. Quantum computing is now posing a credible challenge to that assumption, and the cryptographic community is responding with urgency.

The concern is not that quantum computers can break modern cryptographic systems today. Current quantum hardware remains noisy, limited in qubit count, and far from the scale needed to threaten real-world key sizes. Although the timeline remains uncertain, recent advances in quantum error correction have strengthened the case for beginning post-quantum cryptography (PQC) planning and migration efforts.

What has changed is the combination of two developments: the accelerating pace of quantum hardware research and the recognition that adversaries do not need to wait for a working quantum computer to begin their attack. Data harvested and stored today can be decrypted the moment a capable quantum machine arrives.

NIST finalized its first three PQC standards in August 2024, after an eight-year standardization effort that drew 82 submissions from cryptographers across 25 countries. FIPS 203, FIPS 204, and FIPS 205 represent the official answer to the quantum threat. But a standard being published and an enterprise being ready are two entirely different things. Most organizations have not yet inventoried their cryptographic assets, let alone mapped a migration path. The gap between published standards and enterprise readiness is what makes this moment genuinely consequential.

This blog explains how quantum computing actually threatens encryption, why the risk is present-day and not hypothetical, and what the standards and government mandates require organizations to do now.

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 the computational difficulty of factoring large integers on classical hardware. Elliptic curve cryptography (ECC) rests on the hardness of 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 the algorithms designed for exactly these problems. Not every organization faces the same exposure, but the nature of these problems means the risk extends well beyond government systems.

Who Needs to Act and Why

The quantum threat is not confined to defense agencies or classified systems. Federal agencies subject to the Federal Information Security Modernization Act (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: any enterprise transmitting or storing data that must remain confidential beyond the point at which a capable quantum computer could realistically exist is already at risk today.

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 the Health Insurance Portability and Accountability Act (HIPAA) and remain sensitive well beyond active treatment periods. The same applies across financial services, legal, and critical infrastructure.

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, mergers and acquisitions documentation, and litigation strategy that adversaries would find valuable long after a matter closes. Critical infrastructure operators, including energy grid controllers, water treatment facilities, and telecommunications providers, transmit operational and control system data whose exposure could enable targeted disruption of physical systems.

For all of these sectors, the data being transmitted and stored today is the data an adversary equipped with a future quantum computer can decrypt. Understanding that exposure requires understanding exactly how a quantum computer dismantles the math that classical encryption depends on.

PQC Advisory Services

Gain post-quantum readiness with expert-led cryptographic assessment, migration strategy, and hands-on implementation aligned to NIST standards.

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, the most widely deployed asymmetric algorithm in the world, 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, a fraction of what classical hardware would require. The same applies to ECC.

ECC relies on the hardness of the elliptic curve discrete logarithm problem, which Shor’s algorithm similarly reduces to polynomial time, though the quantum resource requirements differ from those needed to attack RSA. 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. As a result, NIST uses AES-128 key search as the reference point for Category 1 in its post-quantum security framework. This benchmark represents a comparative security level rather than a recommendation for symmetric key sizes.

AES-256 provides a wider security margin and is the recommended choice for the highest-assurance contexts. The quantum threat to symmetric algorithms is a problem of key size, not algorithm design. The threat to asymmetric algorithms is existential. The threat does not require a quantum computer to exist yet. It only requires one to arrive eventually.

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 the Cybersecurity and Infrastructure Security Agency (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 potential value of decrypting it once a cryptographically relevant quantum computer arrives is substantial. 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.

NIST, NSA, and CISA built their guidance around exactly that window, and the deadlines they published reflect it.

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 (Module-Lattice-Based Key-Encapsulation Mechanism), derived from CRYSTALS-Kyber, and is the designated replacement for RSA key transport and ECDH in key exchange and secure session establishment. FIPS 204 standardizes ML-DSA (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium, as the primary replacement for ECDSA and RSA signatures.

FIPS 205 standardizes SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+, offering an alternative whose security rests on hash function hardness rather than lattice problems, at the cost of larger signature sizes and slower performance. This makes it the conservative choice where algorithm diversity across mathematical assumptions matters.

A fourth standard, FIPS 206, designated by NIST as FN-DSA (Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm) and based on the FALCON algorithm, was published as an Initial Public Draft in late 2025, with finalization expected in late 2026 or 2027.

NIST also selected HQC in March 2025 as a second KEM for standardization, chosen specifically because its security is based on error-correcting codes rather than lattice problems, providing a non-lattice backup to ML-KEM if lattice assumptions are ever weakened. HQC has not yet been published as a final FIPS standard. Standardization is ongoing.

The regulatory pressure attached to these standards is substantial and moving fast. NSA CNSA 2.0, issued in September 2022 and updated since, 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, per the NSA CNSA 2.0 FAQ. Operating systems must support and prefer CNSA 2.0 by 2027, with exclusive use required by 2033. Custom applications and legacy systems must be updated or replaced by 2033. For organizations supplying products or services to the federal government, CNSA 2.0 requirements flow down through the supply chain, making them relevant well beyond defense agencies.

NIST IR 8547, published in November 2024 as an Initial Public Draft, addresses the deprecation timeline for quantum-vulnerable algorithms. RSA-2048 and ECC P-256, currently the most widely deployed public-key algorithms, are designated for deprecation by 2030 and full disallowance by 2035.

Organizations running FIPS 140-3 validated cryptographic modules face a related constraint: the Cryptographic Module Validation Program updated its approved algorithm listings to include ML-KEM, ML-DSA, and SLH-DSA, aligned with the August 2024 publication of the PQC standards. Migration is not optional for federally regulated environments. For commercial enterprises, the combination of regulatory timelines and the HNDL threat makes it operationally irresponsible to defer indefinitely.

The standards define the destination, but the work of getting there remains with individual organizations.

CBOM

Gain complete visibility with continuous cryptographic discovery, automated inventory, and data-driven PQC remediation.

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 and left many organizations running vulnerable configurations well beyond recommended timelines.

PQC migration is considerably more complex. In many PKI environments, the SHA-1 migration required updating a single hash function in certificate signatures. PQC migration 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. Most large enterprises have cryptographic assets distributed across on-premises infrastructure, cloud environments, CI/CD pipelines, and IoT or operational technology devices. In most environments, a significant portion of these assets have no centralized tracking at all.

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 Harvest Now, Decrypt Later (HNDL) exposure are typically addressed first.

The inventory shows what needs to change. Crypto agility is the architectural principle that determines how much it will cost to change it. An environment designed with algorithm flexibility, meaning cryptographic primitives can be updated without rewriting applications or replacing hardware, 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 can significantly reduce the cost and disruption of future algorithm transitions.

For many organizations, the challenge is not understanding the risk but determining where to begin. Translating PQC requirements into an actionable migration program requires both strategic planning and technical execution. Encryption Consulting helps organizations turn assessment findings and strategic objectives into practical migration plans and implementation activities.

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. For organizations navigating the FIPS 140-3 validation gap, EC can help classify their deployment environments, sequence migration activities against the validation timeline, and build the internal PKI infrastructure that does not require FIPS-validated modules for early deployment.

PQC Advisory Services

Encryption Consulting delivers PQC advisory services in five structured steps. Here is how each offering accelerates your progress.

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.

We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.

Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.

With this structured approach, you move from cryptographic uncertainty to a documented, policy-driven migration program aligned to NIST timelines and your regulatory obligations.

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. It provides visibility into what is deployed, where it is running, and how cryptographic dependencies evolve over time.

The platform also supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and helping organizations address security, operational, and compliance risks.

For PQC readiness, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation activities, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.

Conclusion

Quantum computing is not a distant, theoretical problem that the cryptographic community is getting ahead of. 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, under regulatory pressure, with limited resources to do it cleanly.