Marin Ivezic
A program plan published on PostQuantum.com for one large telecommunications operator counted more than 120,000 discrete tasks across a decade. Most program managers who meet that figure ask whether it is padded. That is the wrong first question. Schedules of that size fail on the order of the work, not the volume of it, and the order is the part a project manager actually controls.
Scope, by this point, is fairly well settled. NIST finalised its first three post-quantum standards in August 2024, regulators in the UK and the EU have published dates, and the list of systems needing attention is whatever your discovery finds. Sequencing is the open decision. Which systems move in the first wave, which cannot move until something else finishes, and what has to be true before any wave is allowed to start.
What a wave actually is
An integrated master schedule is a dependency network, not a task list. Every activity in it has predecessors, successors and an owner, and the schedule is only useful to the degree those relationships are real. A wave is the unit that makes such a network tractable for cryptographic work: a set of remediation packages that share a mitigation pattern, a dependency owner and a change window, released together.
Get the grouping right and the rest of the wave planning follows. Grouping by business unit produces waves that stall the moment one team’s vendor slips. Grouping by criticality tier alone produces a first wave containing 40 different technologies, each with its own upgrade path. Grouping by pattern and dependency produces waves that can be planned once and executed many times, which is the only way a migration of this size finishes inside a decade.
Four gates, and what each one releases
We teach sequencing as four gates. A gate is a condition that has to be true for a specific wave before that wave can start, and different waves clear the same gate on different dates.
Gate one: inventory evidence for the systems in this wave. Not enterprise-wide discovery. This distinction saves programs a year. Waiting for a complete cryptographic bill of materials before starting anything is the most common self-inflicted delay we see. A CBOM is a structured inventory of the algorithms, keys, certificates, libraries and protocols in a system, and it is a living data model rather than a document with a completion date. Your enterprise CBOM will never be finished. The inventory for your remote access estate can be finished in six weeks, and that is the gate that governs the remote access wave.
Gate two: an approved and validated pattern. Every system class needs a decision before it needs an engineer: upgrade in place, run a hybrid configuration, wrap the traffic at a gateway, isolate and reduce exposure, replace the hardware, or retire the service. Six answers, and the rule set for choosing between them is a program deliverable. A wave whose pattern has not been validated in a lab is a research project with a delivery date, not a wave.
Gate three: shared foundation capacity. The certificate authority that will issue for this wave, the hardware security modules that will hold the keys, and the network elements the traffic will cross all have to tolerate the new material before any application team touches anything. This is the gate programs skip, and it is the one that produces year-four crises.
Gate four: change window, rollback and evidence. A wave with no rehearsed rollback is a wave that will be halted by the first operational incident, and a wave with no evidence capture will be re-executed in two years when an auditor asks for proof.
Why the foundation gate is not negotiable
Post-quantum material is bigger, and the size difference is not marginal. In a hybrid key exchange combining X25519 with ML-KEM-768, the standardised key encapsulation mechanism formerly called Kyber, the client sends a key share of 1,216 bytes: the 1,184-byte ML-KEM-768 encapsulation key specified in FIPS 203, plus 32 bytes of X25519. An ML-DSA-65 signature, from the standard formerly called Dilithium, is 3,309 bytes against 64 for an ECDSA P-256 signature, whose parameters are specified in FIPS 186-5. Certificate chains grow accordingly, handshakes fragment, and fixed buffers in middleboxes that nobody has looked at since 2016 start rejecting connections.
Sequence an application wave ahead of the network and PKI work, and every one of those failures lands on an application team that cannot fix any of them. They will raise defects against a firewall they do not own, the wave will slip, and the slip will be recorded as an application problem. Sequence the foundation first and the same wave becomes a configuration change with a test plan.
The practical rule: shared infrastructure is always its own wave, it always runs early, and its acceptance criteria are written by the teams who will depend on it.
Track 0 runs beside the gates, not behind them
Two risks are already accruing and neither waits for a gate.
Harvest now, decrypt later means an adversary copies encrypted traffic or archives today and decrypts them when a capable quantum computer exists. Anything with a long confidentiality requirement is exposed the moment it crosses a network, which makes protection a question of data lifetime rather than migration sequence.
Trust now, forge later is the signature-side version. A signature that is valid today can be forged later, so long-lived signed artefacts, code signing chains and archived documents need timestamping or re-signing regardless of where their host systems sit in the wave plan.
Track 0 is the parallel portfolio that addresses both: re-encrypting high-value archives under fresh key hierarchies, shortening certificate lifetimes in high-risk trust domains, automating certificate lifecycle management, and hardening the signing chains. It starts in month one. It has its own budget line, because the moment it competes with wave work for the same engineers it loses every time.
Certificate automation carries a second justification. The CA/Browser Forum has adopted a phased reduction in maximum public TLS certificate validity, reaching 47 days by March 15, 2029. Manual renewal stops being viable well before post-quantum certificates arrive.
Three sequencing errors that surface in year four
Vendor-dependent work in the first wave. Vendor readiness is a critical path constraint, not a procurement footnote. If a product family has no post-quantum roadmap, no amount of internal planning moves it, and putting it in wave one means the wave inherits a date nobody in your organisation controls. Classify suppliers by cryptographic criticality early, then place their systems in waves that match their published roadmaps. Where a vendor cannot commit, the wave decision is isolation, a gateway, or replacement procurement, and each of those has a lead time that has to sit in the schedule.
Flag-day cutovers scheduled last. A flag day is a transition where both sides must switch simultaneously, because no compatible fallback exists. Bilateral key exchange with a clearing partner, lawful interception interfaces and certain inter-carrier links all behave this way. These are the least reversible items in the program, and putting them at the end means the first rehearsal happens under deadline pressure with a partner organisation whose own program is late. Schedule the rehearsal in the middle years, even if the cutover stays at the end.
Hybrid treated as a resting state. Running classical and post-quantum algorithms together is the right transitional choice, and it doubles the test matrix: classical fallback, post-quantum only, and the combination. Every hybrid deployment needs a sunset task for the classical component, scheduled in the same wave that created it. Otherwise the program ends with a permanent second cryptographic estate to monitor and patch.
Sequencing against dates that disagree
Multinationals do not get one deadline. NIST’s draft transition guidance, IR 8547, proposes deprecating RSA and elliptic-curve signatures after 2030 and disallowing them after 2035. The UK NCSC roadmap sets discovery by 2028, high-priority migration by 2031 and completion by 2035. The EU’s coordinated roadmap asks member states to address high-risk use cases by the end of 2030 and to complete migration by 2035. Several other national regulators have published earlier dates than any of these, and some sector regulators are earlier again.
The sequencing rule is simple and unpopular: the earliest binding date for a given system sets that system’s wave, and the average is irrelevant. In practice this means the estates sitting under the earliest regulator move ahead of the ones sitting under the latest, which cuts across how most global programs are organised and how most global budgets are allocated. Map the obligations by geography and sector once, translate them into internal target dates per domain, and revisit the mapping annually, because the mapping itself is recurring governance work over a seven to ten year horizon.
A sequencing review you can run in a week
Take your current plan and ask four questions of each wave in the first three years.
- Which gate is this wave currently failing, and who owns the gate?
- What is the single longest-lead predecessor, and is it internal or a vendor?
- If this wave slips two quarters, which other waves slip with it?
- What evidence will exist at the end proving the systems in it are quantum-safe end to end?
Waves that cannot answer question two are usually mis-cut. Waves that cannot answer question four will be repeated. And if the answer to question three is “nothing,” the wave is probably not on the plan’s spine at all, which is worth knowing before it consumes a quarter of your engineering capacity.
The capability underneath all of this
Sequencing gets easier as crypto-agility improves, where crypto-agility means the ability to change an algorithm without changing the application: cryptographic operations behind a configurable interface, policy separated from mechanism, and algorithm choices expressed as configuration rather than code. Each wave that leaves an estate more agile shortens every wave after it, which is a reason to weight early waves toward the systems where that investment compounds.
What none of it survives is a plan built by people who have not been taught what the dependencies are. The judgment calls in this article – whether a pattern is validated, whether a vendor roadmap is credible, whether a foundation is ready – sit with the program office, not with a tool. Building that judgment across a program team is a training problem before it is a scheduling problem.
For migration methodology and the underlying framework, see pqcframework.org. For deeper technical background on why post-quantum material breaks networks, PostQuantum.com covers the infrastructure engineering in detail. And for structured training that takes program and project managers from cryptographic inventory through wave design and governance, our certification programs are at quantumacademy.com/.