Post-quantum cryptography: what to do before 2030

A security review we sat in went quiet on a simple question: how long does this data have to stay secret? The system held identity enrolment records for a public programme. Nobody in the room could give a number, and the answers offered ranged from seven years to for ever. That question decides the entire post-quantum migration plan, and in most organisations it has never been asked of anyone with the authority to answer it.

The engineering side of this is less mysterious than the marketing suggests. Standard algorithms exist and have names: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. Libraries implement them, and choosing between them is an afternoon's reading. The work sits elsewhere: discovering how much of an institution's cryptography is embedded in things that cannot be changed quickly, and sequencing the change so it fits an organisation that buys hardware on five-year cycles and cannot take its core systems offline.

The clock is retention plus migration

The arithmetic that decides urgency has three terms. How long the data must remain confidential. How long the migration will take. How long until an adversary can break the algorithm protecting it. If the first two added together run past the third, the data is already exposed, and no future decision fixes it.

That is what harvest-now-decrypt-later means in practice. An adversary with storage and patience captures encrypted traffic today and keeps it. The economics are unremarkable: storage is cheap and the capture is passive, so there is no incident to detect and nothing to respond to. The traffic is read years later, when the tooling exists.

Whether that matters depends entirely on the first term. Card authorisation traffic is close to worthless in ten years, because the card was reissued twice and the balance is long settled. A land registry, a health record, a national identity enrolment, a defence contract, a lawful intercept archive or a bank's know-your-customer file is a different proposition. Those records are still sensitive when the people in them have grandchildren. Sorting an estate by that criterion is the first useful output of a migration programme, and it is a business decision that an engineer cannot make alone.

The deadline is the day the thing you encrypted this morning stops being worth reading. For a great deal of public sector data, nobody has ever set that day.

Confidentiality moves first, signatures move on a different schedule

Key establishment is where harvest-now bites, so it moves first. This is also the easy half: hybrid key exchange, combining a classical algorithm with a post-quantum one so the session is safe if either holds, is deployable today in mainstream stacks and degrades gracefully against endpoints that do not support it. External-facing traffic and long-lived tunnels between sites are the sensible starting points, because they carry the most traffic worth capturing.

Signatures have a different shape. A signature made today is broken only when the attacker can forge one, which does not retrospectively expose anything, so the pressure looks lower. The complication is lifetime. A root of trust issued now may be embedded in devices shipping for the next decade and trusted for a decade after that. Firmware signing keys are burned into hardware. Document signing has to verify in a dispute fifteen years from now. Anything whose signature must still be checkable in the 2040s is on the early list even though the threat is on the late list.

What actually blocks the migration

Nothing on this list is the algorithm.

Sizes. Post-quantum keys and signatures are substantially larger than the elliptic curve equivalents they replace. That breaks fixed-width database columns, message formats with length assumptions, smartcards with a few kilobytes of storage, QR codes that have to stay scannable on a printed page, and embedded firmware that was sized to the byte. Each of those is owned by a different team on a different release calendar.

Hardware security modules. Keys that live in an HSM move when the vendor's firmware supports the new algorithms and the certification catches up. Neither is under the institution's control, and the purchase cycle behind a replacement is measured in budget years. This is worth asking vendors about now, in writing, because a dated answer changes the plan.

Devices in the field. A controller installed on a power plant is there for fifteen years, and its cryptography is in firmware on a board that may no longer be manufactured. We instrument plant hardware for telemetry and have watched what it takes to change anything on that estate: a site visit, an outage window, and a commissioning engineer. Every device installed between now and the migration is a device that will still be there afterwards, which makes procurement requirements the cheapest control available.

Third parties. The SaaS platform terminating TLS on your behalf, the regulator's submission portal, the payment network, the partner whose file transfer has used the same host key since 2015. Both ends of a protocol must move, and half of the estate belongs to somebody with their own priorities. Migration timing here is a contract conversation.

