From the Winter 2026 Issue

The Quantum Threat Is Already Here: We Just Can’t See It Yet

Gurdeep Gill
Software Engineer Technical Leader | CISCO Systems

Nation-states are harvesting encrypted data right now, banking on quantum computers to crack it open in the coming years.

The Attack That Leaves No Trace

Your encrypted data is being stolen right now. Not by attackers trying to break your encryption today, but by adversaries who understand that quantum computing will eventually make current cryptographic protections obsolete. This is “Harvest Now, Decrypt Later” (HNDL), a surveillance strategy where nation-state actors and well-funded threat groups systematically collect vast amounts of encrypted traffic, storing it in massive data repositories with the intent to decrypt it once sufficiently powerful quantum computers become available.

The threat isn’t hypothetical. The math is simple: RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman, the algorithms protecting most encrypted communications, rely on computational problems that would take classical computers longer than the age of the universe to solve. Factoring large numbers, solving discrete logarithms, these are mathematically hard problems that form the bedrock of modern public-key cryptography. However, quantum computers running Shor’s Algorithm could potentially break RSA-2048 encryption in hours or days instead of billions of years.

Data encrypted today using vulnerable algorithms and captured by adversaries will be exposed when quantum decryption becomes feasible.

The urgency of this threat stems from data retention requirements. Government records, intellectual property, healthcare information, financial transactions, and critical infrastructure logs often need to remain confidential for decades. HIPAA mandates seven-year retention for healthcare data. Certain nuclear safety records require up to 50 years. Patent applications, classified communications, and trade secrets may need protection for 25 years or more. Data encrypted today using vulnerable algorithms and captured by adversaries will be exposed when quantum decryption becomes feasible.

While practical cryptanalytically-relevant quantum computers don’t yet exist, development is accelerating. Expert consensus suggests RSA could become vulnerable within 10 to 20 years. Recent research indicates breaking RSA-2048 might require fewer resources than previously estimated, potentially under a million noisy qubits operating for less than a week rather than millions of error-corrected qubits. This has compressed timeline estimates, with some researchers projecting a significant probability of RSA-2048 being broken by the early 2030s.

The probability that your long-lived encrypted data is already being harvested is high. The attack leaves no trace, triggers no alerts, appears in no security logs. By the time quantum decryption is possible, it will be too late.

Figure 1: Three-stage HNDL attack progression from current data harvesting (2025) through quantum development (2025-2035) to eventual decryption at Q-Day (~2030s). Each stage shows key activities and threats.

The HNDL attack unfolds in three stages.

Stage 1 (today): Adversaries harvest encrypted traffic with no detection while data is stored in archives.

Stage 2 (2025-2035): Quantum computers advance as PQC migration window remains open.

Stage 3 (Q-Day, ~2030s): RSA-2048 is broken, archived data is decrypted, and it becomes too late to protect previously encrypted data.

The yellow banner emphasizes the core threat: data encrypted today will be vulnerable when quantum computers arrive in approximately 10 years.

When will This Actually Happen?

Everyone wants to know: when will quantum computers be powerful enough to break RSA? We call this “Q-Day” or “Y2Q,” and, nobody knows for sure when this will happen. The consensus puts it somewhere in the next 10 to 20 years, but that’s a pretty wide window.

What’s changed recently is that we’re learning it might not take as much quantum horsepower as we thought. Some newer research suggests breaking RSA-2048 could happen with under a million noisy qubits running for less than a week, not the millions of error-corrected qubits we previously assumed. That’s moved some estimates up, with credible researchers suggesting we might see RSA broken by the early 2030s.

But here’s the thing: it doesn’t matter if Q-Day is 2031 or 2041. If you’ve got data that needs to stay secret for 25 years, and adversaries are collecting it now, you’re already on the clock. Quantum error correction is advancing, qubit counts are climbing, and algorithm efficiency is improving. The trend line points in one direction.

The Algorithms That Break all

Two quantum algorithms are the real problem here, and they attack crypto in different ways.

Shor’s Algorithm, published by Peter Shor back in 1994, is the nightmare scenario for public-key cryptography. It can factor large numbers and solve discrete logarithm problems efficiently, which is a fancy way of saying it demolishes the math that RSA, ECC, and Diffie-Hellman rely on. These aren’t niche protocols; they’re everywhere. TLS, SSH, VPNs, digital signatures. A quantum computer running Shor’s Algorithm would make all of them vulnerable.

Grover’s Algorithm is less catastrophic but still problematic. It doesn’t break symmetric encryption like AES, but it does weaken it by effectively cutting the key strength in half. So, your AES-128 becomes 64-bit security in a quantum world, which is… not great. AES-256 drops to 128-bit, which is still usable but not what you thought you were getting. The fix is straightforward at least: use longer keys.

