Harvest Now, Decrypt Later: Why Quantum Is Today's Problem

Somewhere, right now, someone may be recording your encrypted traffic. They cannot read it. The TLS session is sound, the keys are strong, and no computer on Earth can break them in any useful amount of time. So they do the only thing that makes sense: they store it, and wait.

That is the whole idea behind harvest now, decrypt later. It is the reason governments, browser vendors and messaging apps are rebuilding their cryptography years before anyone has a quantum computer capable of breaking it. The attack does not need that machine to exist today. It only needs it to exist before your secrets stop mattering.

This post explains what the threat actually is, why the timeline keeps moving closer, and a simple way to tell whether your own data is already exposed.

The attack that needs no quantum computer (yet)

Most attacks have to succeed in the moment. A password has to be guessed while it is still valid, a session hijacked while it is still open. Harvest now, decrypt later flips that. The collection step is cheap and happens today: copy the ciphertext off a network link, a compromised router, a leaked backup, a subpoenaed data center. The expensive step, the decryption, is postponed until the tools to do it exist.

Storage is cheap and patient adversaries are real. Anyone who can afford to tap a fiber route can afford to keep what they collect for a decade. And unlike a stolen password, recorded ciphertext never expires. If the key exchange that protected it can one day be broken, every message that relied on it is opened at once, retroactively.

What a quantum computer actually breaks

Not all cryptography is equally at risk, and the distinction matters.

• Public-key cryptography is broken. RSA, Diffie-Hellman and elliptic curve cryptography (ECC) rest on math problems, factoring large numbers and computing discrete logarithms, that a large enough quantum computer running Shor's algorithm solves efficiently. These are the algorithms that let two strangers agree on a secret key over the internet, and that sign certificates, software updates and transactions.
• Symmetric cryptography is only weakened. Ciphers like AES and hash functions like SHA-256 face Grover's algorithm, which gives a quantum computer a speedup against them but not a knockout. Longer keys restore the margin, which is why AES-256 is the comfortable choice for data that has to stay secret for a long time.

Here is why that split is so dangerous for recorded traffic. A typical HTTPS connection uses public-key cryptography for one short moment, to agree on a session key, and then encrypts everything with a fast symmetric cipher. The symmetric part would survive a quantum computer. The handshake would not. Break the handshake in the recording, recover the session key, and the "safe" symmetric layer falls with it.

The estimate keeps shrinking

How big a quantum computer does this take? The answer has moved a lot, and always in the same direction.

• In 2019, the best published estimate for factoring a 2048-bit RSA key was about 20 million physical qubits running for roughly eight hours.
• In May 2025, Google researcher Craig Gidney cut that to fewer than one million noisy qubits, running for less than a week.
• In March 2026, Google Quantum AI published estimates for the 256-bit elliptic curve that secures Bitcoin and Ethereum (curves of the same size protect most modern TLS handshakes): around 1,200 logical qubits, fewer than 500,000 physical qubits, and a runtime measured in minutes.

A note on those two kinds of qubit. Physical qubits are the fragile hardware components, which make errors constantly. Logical qubits are what you get after bundling many physical qubits together with error correction so they behave reliably. Useful attacks need logical qubits, and every logical qubit costs hundreds of physical ones. The recent drops did not come from bigger machines. They came from smarter algorithms and cheaper error correction, which shrink the machine an attack would need.

To be clear, no machine anywhere near these sizes exists today, and building one remains a formidable engineering problem. Credible forecasts for a "cryptographically relevant" quantum computer range from around 2030 to the 2040s. But the target has shrunk by more than an order of magnitude in about six years, and that trend is the part worth paying attention to.

Are you already too late? Mosca's inequality

The most useful tool here is not a physics result but a line of arithmetic, proposed by the Canadian cryptographer Michele Mosca. Answer three questions:

• X: how many years must your data stay secret?
• Y: how many years will it take you to migrate your systems to quantum-safe cryptography?
• Z: how many years until a quantum computer can break today's public-key cryptography?

If X + Y > Z, you have a problem, and the problem already started. Data you send today under old cryptography will still be sensitive on the day it becomes readable.

