Harvest Now, Decrypt Later: Why Today's Encrypted Data Is Tomorrow's Breach

Harvest now, decrypt later is a simple attack with a long fuse. An adversary captures your encrypted traffic today, stores it, and waits. They can’t read it yet. They’re betting that a future quantum computer will break the encryption protecting it, at which point the stored data becomes readable in bulk.

That bet is the subject of episode 96, where Kevin Kane, co-founder and CEO of American Binary, joined us to talk post-quantum encryption. The episode title says it plainly: they don’t need to hack you now. They just need to wait.

The uncomfortable part is that the attack works against data you already sent. Encryption you trusted last year, last week, or this morning is only as durable as the math behind it. If that math falls, every copy an attacker quietly saved falls with it. The encouraging part, and the reason this post exists, is that the replacement math is finished, standardized, and already running in the browser you’re reading this in. What’s left is a migration, and migrations reward the teams that start early.

What is a harvest now, decrypt later attack?

Harvest now, decrypt later (HNDL, or “store now, decrypt later”) is the practice of collecting encrypted data you cannot currently read, keeping it, and decrypting it once a cryptographically relevant quantum computer exists. The White House memorandum that set the US government’s post-quantum deadlines, NSM-10 of May 2022, describes that machine as one that “will be capable of breaking much of the public-key cryptography used on digital systems across the United States and around the world.”

Three properties make the attack unusual.

It is passive. Recording ciphertext off a fiber link or a peering point produces no login, no malware, no alert. Nothing happened on your systems, so nothing shows up in your monitoring.

It is patient. The archive gains value with time: the attacker collects for years and cashes out once.

And it is retroactive. Patching in 2031 does nothing for what you sent in 2026, which makes this the one item on your roadmap where the attacker’s timeline, not yours, decides when the work was due.

Kane’s assessment of who is doing this today is blunt (his claim, not ours):

“It’s a harvest attack. The Chinese government has been recording internet traffic somewhere between 10 and 15 years. They’ve recorded every packet. They continue every day to record every packet from every mobile device and every computer and every electronic device that transmits information by radio or internet.”

Kevin Kane, co-founder and CEO of American Binary, on episode 96

Nobody outside an intelligence agency can verify the scale; a passive collector leaves nothing to audit. What is public is how the people running the largest networks on earth talk about it. Google’s security leadership wrote in March 2026 that “the threat to encryption is relevant today with store-now-decrypt-later attacks,” and Cloudflare now reports its post-quantum rollout as the share of traffic “protected against harvest-now/decrypt-later.” Both talk about it in the present tense, and that is the sensible default for you too.

Why RSA, Diffie-Hellman and elliptic curves are the weak point (and AES isn’t)

Nearly all encrypted internet traffic depends on public-key cryptography to set up a secure session. Two ideas do most of that work: RSA, and the Diffie-Hellman key exchange, the way two parties who’ve never met agree on a shared secret over a public network (most modern connections use its elliptic-curve form, ECDH). Kane described how central this one mechanism is: “There is a particular key exchange called the Diffie-Hellman key exchange, and it guides everything on the internet. Every email, every WhatsApp message, every VTC connection that’s encrypted uses this key exchange.” His plain-English definition is worth keeping: “A key exchange is, I’m going to send you, encrypted, some secret information, and I’m going to send you over a key that you can then use to receive the secret information that’s about to come.”

That concentration is why the quantum threat is systemic. RSA and Diffie-Hellman both rest on math problems (factoring large numbers, computing discrete logarithms) that are hard for today’s computers and easy for a large enough quantum computer running Shor’s algorithm. Recover the session key from a recorded handshake and the whole conversation opens.

The symmetric encryption protecting the message contents is a different story. AES-256 is untouched by Shor’s algorithm; the best known quantum attack on it, Grover’s, roughly halves the effective key length, which is why the NSA’s post-quantum suite keeps AES-256 as-is. Signatures (RSA, ECDSA, EdDSA) do fall to Shor, but a forged signature needs the quantum computer to exist first, so nothing recorded today becomes forgeable retroactively. The break that matters for harvest now, decrypt later is the handshake that sets everything up.

How long until Q-Day? What the timelines actually say

No one can name the date. The industry calls the moment a quantum computer can break current public-key encryption “Q-Day,” and the honest estimates are probability ranges. In the Global Risk Institute’s Quantum Threat Timeline Report 2025 (published March 2026), Michele Mosca and Marco Piani surveyed 26 experts, who rated a cryptographically relevant quantum computer “quite possible (28-49%) within the next 10 years, and likely (51-70%) in the next 15.”

