Harvest now, decrypt later: why long-lived products need post-quantum planning today

The most common question I hear about post-quantum cryptography is: “When will quantum computers actually break RSA?”

It’s a reasonable question. It’s also the wrong place to start.

For many organisations, the risk doesn’t begin on the day a sufficiently powerful quantum computer exists. It begins on the day someone records data that will still be valuable when that computer arrives.

What “harvest now, decrypt later” means

The idea is simple. An attacker intercepts and stores encrypted traffic today. They can’t read it yet. They don’t need to. Storage is cheap, and they can wait.

When a cryptographically relevant quantum computer becomes available, the key exchanges protected by today’s public-key algorithms, such as RSA and elliptic-curve cryptography, could be broken. Shor’s algorithm showed in 1994 that this is possible in principle. The data recorded years earlier becomes readable.

Whether that happens in ten years or twenty is uncertain. What matters is a much simpler comparison.

The three numbers that decide your risk

There’s a well-known way to frame this, often attributed to Michele Mosca. You compare three durations:

• how long your data must stay confidential (x);
• how long it will take you to migrate your systems to quantum-safe cryptography (y);
• how long until a quantum computer can break today’s public-key cryptography (z).

If x + y is greater than z, you have a problem, and you have it today.

The useful part of this formula is that you don’t need to know z precisely. You only need to be honest about x and y. And in my experience, y is the number people underestimate most.

Why connected products are different

For a web service, migration is hard but bounded. You control the servers, you can deploy new libraries, you can rotate certificates.

Connected products are different.

• They stay in the field for ten, fifteen, sometimes twenty years.
• Their cryptography is often tied to hardware, bootloaders and secure elements chosen years earlier.
• Their update chain may involve several suppliers.
• Some of them can’t be updated at all.

So for a device designed today, x and y overlap with z almost by definition. The product you are specifying now will very likely still be running when the transition is well under way.

It’s not only about confidentiality

“Harvest now, decrypt later” is about confidentiality. For connected products, there is a second risk that I find even more important: authenticity.

Firmware updates are signed. Devices prove their identity with certificates. If the signature schemes behind those mechanisms become breakable, an attacker doesn’t need to read your data. They can impersonate you: sign malicious firmware, or clone a trusted device.

That risk doesn’t start when data is harvested. It starts when the attack becomes practical. But the root of trust that has to resist it is decided much earlier, when the hardware and the boot chain are designed.

The timeline is already set

You don’t have to bet on quantum hardware to have deadlines.

• NIST published its first post-quantum standards, FIPS 203, 204 and 205, in August 2024.
• NIST has set out its plan to deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them after 2035.
• The European Union’s coordinated roadmap asks for the transition to start by the end of 2026, for high-risk use cases to be protected by 2030, and for as many systems as feasible to be migrated by 2035.

Regulators and large customers will follow those dates regardless of what happens in quantum labs.

What to do now

You don’t need to replace every algorithm this year. You need to stop making the problem bigger.

1. Classify your data by lifetime. What must remain confidential for more than ten years? That traffic deserves attention first.
2. Find where public-key cryptography is used. Key exchange, signatures, device identity, update signing. You can’t plan a migration you can’t see.
3. Don’t ship new products that can’t change. Make sure new designs have the memory, the performance margin and the update path to adopt new algorithms. I call this crypto-agility.
4. Estimate y honestly. Ask your teams how long it would take to change the signing scheme of your oldest supported product. The answer is usually longer than the roadmap assumes.

The quantum computer is not the starting point. The starting point is the data, and the products, you are creating today.