The Dawn of a New Cyber Threat

Published: December 2023. Updated: August 2026. Reviewed by Encryption Consulting’s PQC Advisory team.

The history of cryptography began with encoding secrets of war, so it fits that the relationship between defenders and attackers is usually described as an arms race. For nearly five decades, that race has been remarkably one-sided in favor of encryption. RSA, developed in 1977, is still protecting traffic today, and the standard defense against a faster attacker has always been the same: make the key bigger. That era of relative stability is ending, and the reason is not a faster CPU. It is a fundamentally different kind of computer.

What Is the New Cyber Threat, Exactly?

The threat is a cryptographically relevant quantum computer (CRQC), a machine powerful enough to run Shor’s algorithm against the math that underpins RSA and elliptic-curve cryptography (ECC). Both algorithms rely on “trapdoor” math problems that are easy to compute in one direction and, for a classical computer, extremely hard to reverse. RSA leans on the difficulty of factoring the product of two large primes; ECC leans on the discrete logarithm problem over elliptic curves. A quantum computer running Shor’s algorithm can solve both in polynomial time, which is what separates this threat from every prior cryptographic scare: increasing the key size does not fix it, because the attack does not get exponentially harder as the key grows the way brute-force guessing does.

Symmetric algorithms like AES are affected differently. Grover’s algorithm gives a quantum computer a quadratic speedup against symmetric keys, which is why NIST recommends AES-256 (effectively AES-128 strength against a quantum attacker) rather than a wholesale symmetric redesign. The urgent problem is specifically the public-key cryptography, RSA, ECDSA, ECDH, and Diffie-Hellman, that issues certificates, signs software, and negotiates every TLS session on the internet.

Why Does This Threat Matter Today, Not in a Decade?

Because the attack does not require the quantum computer to exist yet. In a harvest-now, decrypt-later (HNDL) attack, an adversary captures encrypted traffic, backups, or archived files today and simply stores them until a CRQC becomes available. Encrypted data has no expiration date for an attacker with cheap storage and patience. Our deep dive on harvest-now, decrypt-later covers the full attacker economics; the short version is that any data that must stay confidential for longer than it will take a CRQC to arrive is already exposed, even though no quantum computer has broken it yet.

This reframes the question every security leader needs to ask. It is not “when will quantum computers arrive,” it is “how long does our data need to stay secret, and does that outlast our migration timeline?” Healthcare records, genomic data, government intelligence, source code signing keys, and long-lived infrastructure credentials routinely need protection for 10, 20, or more years, which is longer than most credible estimates for Q-Day, the point at which a CRQC exists.

How Far Along Are Quantum Computers, Really?

Further along than most security teams assume, and the metric that matters has changed. Raw qubit counts used to dominate the conversation; IBM’s 433-qubit Osprey chip made headlines in 2022. But qubit count alone was never the right proxy for cryptographic risk, because noisy physical qubits do not translate directly into usable computation. The field has since shifted toward error-corrected “logical” qubits as the metric that actually predicts when Shor’s algorithm becomes runnable at cryptographically relevant scale.

In December 2024, Google’s 105-qubit Willow chip demonstrated error correction that improves as more physical qubits are added, a long-sought threshold for building a fault-tolerant machine. In October 2025, Google followed with its Quantum Echoes algorithm, described by the company as its first verifiable demonstration of quantum advantage on real hardware. IBM, meanwhile, has moved its roadmap away from a pure qubit-count race: its current-generation Heron processors run at 156 qubits with higher fidelity than earlier, larger chips, and IBM has targeted 2029 for Quantum Starling, a fault-tolerant system designed to run 100 million quantum gates across 200 logical qubits. None of this means a CRQC exists today. It means the trajectory that “increasing key size will save us” was built on has clearly ended, and estimates for Q-Day (commonly cited in the 2030 to 2035 range across the industry) carry real engineering evidence behind them now, not just speculation.

Which Post-Quantum Algorithm Should You Actually Use?

On August 13, 2024, NIST finalized the first three post-quantum cryptography standards after an eight-year public evaluation process, and for most organizations, algorithm selection is now a matter of matching NIST’s guidance to the job the algorithm needs to do rather than picking from open options.

Standard	Algorithm	Job	When to choose it
FIPS 203	ML-KEM (based on CRYSTALS-Kyber)	Key encapsulation (replaces RSA/ECDH key exchange)	Default choice for TLS, VPN, and any protocol that negotiates a shared secret. ML-KEM-768 is the common baseline; ML-KEM-1024 for higher assurance or CNSA 2.0 alignment.
FIPS 204	ML-DSA (based on CRYSTALS-Dilithium)	General-purpose digital signatures (replaces RSA/ECDSA signing)	Default choice for code signing, certificates, and document signing where signing and verification throughput matters.
FIPS 205	SLH-DSA (based on SPHINCS+)	Backup digital signatures built on hash functions instead of lattice math	Long-lived, low-volume signatures (firmware, root CA certificates, archival records) where the priority is mathematical diversity over speed or size.

