Safe today. What about tomorrow?

Say "quantum computer" and the same scene comes to mind: one morning we wake up, someone has switched the machine on, every cipher is broken, the world has ended. That scene is wrong. But do not let it comfort you, because the scenario that is real is sneakier.

Almost all of the encryption we use today rests on the difficulty of factoring large numbers. On a classical computer that takes millions of years. In 1994 Peter Shor showed that a quantum computer could do it in a reasonable time. So we have known for thirty years that encryption will one day be broken. The only thing we do not know is the date.

The threat is not the day the machine runs

This is where the real issue begins. The threat has a name: "harvest now, decrypt later".

States and serious actors are recording today's encrypted traffic. The ciphers cannot be broken today; they store it anyway. When quantum matures enough, those archives will spill open. Every document we hide behind encryption we believe unbreakable may already be sitting on someone's disk.

So the question to ask is this: how many years does your data need to stay secret?

If it is an e-commerce basket, the answer is "a few days" and there is no problem. If it is a personnel file, a patient record, a ten-year supply contract, the answer changes. Every piece of data with a long confidentiality lifetime sits inside a risk taken today.

So how much time do we have?

IBM, for example, puts fault-tolerant quantum at 2029. That is the company's own optimistic target, and in this field we have seen plenty of timelines slip.

So: not tomorrow. But "not tomorrow" and "does not concern us" are not the same thing. Changing an organisation's encryption infrastructure takes years: taking inventory, pushing suppliers, replacing legacy systems. This is not work you start when quantum arrives.

Whose calendar do we think it is?

In giving those dates I quietly made an assumption: that we know where quantum stands. In fact the only thing we know is where those who publish their quantum work stand.

IBM announces how many qubits its processor carries, publishes its roadmap, and when it misses a target we see that too. Google does the same. These companies are publicly traded, they publish papers, they file patents. We know their calendar.

And those whom it does not suit to tell? Expecting a military or intelligence programme to be that transparent would be naive. Whatever the state, hiding progress is natural. A code-breaking capability reaches its maximum value only as long as it stays secret. The last thing a state would do on crossing that threshold is announce it.

This is not a conspiracy theory; it follows from the nature of the capability. And the consequence is this: we plan according to the roadmap of the open actors, while the programme that matters may be the invisible one. We cannot know how large the gap is.

So dates like 2029 or 2033 should be read not as a guarantee but as an optimistic estimate. Take that into account when you calculate the confidentiality lifetime of your data.

Start now

One. Take inventory. Determine which system uses which encryption.

Two. Separate your data by confidentiality lifetime and value.

Three. Make quantum-resistant encryption support a requirement in the specification for new purchases. The security envelope of the system you buy today matters enormously.

Four. Assess your surroundings. Your suppliers' security is your security.

Two kinds of mistake

The first is panic: quantum is not arriving tomorrow, encryption is not collapsing tonight. The second, and the more common, is indifference, saying "we are a small company, who would bother recording us". Whoever is recording the data is not looking at who you are; they are looking at the traffic.

A risk known for thirty years is coming due. The work to be done is boring, it is not expensive, and it can be spread over time. It only has to be started.