Figure 2: Breaking encryption - Classical computers take billions of years to break RSA-2048; quantum computers could do it in hours

Who Gets Hit Hardest?

This affects everyone, but some sectors are in worse shape than others.

Financial services is an obvious target. Banking transactions, algorithmic trading strategies, M&A communications, customer data; it’s all high-value and much of it stays sensitive for years. Some research suggests quantum attacks on financial systems could trigger economic disruption in the trillions. Whether that’s overblown or not, the risk is real enough that banks should be worried.

Healthcare has a unique problem: regulatory data retention. HIPAA requires keeping patient records for at least seven years, and many healthcare systems keep them far longer. That means patient data from 2025 needs to stay confidential into the 2030s and beyond, potentially past Q-Day. Once that data is decrypted, it’s exposed forever. There’s no putting that genie back in the bottle.

Government and defense organizations are probably already being targeted. Classified cables, intelligence operations, diplomatic communications: This is exactly the kind of long-term sensitive data that HNDL was designed to capture. If you’re a nation-state adversary, this is your highest-value target.

Critical infrastructure creates a different kind of risk. Power grids, water systems, transportation networks. These systems use encrypted control protocols and authentication mechanisms. Decrypt those, and you potentially get access credentials, system vulnerabilities, or architectural details that could enable physical attacks years down the line.

Intellectual property theft is probably the most widespread concern. R&D data, trade secrets, proprietary algorithms, patent applications. Companies spend years and millions developing this stuff. If competitors or nation-states can decrypt your communications from 2025 in 2035, that’s still valuable intelligence.

The pattern is clear: if your data needs to stay secret for 10-25 years, you’re in the danger zone.

Figure 3: Side-by-side comparison. Left: Quantum threat risk scores (7-10 scale). Right: Data retention requirements (years). Sectors ranking high in both categories are most vulnerable to HNDL attacks.

The Good News: NIST responded appropriately

Having standardized, vetted algorithms means we're not scrambling to invent crypto during a crisis.

NIST saw this coming. Back in 2016, they launched a standardization effort for post-quantum cryptography, and after years of evaluation and cryptanalysis from researchers worldwide, they published the first set of quantum-resistant standards in 2024. This is a big deal. Having standardized, vetted algorithms means we’re not scrambling to invent crypto during a crisis.

Here’s what we’ve got:

FIPS 203 (ML-KEM) is the main key establishment mechanism. You might know it as CRYSTALS-Kyber. It’s lattice-based, meaning it relies on math problems that quantum computers aren’t good at solving. This replaces your RSA and ECDH key exchanges.

FIPS 204 (ML-DSA) handles digital signatures, formerly CRYSTALS-Dilithium. Also lattice-based is what will be used instead of RSA or ECDSA signatures for authentication and integrity.

FIPS 205 (SLH-DSA) is the backup plan, previously known as SPHINCS+. It’s hash-based rather than lattice-based, which gives us cryptographic diversity. If someone finds a weakness in lattice crypto, we’ve got a fallback that uses completely different math.

The underlying principle here is simple: these algorithms are based on problems that both classical and quantum computers struggle with. Lattice problems and hash functions do not have efficient quantum algorithms as Shor’s. At least, none that we know of, and people have been looking hard.

NIST isn’t done, either. More algorithms are coming to provide additional options and diversity. The federal government has set deadlines: deprecated vulnerable ciphers by 2030, full migration by 2035. The EU is on a similar timeline. This isn’t optional.

Figure 4: Overview of NIST's three standardized post-quantum cryptographic algorithms

Why This Migration Is Going to be painful

Having standards is great. Actually, migrating to them? That’s where things get messy.

First, most organizations don’t actually know where all their crypto is. I’ve done enough security assessments to know that cryptographic inventory is usually a disaster. You’ve got crypto in your TLS configs, sure, but also in your applications, your APIs, third-party services, embedded systems, mobile apps, IoT devices. Half of it is undocumented. Some of it was implemented by a contractor who left three years ago. Good luck finding it all.

Then there’s the legacy system problem. That SCADA system controlling part of your manufacturing plant? The medical device that’s FDA-approved with a 15-year operational life? The embedded system that would cost $2 million to replace? Yeah, those aren’t getting cryptographic upgrades. You’re either living with the risk or replacing hardware that still works perfectly fine, aside from the whole “vulnerable to future quantum attacks” thing.

Interoperability is another headache. You can’t just upgrade in isolation. If you’re a bank and you migrate to PQC, but your payment processors haven’t, what do you do? If you’re a hospital and your EHR vendor isn’t ready, you’re stuck. This requires coordinated ecosystem-wide migration, which in practice means it’ll take forever.