ML-KEM and ML-DSA are both lattice-based, which makes them fast and compact, but it also means a single unexpected cryptanalytic advance against lattice math could weaken both at once. SLH-DSA’s hash-based construction rests on different, more conservative assumptions, which is why NIST kept it as a structurally independent option rather than retiring it once ML-DSA was finalized. FN-DSA (based on FALCON, expected as FIPS 206) is a fourth signature option still in progress, aimed at constrained environments that need smaller signatures than ML-DSA without SLH-DSA’s size penalty. For a deeper comparison of post-quantum algorithms against quantum key distribution (QKD), a separate and much less deployable approach some vendors pitch, see why PQC, not QKD, is the practical enterprise migration path.

What Do These Algorithms Cost in Performance and Interoperability?

The trade-offs are real but manageable for most deployments, and they differ sharply by algorithm family:

• Key exchange is cheap. An ML-KEM-768 public key runs about 1,184 bytes and a ciphertext about 1,088 bytes, against 32 bytes for a classical X25519 key. In practice, a hybrid ML-KEM-768 plus X25519 TLS 1.3 handshake adds roughly 2 to 3 KB of overhead, small next to the certificates a handshake already transmits, and ML-KEM’s core operations run as fast or faster than classical elliptic-curve math on modern CPUs.
• Signatures are the harder trade-off. An ML-DSA-65 signature runs about 3.3 KB versus roughly 64 to 256 bytes for ECDSA or RSA. SLH-DSA is heavier still, from roughly 8 KB up to nearly 50 KB depending on the parameter set. Protocols with strict packet-size limits, notably QUIC’s initial packet ceiling, constrain which parameter sets fit without fragmentation, which is one reason ML-KEM-768 rather than ML-KEM-1024 became the common web default.
• Interoperability runs through hybrid mode first. Nearly every production post-quantum deployment today pairs a post-quantum algorithm with a classical one (for example, X25519MLKEM768) rather than replacing classical algorithms outright. That protects against both a still-theoretical quantum break and any undiscovered weakness in the newer post-quantum math, and it keeps the connection working against endpoints that do not yet support post-quantum key exchange.
• Legacy and constrained systems lag hardest. Embedded devices, older HSM firmware, and long-refresh-cycle hardware often cannot absorb the larger key and signature sizes without a firmware or hardware update, which is why inventory and phased rollout matter more than a flag flip.

Where Is This Already Being Deployed?

This is not a hypothetical migration; it is already running in production at meaningful scale:

• Web traffic. Cloudflare reported that as of late October 2025, the majority of human-initiated HTTPS traffic on its network negotiates a post-quantum hybrid key exchange, chiefly X25519MLKEM768, and that recent versions of every major browser now enable it by default.
• Enterprise PKI. Microsoft shipped ML-DSA signature support for Active Directory Certificate Services on Windows Server 2025 in a May 2026 update, letting enterprises stand up ML-DSA certificate authorities on infrastructure they already run.
• Cloud provider roadmaps. Google Cloud has published a phased roadmap targeting post-quantum confidentiality by 2027 and full signature and infrastructure readiness by 2029, splitting responsibility between what the provider migrates and what customers must still handle themselves.
• Government and defense. The NSA’s CNSA 2.0 suite specifies ML-KEM-1024 and ML-DSA-87 with category-by-category deadlines running from 2030 through 2033 for national security systems, well ahead of NIST’s general-purpose federal timeline.

Notably, certificate-based authentication has moved slower than key exchange. As of late 2025, no public post-quantum certificate authority was issuing production TLS certificates trusted by browsers, even though most of that same traffic was already protected in transit by post-quantum key agreement. Confidentiality and authentication are migrating on different clocks, and both need a plan.

What Does Migration Actually Require?

Algorithm selection is the easy part. The dependency that actually determines whether a migration succeeds is key management: you cannot protect, rotate, or replace cryptographic material you do not know exists. A practical response process looks like this:

1. Build a cryptographic inventory (CBOM). Catalog every algorithm, key, certificate, and library in use, including embedded and third-party dependencies most network scans miss entirely.
2. Prioritize by data shelf life and HNDL exposure. Rank systems by how long their protected data must stay confidential, not by how visible the system is. Long-lived data with the highest exposure moves first.
3. Pilot hybrid key exchange on transport first. Enable hybrid ML-KEM alongside existing classical key exchange on TLS endpoints; this is the lowest-risk, most software-only step and can usually happen without waiting on hardware.
4. Plan the certificate and signing migration separately. Map which CAs, HSMs, and code-signing pipelines need ML-DSA or SLH-DSA support, and confirm firmware or vendor timelines before committing to a cutover date.
5. Build in crypto-agility and track against real deadlines. Design systems so the next algorithm swap does not require another multi-year project, and validate progress against NIST IR 8547’s 2030/2035 milestones or your applicable CNSA 2.0 category deadline.