Try it with a medical record. It should stay private for the patient's lifetime, so call X twenty years. Migrating a real system, with its vendors, devices and old integrations, easily takes five years, so Y is five. Even if you take a relaxed view of Z and assume fifteen years, twenty plus five is well past fifteen. In fact twenty alone already is. By this logic, health data sent today under classical key exchange is already exposed to anyone patient enough to keep a copy.

Now try it with a one-time login code that expires in five minutes. X is effectively zero, and the inequality never trips. That is the real lesson: the risk is set by how long a secret has to stay a secret, not by how sensitive it feels today.

What is already being done

The good news is that the fix for harvest now, decrypt later is already rolling out, mostly without anyone noticing.

The first priority everywhere has been key exchange, the step recorded traffic depends on. NIST standardized ML-KEM (FIPS 203) in 2024 as a quantum-resistant way to agree on a key, and the industry quickly paired it with the classical X25519 exchange in a hybrid scheme called X25519MLKEM768. Hybrid means an attacker has to break both halves: if ML-KEM ever turns out to have a flaw, the classical part still holds against today's attackers, and if a quantum computer arrives, the ML-KEM part still holds.

According to Cloudflare, Chrome turned hybrid post-quantum key exchange on by default on desktop in March 2024, Chrome on Android and Firefox followed in November 2024, and Apple's iOS, iPadOS and macOS 26 joined in October 2025. By late 2025, more than half of the human traffic Cloudflare sees was already protected by post-quantum key exchange. Messaging went the same way: Apple's iMessage PQ3 and Signal's post-quantum ratchet both mix a post-quantum key into every conversation.

Signatures, the other half of public-key cryptography, are moving more slowly, and that is a deliberate choice, not neglect. A signature only has to hold up at the moment someone checks it. To forge a certificate, an attacker needs a working quantum computer at the time of the attack; a recording made today does not help them. Confidentiality has a retroactive threat, authentication mostly does not. So the industry fixed the urgent half first and is taking its time with the harder one, where post-quantum signatures are much larger and a single TLS handshake carries several of them.

Regulators are setting dates around the same logic. NIST's draft transition plan deprecates the weakest of today's RSA and elliptic curve parameters after 2030 and disallows all of them after 2035. The EU's coordinated roadmap asks member states to start their transition by the end of 2026, protect high-risk systems by 2030 and most others by 2035. And on September 3, 2026, CISA and the G7 Cyber Security Working Group published a joint call to action urging organizations to begin now.

What this means for the rest of us

You do not need a quantum physicist to act on any of this. The practical steps follow straight from the inequality.

• Sort your data by shelf life. Session tokens and one-time codes can wait. Health, financial, legal and identity data, anything with a long X, is where the exposure lives.
• Find where public-key cryptography protects that data. TLS to your users, connections between your own services, VPN tunnels, encrypted backups, vendor APIs. You cannot migrate what you have not listed.
• Take the free upgrades. Much of the protection comes from keeping TLS libraries, operating systems, CDNs and load balancers current, since hybrid key exchange is increasingly the default. Check that the whole path to your servers supports it, not only the part facing the browser.
• Plan for change, not for one algorithm. The standards are young and more are coming. Systems that can swap cryptographic algorithms through configuration will age far better than systems where the choice is buried in code.
• Collect and send less. The only data that is perfectly safe from a future quantum computer is data that never crossed a network in the first place.

That last point is a design principle we care about at FirstPoint. Pulsefy, our camera-based heart-rate app, runs its measurement entirely on the phone. There is no heart-rate data in transit to record, so there is nothing to harvest, now or later.

The clock started already

Harvest now, decrypt later is unusual among security threats because its damage is decided long before it happens. The recording is made today; only the reading is postponed. That makes it easy to dismiss, since nothing visible goes wrong, and it makes waiting expensive, because every year of delay adds another year of traffic to someone's archive.

The encouraging part is how far the fix has already traveled. If you are reading this in an up-to-date browser, the connection that delivered this page most likely already used hybrid post-quantum key exchange: we checked, and this blog negotiates X25519MLKEM768. The job now is to make sure the rest of the path, and the data that matters most, catches up.

If you enjoy this kind of plain-language engineering writing, subscribe below. We publish notes like this alongside updates on what we are building at FirstPoint.