Your instinct will be to reach for the counter-arguments: TLS 1.3, perfect forward secrecy, AES-256 at rest. They are protections, but they sit on the wrong side of the problem: the weak point is the handshake. Long-lived archives and backups, encrypted under RSA or ECDH key wrapping and kept for compliance, are the least-modelled assets. By the end you’ll be able to explain why “already exposed” is literal, and defend which systems to migrate first using Mosca’s inequality as the ordering tool — the ordering step inside a wider post-quantum readiness programme.
Why does harvest now, decrypt later go after the TLS handshake?
Harvest now, decrypt later targets the TLS handshake because that is the one place public-key cryptography is load-bearing in a connection. The handshake’s ephemeral Diffie-Hellman exchange establishes the session keys, and a future quantum computer can solve that exchange retrospectively and decrypt the recorded traffic. AES-256 is never the weak point.
Strip away the terminology and HNDL is simple. An adversary records encrypted traffic at scale today and stores it indefinitely, then applies Shor’s algorithm to the asymmetric schemes that protected the keys. It goes by a few names, “store now, decrypt later” and “catch now, break later”, but the mechanics don’t change. Nothing needs to be broken now, which is why it feels abstract until you see where the session keys come from.
In TLS 1.3, client and server agree a shared secret using ephemeral Diffie-Hellman (ECDHE). That secret derives the symmetric session keys, which protect the bulk of the traffic with AES. That part is sound: Shor’s algorithm breaks factoring and discrete logarithms; it leaves symmetric ciphers intact. The vulnerable point is the exchange itself, where RSA and ECDH public-key cryptography sits. A future cryptographically relevant quantum computer (CRQC) can recover the secret from the recorded exchange, reconstruct the session keys, and read the captured traffic.
Which brings us to the objection you’re probably raising: doesn’t perfect forward secrecy already solve this? PFS uses an ephemeral key discarded after each session, so a later compromise of the server’s long-term private key cannot decrypt past sessions. But the ephemeral ECDHE exchange is itself built on discrete-logarithm maths a quantum computer can break. A quantum adversary can still solve the recorded exchange and read the session.
The corollary follows: anything with a long confidentiality requirement and a recorded ciphertext is already inside the exposure window, regardless of what later happens to the server or its keys. Hybrid key exchange (X25519MLKEM768) stops new traffic joining the archive. Traffic already captured is unaffected.
Is our data already exposed, and which systems should we migrate first?
Most archived data is already inside the exposure window. Order the migration by shelf life, and use Mosca’s inequality to do it: long-lived archives and health records go first.
Mosca’s inequality produces an ordering. Written X + Y > Z (sometimes X + Y > Q), X is data shelf life, Y is migration time, and Z is the time until a quantum computer can realistically break today’s public-key cryptography. Work one frame: ten years of confidentiality plus five years of migration is only comfortable if a CRQC is more than fifteen years away. That is a bet. Expert surveys put the probability of a CRQC within a decade at roughly a third to a half.
The Z side is uncertain. The X side, how long your data must stay secret, is set for you. Australian retention rules push X past any plausible Y. The Archives Act 1983 keeps most Commonwealth records for decades, with census data held for 99 years. My Health Record retention runs for 30 years after death, or 130 years from birth where death is unknown. Under the Privacy Act 1988, APP 11 obligations persist for as long as personal information is held, including copies in archives and backups. When your shelf life is measured in decades, migration time is the only variable your business controls — and the one the regulatory clock is now compressing.
So the order follows shelf life. Health records, identity documents, financial histories, source code and trade secrets, and long-lived backups go first; session-scoped data like short-lived credentials goes later. Ordering by criticality optimises for availability. A low-visibility archive of ten-year records outranks a customer-facing service whose credentials expire in minutes.
Backups and archives deserve the warning label here: re-encryption takes time and touches data your team avoids, which is why it belongs early. The fix for data at rest is usually re-wrapping keys via ML-KEM in your KMS or HSMs rather than bulk re-encryption, since the AES-256 data itself is fine. But re-wrapping consumes the migration window; it does not extend it. Mapping each system to the data it protects is its own job, and that inventory belongs to the next article.
The compromise is the day of capture. The recording exists, the handshake is the one load-bearing point a future quantum computer can reach backwards through, and “already exposed” stops being a scare phrase once you treat it as an inventory problem. Mosca’s inequality turns “will it happen?” into “which systems first?”, and the answer follows shelf life. Long-lived archives go early, and the cryptographic inventory is the next step in the wider migration programme. You leave with a defensible position: why now, and why these systems first.
Frequently Asked Questions
Is RSA already broken, or is harvest now, decrypt later a future problem?
RSA is not broken today, and no classical computer can factor a properly sized key. The problem is timing rather than mathematics: the recording is already happening, so the question is not whether RSA falls but whether your data still needs to be secret when it does. Until a cryptographically relevant quantum computer exists, the maths holds and the exposure quietly grows.
What exactly is a cryptographically relevant quantum computer?
A cryptographically relevant quantum computer (CRQC) is one with enough stable, error-corrected qubits to run Shor’s algorithm against real key sizes. Today’s machines are small and noisy: useful for research, nowhere near breaking a 2048-bit RSA key. The gap is engineering rather than theory, which is why Z in Mosca’s inequality is uncertain but not infinite, and why published estimates keep moving in both directions.
How would we know when Q-Day has arrived, and does the date really matter?
There is no announcement and no reliable early warning, which is exactly why the date is the weakest input in the model. Z in Mosca’s inequality is a range, not a fixed point, and estimates move as error-correction milestones land. What you control is X and Y. Shorten how long data must stay secret and shorten migration time, and the uncertainty matters less.
How much encrypted traffic can an adversary realistically store?
More than most people assume. Storage is cheap and capture can be automated, so an adversary can hold years of a target’s traffic for the cost of a few hard drives. They do not need everything either, because a filtered capture of login tokens, API calls and database backups is enough. Dragnet collection exists, but targeted capture is the realistic threat for a mid-sized company.
Does this only affect TLS, or do VPNs, SSH and email have the same problem?
Any protocol that establishes keys with RSA or elliptic-curve Diffie-Hellman is exposed, not just HTTPS. IPsec and IKE, SSH, S/MIME and PGP, and TLS-protected APIs all perform the same kind of public-key exchange, so recorded sessions carry the same retrospective risk. The fix is protocol by protocol: wherever you can enable hybrid or post-quantum key establishment, do, starting with the data that has the longest shelf life.
If we migrate to post-quantum cryptography next year, does that protect the data already captured?
No, and this is the part most migration plans get wrong. Hybrid key exchange protects new handshakes from the day it is deployed; it does nothing for ciphertext an adversary already holds. The archive is a separate problem with its own fix, which is why re-wrapping stored keys and retiring what you no longer need belong early in the programme, not at the end.
Is harvest now, decrypt later a realistic threat for a 50-person SaaS company?
Yes, because target selection follows data value, not headcount. A fifty-person healthtech or fintech holds records that stay sensitive for decades, and its customers may include larger organisations whose data you process. Smaller firms also tend to have less visibility into their own traffic, which makes a passive capture easier to miss. The threat is not hypothetical for you, just quieter.
What should we do first if we don’t have a cryptographic inventory?
Start with the data, not the code. List what you hold, how long it must stay confidential, and where it is encrypted, then trace back to the keys and the systems that manage them. That gives you an asset list you can order by shelf life. A cryptographic inventory is the formal version of this exercise, and it is usually the first wave of a migration.
Will post-quantum key exchange slow down our connections or break compatibility?
Not meaningfully. ML-KEM is fast and the handshake cost is small next to the bulk encryption of real traffic, though hybrid groups do add roughly a kilobyte to each handshake. Compatibility is the bigger issue: older clients, appliances and embedded devices may not negotiate the new groups, so pilot on one public endpoint and test the long tail before you enforce them.
Are digital signatures and code signing affected in the same way?
Not in the same way, because the risk is different. Harvest now, decrypt later is about confidentiality: a CRQC recovers keys and reads recorded traffic. Signatures are about authenticity: a CRQC could forge them, and old signatures may be repudiated even though nothing was ever secret. Treat signatures as a separate track, migrated to ML-DSA on its own priorities.
