Harvest Now Decrypt Later
Harvest Now, Decrypt Later, or Decrypt Later, Damage Forever… Attackers are already collecting data.
If you work in security long enough, you eventually realize that most “future threats” are simply today’s threats with better marketing. Quantum computing is a perfect example. For years, it has been treated as a science‑fiction subplot in which a mysterious machine appears one day, breaks RSA in an instant, and forces everyone to gather in a war room and deploy post‑quantum cryptography. Until that moment arrives, the assumption goes, we just keep calm and rotate our keys.
While people were busy telling that story, more capable operators quietly lost interest in the hype and went back to doing what they have always done. They started stealing. They did not focus only on credentials or unpatched servers. Instead, they went after the one category of data that still helps many defenders sleep at night: encrypted information. They grab full packet captures from TLS sessions, VPN tunnels, mailbox archives, database backups, and SIEM cold storage. In practice, they harvest anything that appears as high‑entropy noise moving through or sitting behind your controls.
The crucial point is that they do not care that they cannot read this data today. That is the entire strategy.
“Harvest Now, Decrypt Later,” often shortened to HN/DL, can be summed up in a single idea. Treat every environment as a long‑term data mine. Exfiltrate as much encrypted material as possible right now, store it cheaply, and wait. Time, hardware improvements, and new cryptanalytic techniques do the hard work on the attacker’s behalf. When algorithms weaken, when keys leak, when implementations are broken, or when quantum computers become practically usable, the adversary returns and replays history with a decryption capability you never planned for.
The uncomfortable truth is that this is not a theoretical scenario. If you look honestly at most modern environments, whether they belong to enterprises, managed service providers, managed detection and response vendors, SaaS platforms, or governments, you will see that they are already optimized for HN/DL from an attacker’s point of view. We centralize everything in the name of observability. We keep logs indefinitely to satisfy compliance. We take snapshots of entire tenants, virtual machines, and databases to support business continuity. We aggregate multi‑tenant customer data into a few large “security operations” repositories because this approach makes detection engineering and hunting easier.
On a maturity model slide for defenders, this centralization looks impressive. A collection plan for an adversary looks like winning the lottery.
The deepest trap lives in the mental shortcut we fall back on when we write post‑incident reports. We often conclude that exfiltration occurred, but because the data was encrypted, the impact is limited. That single sentence completely contradicts HN/DL thinking. It assumes your cryptographic choices will age gracefully, your key management will remain flawless, and no well‑resourced attacker is prepared to wait.
In this post, I want to treat HN/DL not as a buzzword but as a threat lens. I will break down what “harvest now, decrypt later” looks like in real operations, which assets and sectors are most exposed, why MDR providers and centralized security platforms are turning into high‑value harvest targets, and how to build a realistic, non‑hyped response plan if you are responsible for environments that must remain safe far beyond a single product roadmap.
What HN/DL actually is?
At a purely technical level, “Harvest Now, Decrypt Later” is a long‑game data theft strategy. Instead of only going after data they can immediately read, attackers systematically steal encrypted information, store it, and wait for the world to make it readable for them.
The model is brutally simple. First comes the harvest. An adversary gets a foothold somewhere meaningful: a hypervisor, an MDR platform, a backup environment, a VPN concentrator, a mail server, a cloud storage bucket, or a logging pipeline. From there, they prioritize anything that looks like high‑entropy garbage: TLS packet captures, VPN traffic, mailbox archives, full database backups, disk images, cold SIEM storage, object‑store snapshots. They do not bother trying to parse the content or break the crypto in real time. They just tag, compress, and exfiltrate as much of it as their access and bandwidth allow.
Then comes the “later” phase. That may be months, years, or more than a decade away. Over that period, three things evolve in the attacker’s favor: hardware gets faster and cheaper, new cryptanalytic techniques and implementation bugs are discovered, and at some point, post‑quantum attacks against widely deployed algorithms may become practical. The stolen encrypted blob you treat as “noise” today will quietly become a searchable, mineable history of your environment once the right keys, exploits, or algorithms exist.
The core idea is that encryption is not a permanent guarantee. It is a moving contract between the attacker’s resources and the defender’s cryptography choices. HN/DL assumes that the contract will eventually tilt toward the attacker, so the rational move is to collect as much as possible now and let time do the heavy lifting.
Seen through that lens, HN/DL is not about a specific exploit or a new malware family. It is a mindset layered atop every intrusion where data exfiltration is possible. Any place where you centralize, archive, or retain encrypted data at scale becomes a future decryption target, whether you realize it or not.
Why It’s a Problem Even Before Quantum Is “Here”
Even before large‑scale quantum computers exist, “harvest now, decrypt later” is already a serious problem because it weaponizes time and architecture, not just math. The moment an attacker pulls a full encrypted backup from your MDR data lake, a mailbox archive from your cloud tenant, or years of TLS traffic from a VPN concentrator, the damage is done. You do not get a second chance to protect that history. From that point on, your risk is chained to every future weakness in your cryptography, key management, and implementations.
The first reason HN/DL matters now is data half‑life. Most organizations hold information that remains sensitive for a decade or more: identity data, legal disputes, long‑term contracts, product roadmaps, source code, diplomatic cables, financial records, and health data. If someone can read all of that in ten years, your “encryption at the time” is irrelevant. They will be mining an unpatched version of your past.
The second reason is that cryptography erodes in practice long before it collapses in theory. We do not need full‑scale quantum to start seeing real‑world breaks. We need one catastrophic implementation bug in a widely deployed library, one systemic key management failure in a cloud provider, or one downgrade vector in a protocol that looked fine on paper. When that happens, the attacker who has been quietly stockpiling ciphertext suddenly finds themselves sitting on a searchable archive.
The third reason is that our architectures already favor the harvester. We centralize everything into MDR platforms, SIEMs, data lakes, and backup vaults; we retain “for compliance” far beyond what we actually use; we mirror entire tenants and tenants‑inside‑tenants in MSP scenarios. From an operator’s perspective, that is operational maturity. From an adversary’s perspective, it is a collection pipeline they did not have to build.
So even if quantum timelines slip indefinitely, the HN/DL mindset punishes defenders for three things they are already doing: keeping too much, centralizing too hard, and trusting that “encrypted” means “safe enough forever.” The threat is not waiting for a magic computer. It is leveraging the inevitability that your current crypto assumptions will age, while your stolen data will not.
Who’s at Risk?
The uncomfortable thing about HN/DL is that it is almost perfectly aligned with how modern organizations actually work. The risk surface is not evenly distributed but is broad.
Governments and intelligence agencies sit at the top of the list. They generate and store data with extremely long sensitivity windows: diplomatic cables, intelligence reports, source identities, operational plans, treaty drafts, export‑control files. A decade‑delayed decryption of those archives can expose human sources, retroactively reveal covert operations, and give adversaries precise insight into negotiation strategies. When that material is centralized into national SOCs, joint data lakes, or cross‑agency analytics platforms, a single intrusion can yield a generational collection win for an opposing state.
Managed service providers and MDR vendors are the next obvious target. By design, they ingest and retain telemetry, logs, alerts, and often packet captures from dozens or hundreds of customers. That telemetry is frequently “encrypted at rest” in shared infrastructure, but the important fact for HN/DL is that it is concentrated. If a threat actor compromises an MDR data store today and quietly exfiltrates SIEM cold storage, EDR telemetry, and backup snapshots, they are not stealing one environment’s history. They are stealing many. In a future where cryptographic controls weaken, that single breach becomes a time machine into every customer network that MDR ever monitored.
SaaS platforms and cloud‑native startups carry similar structural risk. Multitenant databases, message queues, and backup regimes often mix customer data in ways that are clean logically but messy from a long‑term confidentiality perspective. Product roadmaps, unreleased features, pricing models, customer conversations, and ML training data all have multi‑year value. When that material is archived for “analytics later,” it quietly becomes “decryption target later” for anyone already harvesting.
Small and medium enterprises are at risk not because they are juicy per unit, but because they are harvested in bulk. SMEs rely heavily on third‑party SaaS, cloud platforms, MSPs, and outsourced IT. If you compromise the shared backup platform serving hundreds of SMEs, you do not need to care who they are today. You simply pull encrypted snapshots and let time decide which ones are interesting.
Finally, activists, journalists, NGOs, and dissidents face a different flavor of danger. Their threat is not losing a product roadmap; it is long‑term deanonymization and retroactive repression. Encrypted chat logs, email archives, funding records, travel plans, and contact networks might sit unreadable for years in state or quasi‑state archives. When decryption becomes easier, that history can be replayed to map relationships, identify informants, and justify crackdowns long after the original conversations felt “ephemeral.”
HN/DL, in other words, tracks closely with who produces long‑lived, high‑impact data and who centralizes it. That list is uncomfortably close to “almost everyone,” but governments, MSPs/MDRs, SaaS, SMEs, and civil society each experience the blast radius differently.
Threat Actors and Realistic Scenarios
If you strip away the marketing gloss, HN/DL boils down to a couple of very old ideas: collection, patience, and leverage. The threat actors who benefit most are the ones who can afford all three.
Nation‑state intelligence services are the canonical example. They already run massive collection programs, are comfortable holding data for decades, and have a strategic incentive to read not just what you say today, but what you said ten years ago when you thought no one was watching. An intranet backup, a diplomatic archive, or an MDR tenant serving allied governments is perfect fuel for that machine. They do not need to decrypt immediately; they just need to make sure nothing is lost.
But you do not have to be a three‑letter agency to think this way. Well‑funded criminal syndicates and “semi‑official” groups can absolutely justify archive‑style harvesting when the cost of storage is low, and the potential upside is high. Imagine a group that systematically targets backup providers, MSP platforms, and log storage services. Today, they ransom what they can read directly and sell access to live environments. In the background, they also keep copies of anything that appears to be encrypted customer data. If a major cryptographic break, cloud key leak, or widely exploitable implementation bug appears in five years, they suddenly possess a searchable dataset of historical secrets, financials, and identities.
Realistic HN/DL scenarios are not exotic. A compromised MDR platform quietly exfiltrates cold storage from its SIEM cluster each month, wrapped as “off‑site backup.” A malicious insider at a cloud provider siphons snapshots of high‑value customer databases, trusting that keys or implementation flaws will surface later. An APT sits on a VPN concentrator, capturing encrypted sessions at scale and waiting for a key leak, a downgrade vulnerability, or a practical quantum‑assisted attack to make those captures readable.
The common thread is that these actors see encrypted data as an asset, not a dead end. They collect first, label it carefully, and let the rest of us do the hard work of weakening our own defenses over time.
How to Respond: Crypto‑Agility, Data Triage, and Governance
Responding to HN/DL is not about buying a “quantum‑safe” box. It is about redesigning how your organization makes, stores, and ages secrets so that a breach today does not automatically become a crisis years from now.
The starting point is data triage. You need a living inventory of what actually matters over long time horizons. That includes identity data, customer PII, financial records, legal disputes, source code, signing keys, and the MDR‑style telemetry that can be used to reconstruct entire environments. For each category, you should ask how long it must remain confidential and where it actually lives: primary systems, backups, analytics stores, and log archives. Without that map, “post‑quantum” is just a slide.
On top of that inventory, you need real crypto‑agility. That means abstracting cryptographic choices out of application code, avoiding hard‑wired algorithms and key sizes, and centralizing as much of your crypto policy as is practical. You should be able to rotate keys, upgrade ciphers, and introduce post‑quantum algorithms without rewriting half your stack. In MDR and SaaS environments, that agility has to extend across tenants, regions, and pipelines, or you will end up with islands of legacy crypto that attackers can specifically target.
Key management is the next pillar. Long‑lived keys, especially for signing and identity, are toxic assets. Store them in hardened systems, minimize copies, enforce strict access controls, and shorten lifetimes wherever uptime allows. Treat snapshots and backups of key management systems as critical assets in their own right. A future compromise of those backups can turn years of “encrypted at rest” into plain text overnight.
Finally, you need governance over retention and logging. It should no longer be acceptable to keep everything forever “just in case.” For each major data store, you should have explicit retention periods, deletion processes, and monitoring for large‑scale export of encrypted archives. Cold SIEM storage, MDR telemetry lakes, and backup vaults need the same level of attention as production databases because, in an HN/DL world, they are the attacker’s primary prize.
Put bluntly, responding to HN/DL is less about predicting quantum timelines and more about refusing to be your own worst archivist.
This Quarter vs. “When NIST Is Done”
It is tempting to treat HN/DL as something you will tackle “after NIST finishes the post‑quantum story” or “once the vendors ship stable PQC bundles.” That is a comfortable lie. By the time the standards dust fully settles, any attacker who cares about you will already have years of your encrypted history on disk.
So what is worth doing in the next quarter, not the next decade?
First, produce a brutally honest map of your long‑lived data and keys. Identify which backups, archives, MDR stores, and log platforms hold material that will still hurt you if it is decrypted ten years from now. Put owners and retention targets next to each one. This is not glamorous, but it is the foundation for every other decision.
Second, pick two or three high‑value systems and make them crypto‑agile for real. That might be your MDR telemetry lake, your customer database, or your code‑signing infrastructure. Design and implement a pattern where you can swap algorithms, rotate keys aggressively, and prove in tests that you can migrate without taking the business down. Treat this as a reference implementation you can clone elsewhere, not a one‑off hero project.
Third, change how you think about exfiltration. Update your detections, playbooks, and incident templates so that “it was encrypted” is no longer accepted as an excuse to downplay impact. Force every investigation to answer what was taken, how long it matters, and what the HN/DL implications are for your specific environment.
“Someday, when NIST is done,” you will absolutely need to roll out new algorithms and protocols. That work will be hard, but it will also be commoditized. The posture that will actually differentiate you is whether you spent the years before that moment quietly reducing your archival blast radius, cleaning up key management, and making your systems agile. HN/DL punishes procrastination. The organizations that come out ahead are the ones that start acting as if someone is already recording everything they encrypt, because in many cases, someone is.
More info about Harvest Now, Decrypt Later from different angles.
