When we talk to people about post-quantum cryptography, the responses range from “never heard of it” to “we’ve already implemented it.” In our experience, it’s usually the former. At Navara we recently went through our customers’ applications to see where they stood, and most of them weren’t quantum-safe yet. When we raised it with management, the reactions varied. Most landed in the same place: interesting, perhaps, but not something we need to worry about yet.

It’s a reasonable place to land. It’s also the wrong conclusion. The work to become quantum-safe has to begin long before the threat becomes visible. By the time it’s obviously real, the chance to deal with it calmly has passed.

To be clear, post-quantum cryptography is simply the encryption already running on your systems, redesigned so that a future quantum computer can’t break it. The quantum part is the threat you’re defending against, not a technology you have to run yourself.

What’s easy to underestimate is how much of an organisation depends on encryption. It protects databases, HTTPS traffic, email, payments, remote access, software updates and the mechanisms that allow systems to trust one another. Much of it was implemented years ago and hasn’t been reviewed since.

That reach is what makes the problem difficult. Before anything can be replaced, organisations first need to understand where cryptography is used and how it is connected across their systems. That’s not something that can be done overnight.

The threat is already live

Encryption has always rested on the following assumption: it doesn’t much matter if someone captures your data in transit because they can’t read it. Intercepting an encrypted message gets you nothing but noise. A quantum computer challenges that assumption.

The machine capable of doing so does not exist yet. But an attacker does not need it today to benefit from it tomorrow. Valuable encrypted data can already be copied and stored. Once a sufficiently powerful quantum computer becomes available, that data can be decrypted. This is known as “harvest now, decrypt later”. The risk is therefore determined by when data can first be captured, not by when a quantum computer eventually arrives.

Which of your data is actually at risk?

Not all data is at risk. Two factors determine whether data is exposed: whether it can be captured, and whether it will still matter when it is.

The first is about where the data goes. The risk primarily applies to data that leaves your systems. That includes data crossing the public internet or stored with a third-party provider, where it can be collected without your knowledge. Data that never leaves a controlled environment is much harder to harvest.

The second is about time. Data with a short shelf life is rarely the concern. Think of this week’s logistics or a price that becomes public next quarter. The real concern is data that could still cause damage if it became public years from now. A practical rule of thumb is simple: if you’d still wince at something being exposed in 2035, treat it as at risk today.

So why not simply wait?

If only a subset of your data is vulnerable, and only data that remains sensitive for years, waiting can seem like the sensible option. You monitor developments and act once a cryptographically relevant quantum computer is clearly on the horizon. The flaw in that approach is not the threat itself. It is the amount of work required to get from recognising the risk to actually being protected.

Encryption is so widespread, and much of it was never documented. The first task is therefore not replacing algorithms, but finding where cryptography is used. That means mapping your own software, your suppliers and the systems in between. Creating that inventory, often called a cryptographic bill of materials (CBOM), is a substantial project in its own right. And it comes before the actual migration begins. Based on previous transitions of similar scale, Dutch government guidance estimates the effort at well over five years [1].

Now combine that with the lifespan of your data. If your data has to stay confidential into the 2030s, and the work to protect it takes the better part of a decade, this is already problematic. The migration has to be completed before that confidentiality expires. That clock may already have started when the data was captured, not at project kickoff.

In theory, you could work backwards from the arrival of a cryptographically relevant quantum computer. In practice, that is difficult. No one can reliably predict when such a machine will arrive, and most serious estimates have moved the date closer rather than further away. Planning around a prediction is therefore not a realistic option. What’s left is to start now and treat the arrival as something that could come early.

Why now?

None of the reasoning so far depends on recent events. The underlying calculation has been the same for years: some data remains sensitive for a long time, while migrating away from vulnerable cryptography takes time. What has changed is more practical. Organisations can now begin the transition, and increasingly they are expected to.

The discussion used to live in research papers and standards committees. Over the past two years, it has moved from research into practice. The replacement cryptographic standards that organisations will eventually migrate to were finalised in 2024 [2]. And across 2024 and 2025, governments stopped treating this as a long-term concern and began putting dates on it: the EU published a coordinated transition timeline, and standards bodies set deadlines aimed at 2030 and 2035 [3, 4]. The point isn’t the specific years. The point is that organisations can now begin with confidence, and the expectation to do so is becoming real.

What this means

None of this calls for panic. It’s a call to begin. The threat itself is still years away. The decision to start while there’s still time to act calmly is not.

What you’re starting is not a one-time migration to today’s approved algorithms. Those algorithms will eventually be replaced as well. The goal is to build the ability to change them without repeating the entire exercise.

This is known as cryptographic agility. It’s the same engineering principle that stops you hard-coding a value you already know will change.

Waiting for the threat to become visible doesn’t make the work any smaller. It only means doing the same work later, with less time and less control over how it’s done.

References