The Cryptographic Horizon

Most discussion of post-quantum cryptography concerns timing: when a cryptographically relevant quantum computer will exist, whether current estimates are optimistic, and how much of the disagreement is technical rather than commercial.

It is an interesting question and largely the wrong one to organise around. The decision an organisation faces is not when the machine arrives. It is what it would need to do in the years before that, and how long those actions take.

Framed that way, the timeline stops being the binding constraint. The binding constraint is that most organisations cannot currently produce a list of where they use public-key cryptography.

The inventory problem

Cryptography is not a system. It is a property of nearly every system, generally arriving through defaults rather than decisions. It authenticates software updates, establishes transport sessions, signs release artefacts, protects backups, underwrites device identity, secures configuration, and sits inside third-party libraries that were selected for unrelated reasons.

Almost none of that is recorded anywhere as a cryptographic dependency. It is recorded, if at all, as a library version, a certificate expiry date, or a firmware revision. The question “where do we use RSA” has no owner, no register, and in most estates no tractable answer without going and looking.

This is why post-quantum readiness is better understood as an asset discovery exercise. The cryptography is the easy part: the algorithms are specified, the libraries are shipping, and the standards work is well advanced. The difficult part is establishing what exists.

Harvest now, decrypt later

The timing argument does collapse in one specific place, and it is worth stating precisely rather than dramatically.

An adversary able to capture encrypted traffic today can retain it and decrypt it whenever the capability becomes available. Whether that matters depends entirely on how long the data stays sensitive. For a session token, it does not. For health records, legal files, source code, long-term contracts, intelligence, or anything with a statutory retention period measured in decades, it plainly does.

The practical exercise is unexciting and useful: identify data whose confidentiality must outlast the plausible arrival window, and treat its transport and storage as the first migration priority. Most organisations have less of this than they fear and more than they expect.

Some technologies change the assumptions beneath the system. The system rarely knows which assumptions those are.

Where the estate cannot be changed

The second priority is determined not by sensitivity but by lifecycle.

A web service can have its cryptography changed on a deployment cadence measured in days. An industrial controller, a medical device, a vehicle, a smart meter, or a satellite cannot. These systems have service lives of ten to twenty-five years, upgrade paths that may involve a site visit, and in some cases hardware roots of trust that cannot be re-keyed at all.

For that class of asset, the decision point is not the arrival of the quantum computer. It is the next procurement. Equipment being specified this year will still be running when the question is settled, and the cryptographic agility of that equipment is decided now, by whoever writes the requirement.

This is the most actionable consequence of the whole subject, and it is usually the one furthest from the security team’s remit.

Agility is the actual deliverable

There is a tempting way to fail at this: run a migration project, replace the algorithms, declare completion.

The algorithms will change again. Parameters will be revised, an implementation will be found wanting, and a second transition will be required on a shorter timescale than the first. An organisation that has completed one migration has proved very little. An organisation that can complete migrations has changed its position permanently.

Practically, agility means cryptographic choices are configuration rather than architecture; that the inventory is maintained rather than reconstructed; that certificate and key lifecycles are automated; and that a supplier’s roadmap for algorithm change is a procurement criterion rather than a surprise.

Starting

The first move is not cryptographic. It is to establish who owns the question, and to produce a partial inventory — deliberately incomplete, deliberately quick — covering externally facing services, long-lived data stores, and anything with a service life past the next decade.

That document is uncomfortable to read, which is its purpose. Every organisation that has taken this seriously describes the same sequence: the inventory was worse than expected, took longer than planned, and was the thing that made the rest of the work possible.