From inventory to roadmap: turning findings into a sequenced plan
A cryptographic inventory is a map, not a plan. This is how to convert discovered assets into a sequenced, owned, dated migration roadmap that leadership can fund and engineering can execute.
The roadmap is where risk becomes schedule
A migration roadmap sequences your discovered cryptographic assets into waves, each with an owner, a target algorithm and mode (hybrid or pure-PQC), a validation gate, and a rollback path. It is driven by risk — long-lived secrets behind quantum-vulnerable key exchange go first — and constrained by dependencies, such as your PKI being able to issue PQC-capable certificates before endpoints can use them.
Leadership does not fund an inventory; it funds a plan with dates. The bridge between the two is the roadmap. Its job is to answer three questions for every system that touches vulnerable cryptography: when do we change it, who owns the change, and how do we know it worked without breaking production.
Group findings into waves
Do not schedule individual assets — schedule waves. A wave is a set of changes that share a risk tier and a set of dependencies, so they can be planned, tested, and communicated together. A workable default is three tiers:
- **Wave 1 — harvestable, long-lived.** Externally reachable key exchange protecting data with a multi-year confidentiality lifetime. This is the harvest-now-decrypt-later front line; move it to hybrid key exchange first.
- **Wave 2 — signatures and internal exposure.** Code signing, document signing, and internal PKI. Forgery risk arrives with the quantum computer, not before, so this is urgent but not harvest-driven.
- **Wave 3 — short-lived and low-value.** Ephemeral sessions, low-sensitivity internal traffic, and systems approaching decommission. Sequence these last or fold them into normal refresh cycles.
The prioritization article covers the scoring that assigns assets to waves. The roadmap consumes that scoring; it does not re-derive it.
Respect the dependency graph
Risk sets desire; dependencies set what is possible. Certificates cannot be PQC before the issuing CA supports PQC algorithms. Endpoints cannot negotiate hybrid TLS before the client and server libraries both support the named group. A firmware signing change cannot ship before the verifier in the field understands the new signature format. Draw the dependency graph explicitly and let it reorder waves where it must — a Wave-1 desire blocked by a Wave-2 prerequisite becomes a two-step plan, not a delayed one.
Hybrid now, or wait for pure-PQC?
For key establishment, prefer hybrid (classical + PQC) as the default transition state: it protects against harvest-now-decrypt-later immediately while keeping a classical fallback if the PQC component is later found weak. For signatures, the trade-off is different — hybrid signatures roughly double size and verification cost, so decide per domain whether the belt-and-suspenders assurance is worth it. Record the choice, and the reason, per wave.
Make every roadmap item executable
A roadmap line that says "migrate PKI" is not executable. A roadmap line is ready when it names the system, the current algorithm, the target algorithm and mode, the owner, the validation gate it must pass, the rollback trigger, and the target window. If any of those is blank, the item is still in planning, not scheduled.
- System and environment (e.g. edge TLS terminator, production).
- From / to (e.g. RSA-2048 key exchange → X25519MLKEM768 hybrid).
- Owner and reviewer.
- Validation gate (interop matrix passes, latency within budget).
- Rollback trigger and procedure.
- Target window and dependencies that must clear first.
Keep the roadmap in the same system as the inventory so the two never drift. When discovery finds a new quantum-vulnerable asset, it should appear as an unscheduled roadmap item automatically — that is how you keep the plan honest as the estate changes.