Guidance
The migration model.
Every published methodology converges on the same six phases, whatever each one calls them. What separates the descriptions is not the phases — it is which failure each one warns you about.
Each phase below: what happens, then where it goes wrong.
-
Your programme
01 Preparation
Owner, mandate, budget
Run as a cryptography project
-
Post Quantum Leap
02 Inventorisation
Find every certificate, key and protocol
Inventorying the CMDB, not the network
-
03 Prioritisation
Rank by criticality, exposure, lead time
Ranking by effort alone
-
Your programme
04 Migration
Replace or wrap, in dependency order
Assuming a drop-in replacement
-
Post Quantum Leap
05 Verification
Prove it on the wire, not in the config
Trusting the change ticket
-
06 Monitoring
Watch for regressions and new arrivals
Closing the project
Reading the chart
- The last phase returns to the inventory rather than closing. An inventory that is not kept live stops being one.
- The lane along the bottom is not two halves. Your own programme sets the mandate and makes the change; the measuring phases either side of it are ours.
The phases in full
Each phase, and the specific way it is usually got wrong.
01 Preparation
What it is
Establish who owns the migration, what it is measured against, and what it is funded to do.
Where it goes wrong
Treating it as a cryptography project. It is a dependency-mapping project that ends in cryptography.
02 Inventorisation
What it is
Find every certificate, key, protocol and library in use, including the ones nobody documented.
Where it goes wrong
Inventorying what the CMDB says exists rather than what the network answers to. The gap between the two is the finding.
03 Prioritisation
What it is
Rank by how long the data must stay confidential, how critical the system is, and how long its own migration will take — starting the long-lead, high-criticality work first, and running the quick wins alongside it rather than instead of it.
Where it goes wrong
Ranking by effort alone. Easy systems clear quickly and report well, but the long-lead, high-criticality ones — and those most exposed to harvest-now-decrypt-later — are where starting late cannot be recovered.
04 Migration
What it is
Replace or wrap the algorithms, in dependency order, usually hybrid first.
Where it goes wrong
Assuming a drop-in replacement. Post-quantum signatures are an order of magnitude larger, and that breaks protocols, buffers and hardware before it breaks anything cryptographic.
05 Verification
What it is
Prove the change took effect on the wire, not merely in the configuration.
Where it goes wrong
Trusting the deployment record. A configuration that says ML-KEM and a handshake that negotiates X25519 look identical from the change ticket.
06 Monitoring
What it is
Watch for regressions, new systems arriving unmigrated, and algorithm guidance moving underneath you.
Where it goes wrong
Closing the project. Guidance has already moved twice while most organisations were still at inventorisation.
The traps are our own observation from running discovery against real estates, not a quotation from any of the sources on these pages.
The phases are a loop, not a line
Guidance has already moved more than once while most organisations were still at inventorisation: parameter sets have been withdrawn, deadlines have been brought forward, and one authority now ends approval for classical asymmetric cryptography five years ahead of the rest. A migration planned as a project that finishes will be planned again. The organisations that spend least are the ones that build the inventory once and keep it live.
Where Post Quantum Leap fits
The phases marked Post Quantum Leap in the chart above are ours. We find every certificate, protocol and cipher in your estate, grade them against your policy, rank what to move first, and prove on the wire that it moved. The rest is yours: setting the mandate and making the change are governance and engineering decisions no scanner makes for you.