Certificates being issued this quarter. Anything with a long validity period issued now is a commitment that outlives the planning horizon. It costs nothing to shorten lifetimes today, and it removes work later.

A sequence that fits how institutions actually move

1. 01Inventory what you encrypt, with a named owner per entry. Most organisations cannot answer this today, and everything else is guesswork until they can.
2. 02Classify by confidentiality lifetime, and get the classification signed by someone with the authority to sign it. Seven years and for ever are different programmes.
3. 03Fix agility in anything being built now: algorithm identifiers in stored records, version fields, no hard-coded key or signature sizes. This is nearly free at design time and expensive afterwards.
4. 04Enable hybrid key exchange on external-facing traffic and site-to-site tunnels, where the stack already supports it.
5. 05Put dated post-quantum commitments into procurement for every hardware purchase, every renewal and every new contract. An hour spent on contract language here removes more work later than anything else on this list.
6. 06Shorten certificate lifetimes and rehearse the rotation, because a migration is a rotation performed under time pressure.
7. 07Plan the root of trust migration explicitly, since it takes longest and cannot be compressed.
8. 08Re-encrypt the archives with the longest retention, having measured the throughput on real volumes rather than on a sample.

Step three is the one worth defending in a budget meeting, because it produces nothing visible. A system built this year with a version field in its record format and its signature verification behind an interface can change algorithm in a release. The same system without those costs a migration project with a maintenance window and a reconciliation exercise. The difference in build cost is close to nothing.

What we would not do

We would not write any of it ourselves. Cryptographic implementation is one of the few areas where the correct professional posture is to use what has been reviewed by people who do only this.

We would not rip out working cryptography on a compressed timetable. A rushed migration produces its own failures, and those are certain rather than speculative. The measured version, hybrid first, agility next, hardware on its natural replacement cycle, gets to the same place with fewer outages.

We would not run a proof of concept as a substitute for the inventory. A demonstration of a post-quantum handshake proves the library works, which was not in doubt. It creates a comfortable feeling of progress on a programme whose real state is unknown.

And we would not treat 2030 as a date set by physics. It is a planning horizon set by procurement cycles, asset lifetimes and how long it takes a large institution to change something in the middle of its estate. Whether a capable machine exists in 2030 or 2040 does not change what should be happening in the next eighteen months, which is why the debate about timing is mostly a way of postponing the inventory.

The unglamorous truth about the first pass

The first inventory is always wrong, including ours. The mistake we have made is scoping it to systems the client operates, which silently excludes every managed service, every partner link and every regulator's submission portal. Those are precisely the entries with the longest lead time, because somebody else owns the schedule and has no obligation to share it.

The second mistake is recording what the configuration says instead of what the endpoints actually negotiate. A capture at the boundary usually finds at least one service still agreeing to something that was supposed to have been retired two policy cycles ago. The inventory deserves a piece of its own, and it gets one. The point here is that it belongs at the start, and that the version produced in month one will be corrected in month four by people who spot their own system missing from it.

What this looks like when it goes well

A realistic programme for a bank, a utility or a government department has four things running in parallel by the end of its first year. An inventory that is maintained rather than produced once. A classification of data by confidentiality lifetime, signed. Hybrid key exchange live on the external edge. Procurement language that stops the estate getting worse while the migration runs.

None of that is difficult engineering. It is coordination across teams that have no reason to talk to each other, on a risk with no incident to point at, in competition with work that has a visible business case. That is why it slips, and it is why we push clients to give it a named owner with a budget line rather than adding it to a security backlog where it will be reprioritised every quarter by people responding to things that have already gone wrong.

Nobody gets credit for this work. Done properly it produces no outage, no announcement and no measurable improvement in anything the business tracks. The only visible outcome is an absence: a category of failure that never arrives, on a schedule nobody controls. That is the same argument as fire doors, and it tends to be made with the same lack of enthusiasm right up until the week it stops being theoretical.