Two estimates for the same job
In August 2024, NIST finalized three post-quantum cryptography standards. ML-KEM handles key establishment; ML-DSA and SLH-DSA handle digital signatures. Many organizations marked the moment by asking an infrastructure team for a number, and those numbers usually come back small. A few hundred line items. One or two budget cycles. Replace the VPN concentrators, reissue the certificates, and the work is done.
The most detailed public account of a real program plan says something else. Writing on PostQuantum.com, Marin Ivezic describes an integrated master schedule for a large telecommunications operator that runs to more than 120,000 discrete tasks over a seven to ten year horizon.
Two estimates for the same job, separated by three orders of magnitude. Only one of them can be right.
Scoping post-quantum work as a technology upgrade produces the small number, and scoping it as a program produces the large one. What follows is where the small estimate loses the work, and what a sponsor can ask to find out which of the two estimates they are holding.
What counts as a task when the schedule is real
An integrated master schedule, or IMS, is not a checklist. Public scheduling guidance treats it as a dependency network covering all authorized work. The U.S. Government Accountability Office’s Schedule Assessment Guide asks that a credible schedule capture every activity in scope, sequence those activities logically, assign resources to each, and expose a validated critical path. Department of Energy guidance sets a similar bar, requiring discrete tasks and the relationships needed to finish the job.
Hold a post-quantum plan against that standard. “Upgrade TLS to post-quantum” is not a task. A line like that admits one of two things. Either the team doesn’t yet know the owners, the dependencies and the outage windows, or the team knows them and hasn’t written them down. The first makes the schedule unexecutable. The second makes it ungovernable.
The counting rule matters just as much, and it’s where most of the skepticism about six-figure schedules comes from. Serious programs don’t write one task per certificate or one task per server. They write repeatable work packages – migrate this service tier, in this region, using this approved pattern – and then schedule the machinery that makes those packages safe to run. A single remediation package runs to something on the order of 15 to 25 scheduled tasks, covering library assessment, code and configuration changes, key rotation, unit and integration and performance testing, security review, rollback design, staged deployment, monitoring, evidence capture, and documentation.
Multiply a few thousand packages by twenty, and you’re at 40,000 tasks without having touched governance, vendors, testing or training.
Where the small estimate loses the work
Cryptography sits below the architecture diagram
Ask an architect where the cryptography is, and you’ll get the diagram. Ask a discovery tool, and you’ll get several times more.
Take a single interbank payment. The customer channel runs TLS with ephemeral elliptic-curve key exchange, plus multi-factor authentication and a mobile app pinning its own certificates. Inside the bank, microservices authenticate to each other with mutual TLS, network segments are joined by IPsec, and messaging middleware carries its own transport encryption. Data at rest sits under database and column-level encryption with card numbers tokenized. Audit logs are hash-chained. The SWIFT interface runs on PKI certificates held in validated hardware security modules, and settlement messages carry digital signatures on top of the tunnel that already protects them.
None of that includes what never appears on a diagram at all. Secure boot and device trust anchors. Container image signing. MACsec on the links, DNSSEC on the names. Federation protocols in the identity plane. Code signing in the build pipeline. Baseboard management controllers with their own secured channels.
One finding from the field makes the point concrete. In a building assessment Ivezic describes, the client found more than 160 distinct categories of connected smart device, installed by facilities, physical security and engineering teams, none of it known to IT. Certificate counts behave the same way: the number an architecture team can name is smaller than the number a discovery run returns, and the gap is usually the internally trusted estate nobody owns.
Every one of those things is an input to the plan. Most of them are absent from the first estimate because nobody knew to look.
Most of the work isn’t cryptography
In the model Ivezic publishes, only around 30,000 of the 120,000 tasks are direct remediation, meaning the cutovers and deployments themselves. The remaining 90,000 are the enablement system that makes remediation possible. Governance and risk integration. Reporting, metrics and audit evidence. Discovery run as a living capability rather than an annual scan. Vendor lifecycle enforcement. Testing and interoperability assurance. Workforce and change management. Operations through the long hybrid period when classical and post-quantum algorithms run side by side.
That shape isn’t an artifact of one consultant’s plan. It’s what the guidance already asks for. NIST’s crypto-agility work treats agility – the ability to change cryptographic algorithms without rewriting the applications that depend on them – as a standing enterprise capability with training, tooling and continuous testing attached, not a one-time engineering sprint. On the policy side, OMB Memorandum M-23-02 requires U.S. federal agencies to name accountable leads, submit cryptographic inventories on a recurring cadence, and file funding assessments alongside them. That is a management system with standing recurring obligations, and every recurrence is a scheduled task.
Measurement generates work in the same way. Designing indicators, wiring telemetry from inventory and configuration systems, scoring how confident you actually are that discovery is complete, and assembling evidence packs an auditor will accept all have to be built and then run, quarter after quarter.
Part of the estate can’t be upgraded at all
Operational technology – the industrial control systems, building management, power distribution and medical devices that run physical processes – breaks the assumptions that make IT migration schedulable.
These components routinely stay in service for ten to twenty years or more. Many run on 8-bit or 16-bit microcontrollers with a few kilobytes of working memory. Patch windows are measured in months. A safety instrumented system can’t be taken down for a firmware change without pre-testing and safety analysis, and in regulated settings the change may trigger recertification with a medical device or aviation authority. Some devices have no over-the-air update path and were never designed to have their algorithms replaced.
Low-power connectivity adds a hard ceiling. A LoRaWAN frame carries as little as 51 bytes of payload in European regional parameters, or 11 bytes in some U.S. configurations, under a one percent duty cycle. Sigfox allows 12 bytes. Now compare the material a post-quantum handshake has to move. The IETF’s hybrid key exchange draft specifies an X25519MLKEM768 client key share at 1,216 bytes against 32 bytes for X25519 alone, roughly 38 times larger. An ML-DSA-65 signature is 3,293 bytes against 64 bytes for ECDSA P-256, roughly fifty times larger. Those numbers don’t fit, and no amount of program management makes them fit.
So the plan fills with workarounds rather than upgrades. Crypto-agile gateways at the boundary. Network segmentation to shrink what a future adversary can reach. Isolation for devices that will never change. Procurement, installation and commissioning for the ones that must be replaced, often on multi-year lead times. In a program of that shape, this layer takes a share of the schedule well out of proportion to its share of the asset count, because a safety-certified controller costs far more per device to touch than a web server does.
Vendor readiness sets the critical path
The single most expensive assumption in the whole exercise is that vendors will handle the quantum-safe transition for you. Sponsors hold it more often than they say it out loud, and it survives right up to the first integration test.
Vendors shipping post-quantum capable products is necessary and nowhere near sufficient. You still have to determine which products are in use and at which versions, test the configurations against your own integrations, coordinate upgrade timing across systems that depend on each other, and prove the chain is quantum-safe end to end rather than in one hop. The joint CISA, NSA and NIST quantum-readiness guidance treats vendor engagement as a core migration step for exactly this reason, and asks organizations to put post-quantum delivery expectations into contracts rather than roadmap conversations.
The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) timelines show why this becomes the constraint. Different technology categories carry different target years for support, preference and exclusive use, and custom or legacy categories tend to convert into waiver and replacement decisions rather than upgrades. Over a decade, some suppliers will also discontinue platforms you depend on, which turns remediation into a contractual problem involving escrow clauses, support extensions, or a decision to isolate and replace.
In schedule terms, none of that is one workshop. It’s supplier classification by criticality, product-by-product roadmap review, contract renegotiation, joint pilots and interoperability testing across vendors who may compete with each other, change-window alignment, and an escalation path for every supplier who misses.
Sizing your own number
The 120,000 figure belongs to one telecommunications operator with 5G and legacy radio networks, an IP backbone, a large IT estate, operational technology and extensive connected devices. Your number will differ, and it has to be built from your own estate rather than scaled down from someone else’s.
The exact figure isn’t the point. The ratio is. If remediation is only a fifth to two-fifths of the work, and your current estimate contains nothing but remediation, then your estimate is short by roughly the amount you haven’t imagined yet.
Set that against the clocks. NIST’s draft transition guidance, IR 8547, flags quantum-vulnerable mechanisms for deprecation after 2030 and disallowance after 2035. The UK’s National Cyber Security Centre asks for discovery complete by 2028, high-priority systems migrated by 2031, and everything finished by 2035. The EU’s coordinated roadmap asks member states to begin by the end of 2026 and to secure high-risk systems by 2030. Australia’s Signals Directorate set 2030 for the whole transition.
Then apply the arithmetic that predates all of it. If the years your data must stay confidential, plus the years your migration will take, exceed the years until a cryptographically relevant quantum computer exists, you are already late. That’s Mosca’s inequality, and for most large enterprises it already holds. It’s also why harvest now, decrypt later – an adversary recording encrypted traffic today to open it once the capability arrives – makes waiting a decision rather than a deferral.
Six questions that resize an estimate in an afternoon
We put these to sponsors before anyone argues about a number, and every honest answer makes the estimate larger.
- Does the inventory cover IT, operational technology, cloud and the build pipeline, and does it record protocol, library, key and certificate detail? A list of servers is not a cryptographic inventory. A cryptographic bill of materials, or CBOM, is the structured version, and the OWASP CycloneDX format now standardized as ECMA-424 defines what belongs in one.
- Where is automated discovery blind? Embedded cryptography inside vendor products generally won’t be found by scanning, which means an attestation workflow with each supplier.
- For each service, is the strategy upgrade in place, replatform, replace, or compensate with a gateway or segmentation, and who is allowed to choose which? Without written rules, every team relitigates the architecture.
- Which vendor roadmaps sit on the critical path, and what contract language obliges delivery dates, test participation and upgrade rights?
- What does hybrid mean here, where will it be used, and how does it end? RFC 9794 gives shared terminology for combining post-quantum and traditional algorithms. Hybrid operation adds testing and configuration overhead rather than removing it, and the classical component needs a retirement plan of its own.
- What gets reported quarterly, and would it survive an auditor? Coverage, completion by criticality tier, residual exposure and supplier readiness, with evidence behind each.
If a plan answers those concretely, the task count goes up. That’s the sign it’s real.
The capability behind the number
Most of the sector is running pilots. Assessment work is widespread, and governance mature enough to carry a decade of recurring obligations is not. A pilot on one VPN gateway and a 120,000-task program are different activities, and the distance between them is filled with people who can build a work breakdown structure, read a supplier roadmap critically, and tell a board what coverage confidence actually means.
That capability is the constraint, and it can’t be hired at peak in year four. Discovery leads, PKI and key management engineers, application and protocol specialists, procurement and risk staff who understand what to demand of a supplier: most of these skills can be built from people you already employ, given a mandate and a curriculum, and none of them require quantum physics.
For the methodology behind sequencing and wave planning, pqcframework.org sets out the migration approach in full. For the engineering depth beneath any of the sections above, PostQuantum.com is where this analysis originates. And if the gap you’re looking at is people rather than plan, Quantum Academy runs the certification programs that prepare the teams who have to build these schedules and the executives who have to fund them.