Performance matters too. PQC algorithms use bigger keys and take more CPU cycles than RSA. For most systems that’s fine, but if you’re running on resource-constrained IoT devices or handling massive transaction volumes, you’ll need to test carefully. Some devices might not have the computational headroom.

And finally, there’s implementation risk. Each interaction with crypto carries a risk of making a costly mistake. New libraries, new configs, new key management processes. This is exactly the kind of migration where you introduce vulnerabilities while trying to fix other vulnerabilities.

What Do You Actually Do?

Despite all the challenges, sitting still isn’t an option. Here’s a practical approach:

Start with inventory. You can’t fix what you can’t see. Map out where you’re using vulnerable crypto. TLS endpoints, application-level encryption, key exchange mechanisms, digital signatures, everything. This is boring, tedious work, but it’s essential. Use automated tools where you can but accept that you’ll need manual review for the edge cases.

While you’re at it, classify your data. What needs to stay confidential for 5 years? 10? 25? Anything in that last category needs to be prioritized for migration because it’s already in the HNDL danger zone.

Build cryptographic agility into your architecture. This is the ability to swap out crypto algorithms without rewriting your entire codebase. If you’re building new systems now, design them so you can switch from RSA to ML-KEM without a six-month migration project. Use abstraction layers, standard libraries, and configurable cipher suites. Your future self will thank you.

Plan for hybrid deployments. You don’t have to, and probably shouldn’t, switch everything to PQC overnight. Run hybrid modes that support both classical and post-quantum algorithms during the transition. This gives you backward compatibility while you migrate. Most major TLS libraries already support this.

Start with your highest-risk systems. Do you have data that needs 25-year confidentiality? Migrate those systems first. Long-lived secrets, sensitive communications, critical infrastructure control systems. Prioritize based on actual risk, not what’s easiest to upgrade.

Engage your vendors now. If you rely on third-party software, SaaS platforms, or cloud providers, start asking them about their PQC roadmaps. Some will have solid plans. Others will give you blank stares. Either way, you need to know so you can plan accordingly.

Test in production-like environments. Don’t discover that PQC breaks your performance requirements after you’ve deployed it. Set up realistic test environments, measure latency and throughput, identify bottlenecks. This is especially critical for high-transaction systems.

Accept that this will take years. The federal government is aiming for 2035. You probably won’t hit full migration before 2030 at the earliest. That’s fine. Just make sure you’re making consistent progress and hitting your highest-risk systems first.

Make sure you build quantum awareness into your incident response plans. If someone discovers a major cryptanalytic breakthrough tomorrow, do you have a process to respond quickly? Think of it like your patch management process, but for cryptographic algorithms.

What Happens If You do not prepare?

Let’s be blunt: if you’re still running vulnerable crypto when Q-Day hits, you’re going to have a very bad time.

The data breach isn’t just current data. It’s everything that was collected over the past decade or more. Imagine explaining to your board (or your customers, or the press) that ten years of supposedly encrypted communications just got decrypted by a foreign government. That’s not a data breach you patch and move on from. That’s an existential crisis.

Regulatory penalties are coming too. Right now, regulators might give you a pass for not having migrated to PQC yet. In 2032? When the federal government mandated migration by 2030 and published standards in 2024? You’re not getting sympathy. You’re getting fined.

For companies, there’s the competitive intelligence problem. If your competitors or foreign adversaries can decrypt your R&D communications, your M&A discussions, your product development plans, that’s years of competitive advantage gone. In some industries, that’s unrecoverable.

And for critical infrastructure and government systems, the national security implications are obvious. This isn’t theoretical risk. This is “adversaries have your classified communications and infrastructure blueprints” risk.

On the flip side, organizations that migrate early get real advantages. You’re compliant before it’s mandatory. Your customers trust you more than the competitors who are still scrambling. Your risk posture is genuinely better. And when Q-Day actually arrives, you’re watching the news instead of being in the news.

Where Things Stand Now

The good news is that migration is actually happening. Major tech companies and cloud providers are rolling out PQC support. CDNs are enabling post-quantum encryption. TLS libraries have added hybrid cipher suites. A meaningful chunk of internet traffic is already using quantum-resistant algorithms, at least in hybrid mode.

This isn't just NIST acting alone; this is a global effort.

The Post-Quantum Cryptography Coalition, comprising researchers from over 100 organizations in industry and academia, is working on standardization harmonization, implementation guidance, and coordinating global migration efforts. This isn’t just NIST acting alone; this is a global effort.