Every one of these steps depends on key management maturity. An organization managing keys manually, or without hardware-backed key protection, cannot rotate to a new algorithm family at the pace this transition demands. HSM vendors are still rolling out ML-KEM and ML-DSA support at different paces, which makes confirming HSM firmware compatibility an early, not final, step in any migration plan.

Limitations

A few honest caveats apply. First, nobody knows the exact date a CRQC will exist; estimates in this article reflect current expert consensus, not certainty, and both faster and slower outcomes remain possible. Second, hybrid post-quantum modes are not universally supported: older TLS libraries, legacy hardware, and some embedded devices cannot negotiate them without an update, so a hybrid rollout is rarely a single flag change across an entire estate. Third, NIST IR 8547’s 2030/2035 dates are directional guidance for federal systems, not a binding law for every organization, though CNSA 2.0 and sector-specific regulators are moving toward harder deadlines. Fourth, quantum key distribution is sometimes proposed as an alternative to PQC; it requires dedicated fiber or line-of-sight hardware, cannot run as a standard cloud service, and does not solve authentication, which is why it is not a realistic substitute for most enterprises. Finally, migrating the algorithm is necessary but not sufficient. Implementation bugs, weak randomness, and poor key storage can undermine ML-KEM or ML-DSA just as they have undermined RSA and ECC deployments in the past.

What Would Encryption Consulting Recommend?

Do not start with an algorithm; start with an inventory. The organizations that struggle most with post-quantum migration are the ones that try to pilot ML-KEM on a handful of servers before they know how many certificates, embedded keys, and third-party dependencies they actually have. Encryption Consulting’s Cryptographic Inventory capability discovers cryptographic assets across network traffic, code repositories, key stores, and HSMs, the layers a network scan alone typically misses, and feeds that data into a prioritized risk view.

From there, our PQC Advisory Services run a 9-phase, execution-ready roadmap that takes an organization from discovery and risk assessment through hybrid pilot testing, phased implementation, and ongoing governance, sequenced against your actual data sensitivity and regulatory deadlines rather than a generic timeline. For teams that need the transition to hold up over the next decade of algorithm changes, not just this one, we build in crypto-agility from the start, so the next mandated swap is a configuration change, not another multi-year program.

If you are unsure where to start, our PQC Readiness assessment is the fastest way to find out how exposed your organization actually is before committing to a migration timeline.

Frequently Asked Questions

Is quantum computing already breaking encryption today?
No. No known quantum computer can yet run Shor’s algorithm at a scale that threatens RSA-2048 or comparable ECC keys in production. The urgency comes from harvest-now, decrypt-later attacks, which capture encrypted data now for decryption once a capable quantum computer exists, not from an active break happening today.

What is harvest-now, decrypt-later, and does it affect my organization now?
It is an attack strategy where adversaries collect and store encrypted traffic or files today, waiting to decrypt them once quantum computers are capable enough. It affects you now if any data you protect today needs to stay confidential longer than your realistic migration timeline. See our full HNDL explainer for a risk-based way to assess exposure.

Which NIST post-quantum algorithm should we adopt first?
Most organizations start with FIPS 203 (ML-KEM) for key exchange, since it is the lowest-risk, software-only change and is already default in major browsers and TLS libraries. Signature migration (FIPS 204 ML-DSA, or FIPS 205 SLH-DSA for long-lived, high-assurance signatures) typically follows once certificate authorities and HSM firmware support it.

Does upgrading to post-quantum algorithms slow down our systems?
Key exchange overhead is small, typically a few kilobytes added to a TLS handshake, with comparable or better raw computation speed than classical elliptic-curve methods. Signatures are the bigger trade-off: ML-DSA signatures run several times larger than ECDSA, and SLH-DSA signatures run larger still, which matters most for bandwidth-constrained or high-volume signing systems.

What is Q-Day and when will it happen?
Q-Day is the point at which a cryptographically relevant quantum computer exists and can break RSA and ECC in practice. No one can name an exact date; industry and government estimates commonly cluster in the 2030 to 2035 range, which is also why NIST’s and the NSA’s own deprecation deadlines fall in that same window.

Conclusion

The arms race between cryptography and computation is entering a phase that increasing key size cannot resolve. RSA and ECC will not fail overnight, but the math they depend on has a known, engineered path to failure, and every year of delay extends the window of data already exposed to harvest-now, decrypt-later collection. NIST has done its part: FIPS 203, 204, and 205 give the industry finalized, vetted algorithms to migrate to. The remaining work, knowing what you have, prioritizing by real exposure, and building the crypto-agility to keep adapting, is organizational, not mathematical, and it is the work that determines whether your organization is ready before Q-Day arrives or scrambling after.

References

• NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 13, 2024
• Federal Register, Notice of Issuance of FIPS 203, 204, and 205
• NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
• Cloudflare, “State of the Post-Quantum Internet in 2025”
• Google, “Meet Willow, Our State-of-the-Art Quantum Chip,” December 2024
• Google, “Our Quantum Echoes Algorithm Is a Big Step Toward Real-World Applications,” October 2025
• IBM Quantum, Hardware and Roadmap