Your Encrypted Data Isn’t “Safe Until Quantum Arrives.” It’s Being Stolen *Because* Quantum Is Coming—And the 2026 Deadline Most Companies Miss Is the Inventory, Not the Math.
Attackers don’t need quantum computers yet—they just need your encrypted data to stay valuable long enough. The real bottleneck is discovering where RSA/ECC hide across apps, PKI, devices, and vendors before your ecosystem’s 2026–2028 clock forces change.
Key Points
- 1Assume “harvest now, decrypt later” is already happening: encrypted traffic and databases can be stolen now and decrypted years later.
- 2Prioritize crypto inventory over algorithm shopping: the toughest work is finding every RSA/ECC dependency across apps, PKI, hardware, and vendors.
- 3Plan on a 2026–2028 ecosystem clock: vendor roadmaps, procurement pressure, and migration lead times make waiting for certainty expensive.
A decade from now, the most damaging breach your organization suffers may not look like a breach at all. It may look like a quiet copy—an archive of encrypted traffic or a stolen encrypted database—taken today, filed away, and opened later when the locks finally fail.
Security teams tend to picture “Q‑Day” as a single dramatic moment when quantum computers suddenly crack the internet. The more realistic—and more uncomfortable—story is slower. Adversaries don’t need a quantum machine in 2026 to profit from quantum risk in 2036. They only need your data to remain sensitive long enough.
That idea has a name: “harvest now, decrypt later” (HNDL). It’s not a slogan from vendor slide decks; it’s an explicit focus of government analysis. A U.S. Federal Reserve working paper, last updated January 30, 2026 (paper dated September 2025), describes HNDL as a “present and ongoing” threat to data protected by today’s public‑key cryptography, using distributed ledger networks as an illustrative case. Meanwhile, U.S. agencies—including CISA, NSA, and NIST—frame quantum readiness as immediate operational work: inventory your cryptography, pressure your vendors, and build a migration roadmap.
Confidentiality can fail retroactively.
— — TheMurrow Editorial
The hard part isn’t choosing a new algorithm. The hard part is finding where the old one is hiding.
The threat that arrives before the quantum computer
“Harvest now, decrypt later” in plain language
Information with a long confidentiality lifespan
- ✓national security data
- ✓long‑lived intellectual property
- ✓health records and biometric identifiers
- ✓industrial control details and infrastructure information
- ✓certain financial records
- ✓sensitive legal communications
Not every breach is “because quantum is coming.” Many attacks are opportunistic and would happen regardless. HNDL is the incremental reason to steal encrypted data that is likely to remain valuable in 5–15+ years—the wedge that turns today’s “safe enough” encryption into tomorrow’s liability.
Why government guidance treats this as a current risk
Quantum readiness starts with a spreadsheet, not a breakthrough.
— — TheMurrow Editorial
For editorial clarity, readers should separate two claims:
1. Quantum computers don’t have to exist at scale yet for HNDL to be rational.
2. HNDL doesn’t explain every breach—only the portion targeting long-lived secrets.
The result is a present-day prioritization problem: decide which data you can afford to be readable later.
What quantum breaks—and what it doesn’t
The concentrated risk: public-key cryptography
- key exchange / key establishment (for example, RSA key transport, Diffie‑Hellman, ECDH)
- digital signatures (for example, RSA signatures, ECDSA, EdDSA)
These systems power the trust layer of modern computing: TLS handshakes, certificate chains, software updates, device identity, and authentication flows. If those mechanisms become forgeable or decryptable, “secure” channels and “trusted” software can degrade quickly.
Symmetric cryptography is different
Pragmatically, most organizations will not “replace encryption.” They will replace the public‑key components embedded in protocols and PKI, while validating symmetric settings and operational practices.
The crisis isn’t ‘encryption is dead.’ The crisis is that the internet’s handshake and signature system has an expiration date.
— — TheMurrow Editorial
A sober framing helps readers allocate budget. A panic framing helps no one.
The deadline most teams miss: finding your cryptography
Cryptography is scattered across the enterprise
Where crypto hides
- ✓application code (custom implementations, libraries)
- ✓protocols (TLS, SSH, QUIC, VPNs)
- ✓identity and trust systems (PKI, certificate chains, code-signing)
- ✓hardware roots of trust (HSMs, TPMs, smartcards, embedded secure elements)
- ✓vendors and managed services (cloud KMS/HSM, SASE, CDNs, IoT platforms)
CISA/NSA/NIST explicitly emphasize cryptographic inventory and supply-chain engagement because most organizations can’t migrate what they can’t see. Teams also tend to discover “crypto surprises”: old services kept alive for one business partner, firmware that can’t be updated, appliances whose certificate stacks are frozen in time.
Crypto agility: the second-order problem
That insight is easy to underestimate. Organizations that “complete a migration” but hard-code assumptions may end up repeating today’s scramble in a few years, just with different acronyms.
Why 2026 keeps showing up in roadmaps (without becoming a universal law)
Europe: start transitioning by end of 2026
UK: discovery and assessment done by 2028—implying earlier starts
U.S. national-security gravity pulls the market
The key takeaway for executives is not “your company is legally required to finish by 2026.” It’s “your ecosystem is likely to change on a 2026–2028 clock.” Waiting for perfect certainty is a strategy—and a costly one.
Key takeaway for executives
Case studies in slow-moving risk: ledgers, PKI, and long-lived systems
Distributed ledgers as a stress test
Ledgers highlight a broader enterprise truth: systems built for persistence tend to accumulate dependencies. When a signature scheme or key establishment mechanism sits at the base layer, migration becomes governance, coordination, and rollout discipline—not just a technical patch.
PKI and code-signing: the quiet single points of failure
These are also the systems least likely to be owned by one team. Security may run policy, IT may run certificates, engineering may run build pipelines, and vendors may run firmware signing. Quantum readiness exposes organizational seams.
A practical plan: what to do in the next 90 days
Start with an inventory you can actually finish
Four questions for a first-pass crypto inventory
- ✓Where do we use RSA/ECC for key exchange and signatures?
- ✓Which systems protect data with long confidentiality lifetimes?
- ✓Which dependencies are vendor-controlled (cloud services, appliances, embedded devices)?
- ✓Which components are hardest to change (hardware roots of trust, legacy platforms)?
Treat “unknown” as a category worth tracking. Unknown is where risk hides.
Engage vendors early—and in writing
Useful vendor questions include:
Vendor questions to ask now
- ✓Which PQC approaches are planned, and on what timeline?
- ✓Will updates require hardware replacement (TPMs, secure elements, smartcards)?
- ✓How will certificate chains and signing infrastructure transition?
- ✓What is the rollback plan if guidance changes (crypto agility)?
Vendor answers need to be captured and revisited. A migration plan built on hand-waving collapses under procurement scrutiny later.
Build crypto agility into procurement and architecture
The best time to bake agility in is when systems are being built or bought. Retrofitting it later is where budgets go to die.
Editor's Note
The balanced view: skepticism, realism, and what not to claim
The skeptical case: “quantum is too far away”
Those points matter. Over-indexing on PQC while ignoring present vulnerabilities is how organizations lose twice: now to conventional threats, and later to retroactive exposure.
The realist case: time-to-migrate is the real enemy
- cryptography is embedded in long-lived systems
- dependencies are distributed across vendors and business units
- trust systems (PKI, code-signing) require careful coordination
- guidance and standards evolve, creating the need for agility
Government bodies are signaling the same conclusion in different accents. The Federal Reserve paper frames HNDL as ongoing. CISA/NSA/NIST emphasize inventory and roadmaps. NIST emphasizes agility. The UK NCSC sets a discovery-and-assessment horizon of 2028 and estimates 2–3 years for large organizations to complete that early phase. The EU message pushes Member States to begin transitioning by end of 2026.
A reasonable editorial stance follows: the prudent response is not panic, but timelines. Organizations should behave as if the work will take longer than expected—because it usually does.
Conclusion: the story isn’t Q‑Day—it’s the years before it
Once that’s answered, the rest is discipline. Build a cryptographic inventory. Identify the public‑key choke points. Pressure vendors for roadmaps. Design for crypto agility so you can adjust as standards and guidance evolve.
The mistake isn’t failing to predict when quantum computers arrive. The mistake is assuming your encrypted data is safe simply because it is encrypted today.
Frequently Asked Questions
What does “harvest now, decrypt later” actually mean?
Adversaries can copy encrypted network traffic or steal encrypted datasets now, then store them until decryption becomes feasible later—potentially using quantum computing against today’s public‑key cryptography (RSA/ECC). The risk is retroactive: data that seems protected today may be readable in the future if it remains valuable long enough.
Is this just a problem for governments and intelligence agencies?
No, but the strongest incentive applies to data with long confidentiality lifetimes: health records, biometrics, long-lived IP, sensitive legal communications, industrial control details, and certain financial records. Government guidance matters because it influences vendors and procurement ecosystems that commercial organizations depend on.
What cryptography is most threatened by quantum computers?
The main concern is public‑key cryptography used for key exchange (RSA, Diffie‑Hellman/ECDH) and digital signatures (RSA signatures, ECDSA/EdDSA). The UK NCSC and other guidance emphasize that symmetric cryptography (like AES) is affected differently and is not the core “break everything” story.
Why do agencies keep telling organizations to build a cryptographic inventory?
Because migration fails when organizations don’t know where cryptography is used. CISA/NSA/NIST quantum-readiness guidance highlights inventory, vendor engagement, and supply-chain assessment as immediate steps. Teams typically find cryptography embedded in apps, protocols, PKI, hardware roots of trust, and third-party services.
Is there a real 2026 deadline for companies?
There’s no universal global deadline that applies to every company. But multiple roadmaps create pressure in the mid‑2020s: the EU has urged Member States to start transitioning by the end of 2026, and the UK NCSC timeline expects discovery and assessment completed by 2028, estimating large organizations may need 2–3 years for that early phase—implying work should start well before 2028.
What is “crypto agility,” and why does it matter for PQC?
NIST’s December 19, 2025 guidance frames crypto agility as the ability to change cryptographic algorithms and parameters without rebuilding entire systems. It matters because standards and implementation guidance evolve, and most organizations run long-lived, heterogeneous systems. Agility helps avoid turning each cryptographic transition into a crisis.