Planning dates are firmer, and they keep moving closer:

• 2029. Google’s security leadership announced in March 2026 that it is “setting a timeline for post-quantum cryptography migration to 2029” for its own systems. Kane pointed to it on the episode as the benchmark to mirror: “Google said by 2029, we should be concerned.”
• 2030. NIST’s draft transition plan, IR 8547 (initial public draft, November 2024), proposes that RSA, ECDSA and EdDSA at 112-bit security strength, the RSA-2048 class, be “deprecated after 2030,” meaning they may still be used but carry acknowledged risk.
• 2035. The same draft proposes that quantum-vulnerable public-key algorithms be “disallowed after 2035,” matching NSM-10’s goal of “mitigating as much of the quantum risk as is feasible by 2035.” The NSA’s CNSA 2.0 advisory sets the same 2035 finish line for national security systems, with milestones on the way: VPNs and routers should “exclusively use CNSA 2.0 by 2030,” browsers, cloud services and operating systems by 2033.

Kane is careful about timing without pretending to predict it:

“When we started this company, the time was not here, and it wasn’t here two years ago, and it’s starting to come here now. But two years later, it’s going to super be here. And four years later, super be here. But if you wait too late to start, you’re not going to catch up.”

Kevin Kane, American Binary, episode 96

For defenders, the exact date is the wrong thing to fixate on. Harvest now, decrypt later turns the timeline into a subtraction problem with a name, Mosca’s inequality: take the years your data must stay secret (x), add the years your migration will take (y), and compare the sum with the years until Q-Day (z). If x + y is greater than z, the data is already exposed. You don’t get to wait for certainty, because the harvesting is happening now. The useful part is that y is the only term you control, and every quarter you take off it moves data from the exposed column to the safe one.

Which data is already at risk? Data shelf life decides

The risk scales with how long the information must stay secret. A session token that expires in an hour is worthless to an attacker who can only decrypt it in 2032. The highest-risk categories share one trait, a long secrecy lifetime:

• Health and genetic records, still sensitive decades later.
• Financial, insurance, and tax data, useful for fraud long after capture.
• Government, defense, and diplomatic communications. The NSA’s reasoning in its CNSA 2.0 FAQ applies to any vendor holding government data: “Because NSS often have very long lifecycles, NSA must produce requirements today for systems that will be used many decades in the future.” Under ITAR or CMMC, your data’s shelf life is set by your customer’s classification schedule, not your retention policy.
• Source code, designs, and trade secrets.
• Long-lived keys and certificates, the material that protects other systems.

Kane’s example for the fourth category came from a talk he gave at KAIST, one of South Korea’s top engineering schools:

“Many of their parents saved up to send them to that school. But for what? They will develop R&D and new technology that the Chinese government will just steal because they’re recording the network traffic.”

Kevin Kane, American Binary, episode 96

The last category, keys, is the quiet multiplier, and the same logic that makes device-bound credentials harder to steal applies: the longer a secret lives and the more it protects, the more it’s worth harvesting today. Two places startups forget are backups and archives. An immutable backup is an encrypted copy of your most valuable data designed to sit untouched for years, exactly the profile a harvester wants, so its encryption deserves the same scrutiny as your TLS. And every pipeline that copies customer data into analytics stores or training sets extends that data’s shelf life by however long the copies live, one more reason to know where your data actually flows (an AI data bill of materials is how we’d start). A useful filter: if a breach of this data in 2035 would still hurt, treat it as a target in 2026.

If you carry a SOC 2, this is also where the work becomes visible to buyers. The Confidentiality criterion asks how information designated confidential is protected in transit and at rest and how keys are managed; documenting a post-quantum roadmap there turns a future questionnaire into a paragraph you already wrote.

What are the NIST post-quantum cryptography standards?

The replacement algorithms exist and are standardized. On August 13, 2024, NIST finalized its first three post-quantum standards: FIPS 203, ML-KEM (formerly CRYSTALS-Kyber), “intended as the primary standard for general encryption,” which in practice means key exchange; FIPS 204, ML-DSA (formerly CRYSTALS-Dilithium), the primary standard for digital signatures; and FIPS 205, SLH-DSA (formerly SPHINCS+), a hash-based signature scheme “intended as a backup method in case ML-DSA proves vulnerable.” A fourth, FN-DSA based on FALCON, is planned as FIPS 206. NIST’s instruction to administrators was not subtle: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”

