Why Post-Quantum Cryptography Is Urgent Even Though No Quantum Computer Has Broken RSA Yet

There’s a common misreading of the post-quantum cryptography (PQC) conversation: people assume the urgency comes from a quantum computer that can already crack RSA or ECC today. It can’t, not yet, and probably not for some years. But that’s not actually why PQC needs to move now. The real driver is a mismatch between two clocks: the migration clock, which runs long, and the data-theft clock, which is already running.

This piece walks through why that mismatch matters, and why PQC doesn’t behave like the two “deadline” analogies people reach for most often are Y2K and IPv4 exhaustion.

The real driver: harvest now, decrypt later

The core risk behind PQC urgency has a name it’s harvest now, decrypt later (HNDL), sometimes written “store now, decrypt later.” The idea is simple. An adversary intercepts or exfiltrates encrypted traffic or data today :TLS sessions, VPN traffic, archived backups, database dumps and simply holds onto the ciphertext. They don’t need to break the encryption now. They wait. Once a cryptographically relevant quantum computer exists, they decrypt what they’ve been sitting on.

A recent 2026 analysis of HNDL feasibility across TLS 1.2, TLS 1.3, QUIC, and SSH frames this precisely, an HNDL attack records encrypted communications today and decrypts them once a quantum computer can break the key exchange underneath, and the risk is sharpest for data that needs to stay confidential for a long time. The same paper’s more striking finding is economic rather than cryptographic, once an adversary can access encrypted traffic in the first place, retaining that traffic costs them almost nothing. The real question shifts from “can they archive it” to “how much will decrypting it eventually cost them,” and that cost keeps falling as quantum hardware matures.

Other literature reframes this as a temporal cybersecurity risk rather than a purely technical one. A 2025 telecom-sector study models HNDL exposure across industries with different data-retention profiles, and finds that sectors holding data for a long time for examples satellite communications and health records were the examples used are facing exposure windows stretching for decades if PQC migration is delayed, while hybrid key exchange and forward-secure protocol design can cut that exposure window by more than two-thirds. That’s the mechanism: it’s not that quantum computers are imminent, it’s that the shelf life of stolen ciphertext already extends into the era when they might exist.

A separate framing worth keeping in mind, aimed at practitioners rather than researchers: the true PQC migration deadline is effectively now, precisely because the HNDL threat model means adversaries are plausibly already exfiltrating long-lived encrypted data in anticipation of future decryption. Under that model, the sensible response isn’t “wait for Q-Day,” it’s building crypto-agility today and knowing what cryptography you run, where, and how fast you could swap it out.

For an institution like a central bank or a payment authority, this isn’t abstract. State secrets, sensitive financial data, payment-system designs, long-lived private keys, transaction archives, and investigation records are exactly the kind of long-shelf-life data that HNDL targets. If that data is stolen this year and only becomes readable a decade from now, the fact that “quantum computers aren’t operational yet” is cold comfort.

Why PQC isn’t like Y2K

Y2K had a fixed, known deadline: January 1, 2000. If a system’s date logic wasn’t fixed by then, it broke at rollover, a clear, binary failure mode tied to a specific date. Organizations could push remediation right up to the wire, as long as they finished before midnight struck.

PQC has no equivalent date. There is no confirmed “Q-Day” the day a cryptographically relevant quantum computer becomes real. Estimates vary widely, and several serious analyses put meaningful quantum decryption risk as low before 2029 but rising sharply by the early 2030s, with a wide error bar either side. That uncertainty is exactly the trap: because there’s no fixed date, it’s tempting to keep deferring. But unlike Y2K, PQC’s damage is retroactive. Y2K couldn’t reach backward and break dates that had already passed correctly. PQC-related exposure can reach backward and unlock data that was stolen, and looked perfectly secure, years before Q-Day ever arrives.

Why PQC isn’t like IPv4 exhaustion

