Harvest now, decrypt later

A common reaction to the last few lessons is: "Fine, but nobody has a code-breaking quantum computer yet. We'll deal with it when they do." This lesson explains why that plan fails for some data today, and how to tell whether yours is part of it.

The threat in one sentence

Harvest now, decrypt later (also called "store now, decrypt later") means recording encrypted traffic today and decrypting it once a cryptographically relevant quantum computer (CRQC) exists.

Recording traffic is easy and storage is cheap. An adversary doesn't need to break anything today. They need only to keep the recordings until the tools catch up.

Why the recordings would become readable

Recall the split from the first lesson. A secure connection uses public-key key exchange (such as ECDH or RSA) to agree on a symmetric key, then encrypts the data with AES under that key. The AES part would survive a quantum computer. But the key exchange is in the recording, and Shor's algorithm could recover the shared key from it. With the key in hand, the AES layer simply unlocks.

So the security of a conversation you have today depends on what an adversary can do with its recording years from now.

Mosca's inequality: are you already late?

Michele Mosca, a quantum computing researcher, framed the question with three numbers:

• X: how many years your data must stay secret (its "shelf life").
• Y: how many years it will take you to migrate to quantum-resistant cryptography.
• Z: how many years until a CRQC exists.

If X + Y > Z, you have a problem. Data you encrypt the old way during your migration will still need protecting after a CRQC arrives. If that data is being harvested, it will be exposed while it still matters. That relationship is known as Mosca's inequality.

The uncomfortable part is that you control X and Y only partly, and Z not at all. Try it:

Two things stand out when you play with it. First, long-lived data (health records, state secrets, intellectual property) is "late" across a wide range of guesses for Z. Second, Y is the lever you actually control. Starting the migration earlier and running it faster is the only reliable way to shrink the left-hand side.

What is Z? Nobody knows

Any honest discussion of the quantum timeline starts with uncertainty. Here's what the published estimates say, attributed to the people who made them:

• In a 2015 note, Mosca estimated a one-in-two chance of breaking RSA-2048 by 2031.
• The Global Risk Institute's Quantum Threat Timeline Report 2024 surveyed 32 experts about a CRQC defined as a machine able to break RSA-2048 within 24 hours. Averaging their answers gave roughly a 19% to 34% likelihood of one within ten years, depending on how optimistically the ranges were read.
• Resource estimates have dropped: from about 20 million noisy qubits running about 8 hours (Gidney and Ekerå, 2019) to fewer than one million running under a week (Gidney, May 2025) for factoring RSA-2048.

None of these is a forecast you can schedule around. They're probabilities and engineering estimates, and reasonable experts disagree. But for risk management, "a meaningful chance within a decade" is already decisive when X + Y is also around a decade.

Encryption and signatures have different clocks

Harvest now, decrypt later is a threat to confidentiality: secrets recorded today. Signatures face a different kind of risk.

A quantum attacker can't go back in time and forge a signature on a transaction that was already verified and acted on. Forging becomes possible only once a CRQC exists. So for short-lived signatures, such as a TLS handshake, the deadline is "before a CRQC arrives," not "now."

But some signed things live for a very long time:

• Firmware and roots of trust. A device that ships in 2027 with a classical signature key burned into its boot process may still be running in 2040. If a CRQC arrives first, attackers could sign malicious updates the device accepts as genuine.
• Long-term documents and certificate hierarchies, whose trust anchors take years to replace.

These need lead time for the same reason encrypted secrets do: the migration has to finish before the threat arrives, and hardware lifecycles are long. That's why the US NSA's CNSA 2.0 guidance puts software and firmware signing first: support and prefer quantum-resistant algorithms by 2025, and use them exclusively by 2030.

The official deadlines

Governments have translated this logic into dates. The details belong to the deadlines lesson in the practitioner track, but the headline is consistent: start now, finish around 2035.

Notice that these plans assume migration takes years. Mosca's Y isn't a weekend project.

The good news: the fix exists and is shipping

This isn't a story with no ending. NIST published its first post-quantum standards on 13 August 2024: ML-KEM (FIPS 203) for key exchange, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. And the key-exchange half, the part harvest-now-decrypt-later targets, is already being deployed at scale:

• Signal introduced its post-quantum PQXDH protocol in September 2023.
• Apple announced the PQ3 protocol for iMessage in February 2024.
• Chrome enabled a hybrid post-quantum key exchange by default in Chrome 124 (April 2024), and switched to X25519MLKEM768 in Chrome 131 (November 2024).
• OpenSSH 10.0 (April 2025) made the hybrid mlkem768x25519-sha256 key exchange its default.

"Hybrid" means combining a classical algorithm with a post-quantum one, so the connection stays secure as long as either holds. The hybrid TLS lesson covers how it works. If you're reading this page in an up-to-date browser, there's a good chance this very connection used one.

What to do first

For an organization, the first steps aren't exotic:

1. Find your long-X data. Which data must stay secret for ten years or more? Where does it travel and get stored? That's where harvest-now-decrypt-later bites first.
2. Inventory your cryptography. You can't migrate what you can't find. See cryptographic inventory.
3. Prioritize key exchange for long-lived secrets. Turning on hybrid post-quantum key exchange (in TLS, VPNs and SSH) protects traffic from harvesting, often with a configuration change or an upgrade.
4. Plan long-lived signatures early. Firmware, devices and roots of trust need the most lead time.
5. Build for change. Systems that can swap algorithms by configuration migrate faster and survive the next surprise too. See crypto-agility.
6. Ask your vendors. Much of your Y lives in other people's products. Ask for their post-quantum roadmap now.

Track summary

You now have the whole foundation. Cryptography does three jobs with a small toolkit. Public-key cryptography, the part that lets strangers connect, rests on factoring and discrete logarithms. Quantum computers use interference, not magic, and Shor's algorithm turns those two problems into easy period-finding. Grover's algorithm only dents symmetric encryption. And because recorded traffic can be decrypted later, the deadline for some data has effectively already started.

The practitioner track picks up from here: the new standards, how hybrid TLS works, the deadlines in detail, and how to run a migration.

Questions

Get five of six right to mark the lesson complete. They also feed the final exam.

Sources

• Mosca (2015), Cybersecurity in an era with quantum computers: will we be ready? (IACR ePrint 2015/1075)
• Global Risk Institute, Quantum Threat Timeline Report 2024 (executive summary)
• NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards
• UK NCSC: Timelines for migration to post-quantum cryptography
• NSA, Announcing the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)

Drawn byKyeson Blake Utley

CourseQuantum Defense

Sheet6 of 18

PartI · Foundations

Rev.18 Oct 2026

Sources6 cited

Found an error?Send a correction