But there’s still a massive gap between awareness and action. When you survey cybersecurity professionals, most of them understand that quantum computing is a threat. But when you ask how many organizations have actually started migration planning? The numbers drop off a cliff. Lots of people know this is coming. Very few are doing anything about it yet.

That gap needs to close, and fast.

The Bottom Line

You’ve got a hundred priorities competing for budget and attention. Quantum computing feels like a future problem, and you’ve got plenty of present-day problems to deal with. But here’s the thing: HNDL attacks are happening right now. Your encrypted data is likely being collected and stored as we speak.

The good news is we’re not starting from zero. NIST has published solid standards. The crypto community has done the hard work of designing and vetting quantum-resistant algorithms. Major vendors are adding support. The pieces are in place.

The bad news is that migration is going to take years, it’s going to be expensive, and it’s going to be painful. Which means if you’re not starting now, you’re already behind.

You don’t need to migrate everything tomorrow. But you do need to start an inventory of your crypto, classify your data, identify your highest-risk systems, build a plan, and allocate budget. Start having conversations with vendors. Test PQC in your environment. Build cryptographic agility into new systems.

Q-Day is coming. We don’t know exactly when, but the trend line is clear. And when it arrives, the organizations that prepared will survive. The ones that didn’t will be case studies in what not to do. lock

Key References and Sources

NIST Standards and Guidelines

NIST Post-Quantum Cryptography Project: https://csrc.nist.gov/projects/post-quantum-cryptography

FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final

FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final

FIPS 205 (SLH-DSA): https://csrc.nist.gov/pubs/fips/205/final

Industry Organizations and Coalitions

Post-Quantum Cryptography Coalition: https://pqcc.org/

Cloudflare Post-Quantum Blog: https://blog.cloudflare.com/post-quantum-to-origins/

Embracing the Quantum Era Cisco Blog: https://blogs.cisco.com/security/navigating-the-quantum-shift-with-pqc

Technical Background

Shor’s Algorithm (Wikipedia): https://en.wikipedia.org/wiki/Shor%27s_algorithm

Grover’s Algorithm (Wikipedia): https://en.wikipedia.org/wiki/Grover%27s_algorithm

Post-Quantum Cryptography (Wikipedia): https://en.wikipedia.org/wiki/Post-quantum_cryptography

Threat Analysis and Research

Harvest Now, Decrypt Later Overview: https://www.hashicorp.com/en/blog/harvest-now-decrypt-later-why-today-s-encrypted-data-isn-t-safe-forever

Palo Alto Networks Quantum Threat Analysis: https://www.paloaltonetworks.com/cyberpedia/what-is-q-day

Implementation Guidance

Encryption Consulting PQC Migration: https://www.encryptionconsulting.com/how-to-start-your-enterprise-post-quantum-cryptography-migration-plan/

MITRE PQC Readiness Guide: https://www.mitre.org/news-insights/news-release/post-quantum-cryptography-coalition-unveils-pqc-migration-roadmap

Sectigo PQC Timeline: https://www.sectigo.com/resource-library/quantum-computing-timeline-things-to-know

Additional Resources

PQShield Industry Analysis: https://pqshield.com/wp-content/uploads/2025/09/Market-Trends-Report-2025-Quantum-FINAL-1.pdf

The Quantum Insider: https://thequantuminsider.com/

CyberArk Quantum Security: https://www.cyberark.com/what-is/post-quantum-cryptography/

Gurdeep Gill

Abbreviations and Acronyms

AES – Advanced Encryption Standard

CDN – Content Delivery Network

CPU – Central Processing Unit

ECC – Elliptic Curve Cryptography

ECDH – Elliptic Curve Diffie-Hellman

ECDSA – Elliptic Curve Digital Signature Algorithm

EHR – Electronic Health Record

EU – European Union

FDA – Food and Drug Administration

FIPS – Federal Information Processing Standards

HIPAA – Health Insurance Portability and Accountability Act

HNDL – Harvest Now, Decrypt Later

IoT – Internet of Things

M&A – Mergers and Acquisitions

ML-DSA – Module-Lattice-Based Digital Signature Algorithm

ML-KEM – Module-Lattice-Based Key Encapsulation Mechanism

NIST – National Institute of Standards and Technology

PQC – Post-Quantum Cryptography

Q-Day – Quantum Day (when quantum computers become capable of breaking current encryption)

R&D – Research and Development

RSA – Rivest–Shamir–Adleman (public-key cryptosystem)

SCADA – Supervisory Control and Data Acquisition

SLH-DSA – Stateless Hash-Based Digital Signature Algorithm

SSH – Secure Shell

TLS – Transport Layer Security

VPN – Virtual Private Network

Y2Q – Year to Quantum (alternative term for Q-Day)

Leave a Comment