IPv4 address exhaustion is a scarcity and scalability problem. The internet ran out of room to hand out globally unique addresses, and the industry absorbed the pain gradually such as NAT, private addressing, CGNAT, and IPv6 dual-stack all bought time and softened the transition. It made growth harder and messier, but it didn’t retroactively expose anything that already happened. A network that never migrates to IPv6 doesn’t suddenly leak yesterday’s traffic.

PQC cuts differently because it touches the trust foundation itself: TLS, VPNs, PKI, digital signatures, code signing, HSM integration, device identity, secure boot, API trust, and certificate chains all lean on public-key cryptography that quantum computers are expected to eventually break. If that foundation is weak against quantum attack, the failure mode isn’t “not enough addresses”. It’s confidentiality, authenticity, integrity, and non-repudiation all potentially failing at once, and often silently, since a broken signature or decrypted archive doesn’t page anyone the way an outage does.

Side-by-side

The real strategic risk is lead time, not a deadline

What actually makes PQC a strategic risk rather than a routine technology refresh is how long the migration takes relative to how little warning there’ll be. Swapping cryptographic algorithms isn’t a drop-in change. An organization first has to know where cryptography is even used across TLS, VPN, SSH, PKI, machine certificates, HSMs, legacy applications, API gateways, mobile apps, smart cards, backup encryption, database encryption, signing infrastructure, and third-party vendor appliances.

A 2024 IEEE Access framework for enterprise PQC migration lays out exactly why this is hard: building a cryptographic inventory means mapping algorithms, key storage, certificate chains, protocol and library versions, and even non-technical context like data classification and business ownership, across every one of those systems and most organizations don’t have that inventory today. The same framework notes that PQC’s larger keys and different resource requirements often force protocol and hardware changes, that many hardware accelerators built around today’s algorithms will need replacing, that legacy systems without ongoing vendor support may need retiring outright, and that most organizations simply lack in-house staff with the relevant expertise all of which makes migration slow and expensive by nature, independent of any single deadline.

NIST’s own 2021 guidance on PQC adoption challenges makes a related point: there wasn’t, at the time, an existing inventory of cryptographic dependencies that could even guide the standards and regulatory updates migration would require discovery has to happen before planning can start. That’s the practical translation of “long lead time”: even once an organization decides to act, finding out what needs fixing can itself take a long time.

Standards have matured so “there’s no standard yet” is a weaker excuse

One argument for waiting has been that PQC standards weren’t finalized. That’s no longer true. On August 13, 2024, NIST finalized its first three PQC standards: FIPS 203 (ML-KEM, for general encryption and key exchange), FIPS 204 (ML-DSA, a lattice-based digital signature standard), and FIPS 205 (SLH-DSA, a stateless hash-based signature standard), with all three becoming effective the following day. A fourth algorithm, HQC, was selected for standardization in March 2025, and FALCON is expected as FIPS 206.

That doesn’t mean every organization needs to fully deploy PQC tomorrow. It does mean the “no standard exists” excuse has expired. What’s realistic and achievable now, regardless of industry or Q-Day timing , is starting a cryptographic inventory, building crypto-agility into architecture decisions, piloting hybrid TLS/VPN configurations that combine classical and post-quantum algorithms, and pushing vendors for a concrete PQC roadmap in their products.

The bottom line

PQC urgency isn’t about a quantum computer breaking RSA this afternoon. It’s about the fact that data stolen today can sit quietly for years and still be exposed later, that there’s no fixed date to plan around the way there was with Y2K, and that PQC touches the cryptographic trust fabric in a way IPv4 exhaustion never touched data integrity. Combine that with a migration process that’s inherently slow: inventory, dependency mapping, prioritization, hybrid deployment, vendor coordination and waiting for certainty about Q-Day is itself the risky choice. The organizations that treat this as “eventually” rather than “now, for the data that matters most” are the ones most likely to find their long-lived secrets sitting in someone else’s archive, waiting.