Sequencing a migration

Most post-quantum programmes do not fail at the cryptography. They fail at the ordering. An inventory lands, someone sorts it by asset count or by which team answers email fastest, and the first quarter is spent on whatever was easiest to reach. That produces motion without reducing exposure. Sequencing is the decision that determines whether nine months of engineering removes your worst risk or only your most convenient risk.

This article describes how we sequence work in a Deep Migration Engagement, and how to apply the same reasoning yourself. It assumes you already have an inventory and a score for each asset. If you do not, start with How discovery finds cryptography and How the exposure score is built.

#Asset count is the wrong sort key

Counting is seductive because it is easy to report. A slide that says 60% of assets are remediated looks like progress to a steering committee. It is close to meaningless. Cryptographic assets are not interchangeable units of risk. One TLS terminator in front of a payments API and one self-signed certificate on an internal wiki both count as one asset, and they are separated by several orders of magnitude of consequence.

Sorting by count reliably produces three failures. Teams pick up the long tail of low-value assets first, because each one is quick. High-consequence systems get deferred, because they are hard and politically expensive. And the programme runs out of budget and attention before it touches anything that mattered.

• Count tells you how much work there is. It does not tell you what order to do it in.
• Score tells you how exposed an asset is today. It is an input to ordering, not the whole of it.
• Confidentiality lifetime tells you how long the data protected by that asset must remain secret.
• Blast radius tells you what else fails if you change that asset and get it wrong.

#Sort by confidentiality lifetime, then blast radius

The primary sort key is how long the data has to stay secret. This is the practical form of the harvest-now-decrypt-later problem: traffic captured today can be stored and decrypted whenever the capability arrives. If a record must remain confidential for fifteen years, the clock is already running against it. If a session token expires in ninety seconds, its confidentiality lifetime is ninety seconds, and no realistic future decryption capability threatens it. Harvest now, decrypt later sets out the reasoning in full.

Ask the data owner one question: if the ciphertext protecting this were published in a decade, what would the consequence be? Underwriting files, medical records, source code, long-term contracts, key material and archived backups all answer badly. Cache invalidation traffic and health-check probes answer well. That single question separates an estate faster than any automated classifier.

The secondary sort key is blast radius. Blast radius is not the value of the asset. It is the number of things that break if the change goes wrong: how many callers depend on this endpoint, whether failure is visible to customers, whether the rollback is a configuration flag or a firmware campaign, and whether the system sits in the revenue path. High confidentiality lifetime with small blast radius is where you start. High lifetime with large blast radius is where you go once the process is trusted.

Primary key

Confidentiality lifetime of the protected data, in years

Secondary key

Blast radius if the change fails, from single service to estate-wide

Tie-breaker

Whether the asset gates other work, for example an internal certificate authority

Deliberately not a key

Asset count, team ownership, or how loudly a stakeholder is asking

#The order layers usually move in

Across the estates we have looked at, the layer order below holds more often than not. It is not a law. It is a default that survives most dependency analysis, because each step makes the next one cheaper. Deviate from it when your dependency graph says to, and record why.

1. 1

   Certificate and PKI groundwork

   Get the issuance path under control before you change any algorithm. That means a complete certificate inventory, automated issuance and renewal, short lifetimes, and the ability to rotate a trust chain without a change freeze. Almost every later step is gated on this, and teams that skip it stall halfway through transport work.

2. 2

   Transport and key establishment

   Move key exchange to a hybrid construction combining a classical exchange with ML-KEM. Transport is where harvest-now-decrypt-later bites, so it delivers the largest confidentiality gain per unit of effort. It is also the most mature part of the ecosystem, with the widest library and load-balancer support. See Hybrid modes and keeping your rollback.

3. 3

   Signing, and code signing early within it

   Signatures protect integrity rather than confidentiality, so an adversary cannot harvest them now to forge them later. That earns signatures a later slot overall. Code signing and firmware signing are the exception worth pulling forward, because a signing key you use today may still be verifying artefacts a decade from now, and the verifier is often the thing you cannot update.

4. 4

   Long-lived data at rest

   Archives, backups, document stores, database encryption and escrowed key material. The work here is usually re-encryption at scale plus changes to a key hierarchy, which is slow, expensive and mostly invisible to users. Start scoping it early even though it lands late, because the storage and time budget is what surprises programmes.

5. 5

   Embedded, hardware and appliances

   HSMs, payment terminals, smart cards, industrial controllers, network appliances, and anything whose cryptography sits in silicon or in a vendor firmware image you do not control. These move on procurement and refresh cycles, not on your sprint cadence. The deliverable in year one is usually a vendor commitment and a funded refresh plan, not a migration.

6. 6

   Everything you decided to accept

   Some assets will be left on classical cryptography on purpose, because their confidentiality lifetime is short and the cost of change is not justified. Write that decision down with an owner and a review date. An accepted risk that nobody recorded becomes an audit finding later.

#Dependencies decide what is actually possible

A sequence that ignores dependencies is a wish list. Before committing to an order, walk the constraints that can invalidate it. Four of them account for most of the re-planning we see.

• Both ends must agree. Key establishment is negotiated. You cannot unilaterally move a channel unless the peer supports the new construction, so external integrations move at your counterparty’s pace.
• Middleboxes see the handshake. Load balancers, TLS-terminating proxies, WAFs, inspection appliances and older firewalls may reject a handshake larger than they expect. This is the most common cause of a failed first attempt.
• Libraries gate applications. An application cannot move before its runtime, its TLS library and its HSM firmware support the algorithm. Map platform versions early; they usually set the true earliest start date.
• Verifiers outlive signers. If a device in the field verifies your signatures, the device dictates your signature migration, not your build pipeline.

Interoperability is the constraint teams most often underestimate. Standards conformance is necessary but not sufficient: two conformant implementations can still fail to negotiate, because of parameter-set choices, code-point disagreements, or a size limit somewhere in the middle. Plan an interoperability test between every pair of implementations that has to talk, and treat a passing test as the gate for the change, not the standard’s publication date.

#Choosing a first wave that proves the process

The purpose of wave one is not risk reduction. It is to prove that your organisation can change cryptography and observe the result. Pick something whose failure is survivable and whose measurement is honest. If wave one is invisible when it works and non-catastrophic when it breaks, you will get a second wave.

1. 01Pick internal service-to-service traffic where you control both endpoints and can revert with a configuration change.
2. 02Require that the path already has latency and error-rate telemetry good enough to detect a regression. If you cannot measure it now, you cannot prove anything about it later.
3. 03Include at least one middlebox, so the wave exercises the part of the network that tends to break.
4. 04Exclude anything in the revenue path, anything under a change freeze, and anything whose owner cannot commit review time this quarter.
5. 05Write the rollback procedure and rehearse it before enabling the change, not after the first incident.
6. 06Capture a before-and-after performance comparison. That artefact is what buys you the next wave. See Proving the performance impact.

#What a realistic multi-quarter plan looks like

We describe waves relatively rather than by calendar date, because the start depends on your change calendar, your vendor timelines and your audit cycle. The shape below is what a plan tends to look like once dependencies are respected. Timing stays a placeholder until it is agreed with your programme office.

Two things here are deliberate. Wave 0 never finishes, because inventory and issuance are standing capabilities rather than projects. And the waves overlap, which is what stops a programme discovering its storage bill in the final quarter.

#Where our part stops

Sequencing is not a one-time artefact either. Every wave changes what you know, and a plan that has not been revised in two quarters is usually a plan that stopped being true. The Theos Method documents how we version that reasoning so an auditor can see why the order changed.