For anything touching national security systems, the NSA’s CNSA 2.0 suite picks the strongest parameter sets: ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, LMS and XMSS for firmware signing, with AES-256 and SHA-384 or SHA-512 carried over. The FAQ adds a date anyone selling into that market should circle: from January 1, 2027, “all new acquisitions for NSS will be required to be CNSA 2.0 compliant.” If that’s your market, our post on building a defense tech startup covers what else the buyer will ask.

Why “post-quantum” is not automatically “quantum safe”

Kane’s warning on the episode is the one most vendors will skip: swapping in a new algorithm is not the same as being secure.

“Using post-quantum encryption does not make the product quantum safe. You have to follow additional instructions to do the cryptographic construction correctly.”

Kevin Kane, American Binary, episode 96

His company spent years on the unglamorous part, making a new key exchange work in the real world, with private peer review and formal verification (the founder side of that story, why deep tech can’t be built in a weekend and why formal verification is a moat, is in our companion post from the same episode, What Is Deep Tech?). His hard-won lesson is why this can’t be a last-minute scramble: “There’s such a long road on learning what’s going wrong with software that is new, doesn’t exist in the wild, except for what you built.” New cryptography fails in ways no one has documented yet; the teams that start early find those failures on their own schedule.

The second point is about trust, and it’s the one founders should tape to the wall. A product can be technically fine after a break and commercially dead the same afternoon:

“Tell that to your customers who decide to stop using the product tomorrow because a bunch of crypto bros are freaking out on Twitter and X saying someone solved for the discrete log problem and broke this email thing. I don’t think anyone’s gonna wait for a cryptographer to say, actually, AES-256 is still secure inside. I think they’re gonna leave, or even worse, a bank.”

Kevin Kane, American Binary, episode 96

Read that as an opportunity. Your enterprise buyers will need a post-quantum answer from every vendor in their supply chain, and most vendors won’t have one for years. A startup that can hand procurement a cryptographic inventory and a hybrid-by-default architecture is offering what a SOC 2 offers: proof you were paying attention before anyone asked.

How to start a post-quantum migration: four steps

Those deadlines are the runway, not the finish line. A practical migration starts well before them, and the first three steps require no new cryptography at all.

1. Inventory your cryptography. Every TLS endpoint, VPN, SSH bastion, code-signing path and service-to-service credential, plus the encrypted archives and backups holding long-lived data. Most teams badly underestimate this surface (NSM-10 gave federal agencies a full year for the same exercise). Certificates and libraries are searchable; the hard part is the mobile app that pinned an RSA key in 2022 and the vendor appliance nobody logs into.
2. Rank by data shelf life. Migrate long-secrecy data first: a marketing site can wait, a health-records pipeline cannot. The chart above plus your own data classification is the whole ranking exercise.
3. Build crypto agility. Architect so algorithms can be swapped like rotating a certificate rather than replatforming: cryptography behind one interface, algorithm choice in configuration, key sizes and protocol versions never hard-coded into data formats or client apps. This step pays back even if Q-Day slips a decade, because the next algorithm break may not be quantum at all.
4. Start hybrid. Pair a classical algorithm with a post-quantum one so a break in either doesn’t expose the session. The standard TLS hybrid, X25519MLKEM768 (X25519 plus ML-KEM-768), is already on by default in recent versions of all major browsers, OpenSSL, Go and recent Apple operating systems, according to Cloudflare’s October 2025 state of the post-quantum internet, which reported over half of human-initiated traffic to Cloudflare already post-quantum protected. If your edge supports it, turning it on is a configuration change. Post-quantum signatures and certificates are the slower half of the migration and can follow.

Where a security partner earns its keep: an engineering-led product security engagement is how we run steps one and three with teams (the inventory, the abstraction layer, the design review of anything homegrown), and a penetration test is where the 2022 mobile app with the pinned RSA key tends to turn up. Neither requires you to hire a cryptographer.

What to decide this quarter

You don’t need to predict Q-Day. You need three answers: which of your data would still hurt if it were read in 2035, how long your migration would take, and whether hybrid key exchange is on or off at your edge today. The first two are your version of Mosca’s inequality. The third is usually a one-line change with an outsized payoff.

Kane’s line on timing is the one to remember: the time to start was not here two years ago, it is starting to be here now, and in a few years it will “super be here.” The proven algorithms are ready. The scarce resource is the time to deploy them well, and every team that starts now gets more of it.

If you want a second set of hands on the inventory and the crypto-agility work, our product security team, engineers with security backgrounds at Apple, Uber, Microsoft, Robinhood and Brex, will scope it in one call. And if you’d rather hear the argument in Kevin’s own voice first, episode 96 is 26 minutes well spent.