What belongs in a post-quantum migration plan?

What a reviewable plan contains

A post-quantum migration plan is frequently a slide: the standardised algorithms, a diagram of affected systems, and a target year that matches the published guidance. It passes an internal review and provides no basis for action, because nothing in it says what happens next quarter or who is responsible.

A plan that survives scrutiny contains seven things:

1. The inventory, ranked by migration difficulty and by required confidentiality lifetime.
2. Workstreams, each with a named owner who controls the capacity to deliver it.
3. Dependency lead times for each workstream—the vendor release, hardware refresh, counterparty change or standards decision it waits on.
4. The interim state for each system, since most will run a hybrid or mixed configuration for years.
5. Exit criteria for each interim state, so the transition ends rather than becoming the architecture.
6. Decisions due now, with dates, distinguishing what is blocked from what is merely unscheduled.
7. The residual risk position: what remains exposed at each stage, accepted by whom.

The fifth is the one most often absent, and its absence is how a hybrid deployment becomes permanent.

Organise by dependency lead time

The instinct is to sequence by system importance. That produces a plan whose critical path is discovered late, because the systems that take longest are rarely the ones that seem most important.

Sequence by lead time instead, working backwards from the date the change must be complete:

Workstream	Typical lead time	Why
Deployed devices with immutable verification roots	Product generation; may be never for shipped units	Requires a hardware revision
Hardware security modules	1–3 years	Vendor firmware, possible hardware refresh, re-validation
Regulated or specified counterparty protocols	2–4 years	Specification body timetable, then bilateral upgrade
Enterprise counterparty integrations	1–2 years	Their roadmap, contract cycle, test coordination
Third-party platforms and SaaS	Vendor roadmap	You cannot act; you can ask and record
Internal PKI hierarchy	6–18 months	New roots, cross-signing, client trust distribution
Internal service-to-service TLS	1–2 quarters	Library and platform support, then rollout
Externally facing TLS	1–2 quarters	Largely available; browser and client support already broad
Stored data re-encryption	Depends on format	Trivial with algorithm identifiers, a project without them

Reading the table top-down gives the order in which conversations must start. The bottom rows are engineering work you control and can schedule; the top rows are commitments you must begin now to have any chance of the published dates.

The decisions that are already late

Three decisions have lead times long enough that deferring them past the current year makes the 2031 milestone unachievable for most organisations.

Hardware roots of trust for products currently in design. A device entering design now will ship for several years and be supported for a decade after that. If its firmware verification root cannot accept a quantum-resistant signature, that decision is being made permanently for every unit. FIPS 204 standardises a lattice-based signature and hash-based schemes are also standardised; provisioning space for a larger signature and a scheme identifier in the image header is cheap now and impossible later.

Hardware module refresh planning. Modules that hold your most important keys need firmware supporting the new algorithms, and in many cases the current hardware generation will not. The procurement cycle, validation timeline and key migration ceremony together consume years.

Counterparty and contract engagement. Where a protocol is specified by a scheme operator or agreed bilaterally, the change is not yours to make. Getting it onto the other party’s roadmap has a lead time measured in contract cycles.

CISA’s quantum-readiness guidance is explicit that supplier engagement is an early activity rather than a later one, and this is why: the organisation’s own engineering is rarely the constraint.

Name the interim state and its exit

Almost every system will spend years in a state that is neither old nor new: accepting both classical and post-quantum options, or running hybrid key establishment, or verifying signatures from two schemes.

Each interim state should be described explicitly—what is accepted, what is offered, what is preferred—and paired with an exit criterion that does not depend on judgement. Useful criteria are observable: when fewer than a stated proportion of connections negotiate the classical option; when a named counterparty confirms support; when a device population below a stated size remains on the old scheme; or a fixed date after which the option is removed regardless.

Without a criterion, the interim state persists. The classical option remains accepted indefinitely, which means the migration has added a new capability without reducing the old exposure—and an active downgrade attack still reaches the classical path.

This is why telemetry on negotiated parameters belongs in the plan as a workstream in its own right. You cannot retire an option you cannot measure.

Signatures need their own workstream

Encryption and signatures migrate for different reasons on different timetables, and combining them into one workstream obscures both.

Key establishment migration is driven by retrospective exposure and is largely available: the standardised mechanism in FIPS 203 is supported in mainstream TLS implementations and platforms, and hybrid modes preserve classical security during the transition.

Signature migration is driven by how long an assertion must remain trustworthy and by how hard the verifier is to reach. It is also harder in practice, because post-quantum signatures and public keys are considerably larger than their classical equivalents, which has consequences for certificate sizes, handshake sizes, firmware image headers, constrained links and any format with a fixed field length.

Treat it as a separate workstream with its own inventory: certificate hierarchies, code and firmware signing, document signing, token signing, and device attestation. The sizing implications need measuring in your own systems rather than assuming, and the formats that cannot accommodate a larger signature are the items that determine your timeline.

What the plan should say about cost

A plan without a cost estimate does not get funded, and a cost estimate built from algorithm work will be wrong by an order of magnitude.

The cost concentrates in four places: discovery and inventory maintenance; the engineering to add agility to systems that lack it; hardware and vendor refresh for modules and devices; and the coordination effort with counterparties, which is largely people time over a long period. Cryptographic implementation is a minor line item, because the standards bodies and library maintainers have done that work.

Presenting it this way has a useful side effect. Most of the agility engineering—algorithm identifiers, configuration-driven parameter sets, key wrapping, negotiation telemetry—is valuable regardless of quantum computing, because it makes every future cryptographic transition cheaper. That makes it easier to fund than a programme justified solely by a threat with an unknown date.

Reviewing the plan against the dates

Once a quarter, read the plan against the published milestones rather than against its own internal schedule. NIST’s transition guidance and the UK timelines both provide external dates, and the useful question is whether each workstream’s lead time still fits inside them.

Three signals indicate a plan that is drifting: a workstream whose lead time has grown while its deadline has not moved; an interim state whose exit criterion has been revised for the second time; and a dependency owner who has not been contacted since the plan was written.

The plan’s value is that it makes those signals visible early enough to change something. A plan that names a target year and no dependencies cannot drift, because there is nothing in it to observe.