The Four Clocks of PQC Migration — and Why They Don't Agree
At a glance
- Quantum exposure is not a date. It accumulates in the gaps between timelines that were never synchronised.
- Four clocks drive PQC migration, and none of them agree: regulator, adversary, vendor, and your own execution.
- Gross progress is not net progress — are you retiring cryptographic debt faster than you create it?
- Prioritise the corridors where traffic aggregates, not individual assets. And build agility while you do it.
A few days ago, the CISO of a US financial institution described how he frames two threats for his team. Frontier AI-driven attacks are like carpet bombing. But looming right behind them, he cautioned, is something closer to a nuclear strike.
The metaphor vividly captures the scale of concern. The caveat is the timing: quantum exposure is not a moment in time. It accumulates quietly, over years, in the gaps between timelines that were never synchronised to begin with.
The quickly shiftingtimeframe to a cryptographically relevant quantum computer — often framed as“Q-Day” — still matters for risk modelling. But this is no longer about gazinginto a crystal ball, and it no longer determines whether to act.
The forecast moved. What it's for hasn't.
Those working on this in 2019 could already see the fault lines: cryptographic change would not scale manually, supplier dependency would cut both ways, and enterprise coordination would be harder than it looked. Thirty years of relative cryptographic calm had masked how tightly the architecture had become coupled.
This transition will not be the last — and the scenario most IT defence teams would rather not contemplate is the next one arriving before this one is complete. That is where tightly coupled architecture starts charging compound interest.
What we could not have predicted was how quickly the numbers themselves would move. In 2019, a leading estimate put factoring RSA-2048 at around 20 million noisy physical qubits. By 2025 it was below one million; recent work puts it below 100,000 under stated assumptions. Signatures sit on their own track, and that number moved too: colleagues at IonQ published a fully compiled, end-to-end estimate this month putting a discrete-logarithm attack on secp256k1 — a 256-bit elliptic curve — at 25.7 days per attempt on a machine of approximately 19,400 physical qubits in the architecture modelled. At the same time, hardware roadmaps — including ours — are accelerating towards hundreds of thousands and millions of physical qubits before the end of the decade. A resource estimate is still not a schedule. But it does make today's number a poor anchor for a multi-year security strategy. Policy is increasingly reflecting that same shift from prediction to migration planning.
Migration takes longer than the deadlines assume
Across the programmes I see, there is now broad acceptance that migration takes long enough to put many large organisations under real pressure as recent compliance timelines approach. SHA-1 is a useful reminder: its retirement stretched across more than a decade of standards, products and protocols — and that was a far simpler change. Meanwhile, the ongoing exposure keeps raising eyebrows in boardrooms. Rightly so.
Four clocks, and none of them agree
It may not come as a surprise that programme maturity varies widely. Some organisations are still scoping how to build a cryptographic bill of materials; others are already deep into harvest-now-decrypt-later mitigation. The difference often comes down to which clock they are answering. There are at least four: the regulator clock, the adversary clock, the vendor clock and the organisation's own execution clock.
The regulator clock is becoming concrete. Alongside NIST's 2030/2035 transition timeline, US Executive Order 14412 set December 31, 2030 for post-quantum key establishment and December 31, 2031 for digital signatures across specified federal high-value and high-impact systems. The Monetary Authority of Singapore signalled in July that supervisory expectations for the financial sector are coming too. This will accelerate programmes that needed a forcing function — and compress work that does not safely compress. Most of us have watched that trade-off before.
The adversary clock has already started. Encrypted information can be collected today and retained for future cryptanalysis — a threat the Executive Order explicitly recognises, with the key-establishment deadline set ahead of signatures. Trading strategies, client relationships, research IP and operational telemetry hold value for years, and datasets aggregated over time can hold more still. Which raises a question few boards have answered out loud: how much HNDL exposure is the organisation prepared to tolerate while the infrastructure migrates? A deadline says nothing about what risk builds up before it.
Starting the first cryptographic workstream should not mean postponing the second — HNDL makes confidentiality and key establishment more urgent, while the forgery risk to signatures, certificates and roots of trust, increasingly described as Trust Now, Forge Later, can take even longer to unwind.
The vendor clock presents a different challenge. Major suppliers are moving, though PQC support arrives in stages — different product families, releases, management interfaces, hardware generations. Credibility is not the issue here, and it is worth saying so plainly. At the same time, a large enterprise depends on many suppliers at once, and ends up moving at the speed of the slowest unless the architecture decouples cryptographic change from the infrastructure lifecycle. This is where cryptographic agility starts to matter. Hold that thought.
The institutional execution clock is the organisation's own capacity to absorb all that: talent and resourcing, procurement, testing, integration, change control and deployment across live production. Look at your own historical data for realistic timelines per layer. It may not be what you'd been hoping for.
And even this is not really one clock. Key establishment, TLS, PKI, machine identity, code and firmware signing, and hardware roots of trust each carry different technical dependencies, but also sit with different owners across network, application, identity, software supply chain, hardware, OT and procurement teams.
Gross progress vs. net progress
This is the question none of us particularly enjoys: are we retiring cryptographic debt faster than we are creating it?
Measuring gross migration progress with confidence is already hard enough. What easily gets overlooked is the counterflow of new vulnerable dependencies entering through development, procurement, infrastructure and other change. Microsoft made an adjacent point in April: cryptographic inventory has to become an operating model, not a one-time project, because the environment never stops changing.
The arithmetic that follows:
NET CRYPTOGRAPHIC PROGRESS vulnerable dependencies retired − new vulnerable dependencies introduced
Measuring either side of that equation continuously takes governance tooling most estates do not yet have.
Knowing whether exposure is actually declining is one part of the problem; deciding where to reduce it first is another.
Where to reduce exposure first
The useful unit of prioritisation is often the data flow or dependency and where risk can be reduced most effectively, not the individual asset. Much of today's migration conversation converges on TLS stacks, applications and certificates — the most visible artefacts of the estate. However, from a data-risk perspective, another set of candidates keeps surfacing in my conversations with CISOs: WAN backbones, data-centre interconnects and private-cloud paths that aggregate traffic from hundreds or thousands of applications.
Protecting a small number of these corridors can reduce exposure across a much larger estate while the broader migration continues underneath.
Where agility changes the equation
Now that thought. The gap between vendor timelines, compounded by the internal execution clock, is exactly why cryptographic agility matters. If the guidance shifted the quarter after you had upgraded much of your network estate, how much would move with a policy change — and how much would need another multi-year forklift? That is a question many organisations are only now beginning to answer at this scale.NIST's work on cryptographic agility makes the broader point: advances in computing, cryptanalysis and standards will continue to require cryptographic change.
This transition will not be the last — and the scenario most IT defence teams would rather not contemplate is the next one arriving before this one is complete. NIST's work on cryptographic agility makes the broader point: advances in computing, cryptanalysis and standards will continue to require cryptographic change.
It is therefore no surprise that, among organisations that started early, I increasingly see a dual objective — reduce exposure ahead of the natural estate refresh, while building the architectural agility.
In core networks, for example, this translates into separating quantum-safe key delivery from the data plane lifecycle. At IonQ, as part of our broader Quantum Security Posture Management strategy, we embraced this architecture early in Clarion KX, our production key-management platform. It sits above the transport layer and hands quantum-safe key material out-of-band to encryptors already in place, without replacing them or altering the data path. The cryptographic approach stays flexible, with NIST-standardised ML-KEM (FIPS 203) for key establishment, certified quantum-generated entropy, and QKD on the corridors where it matters.
What I'll dig into next
I will stay with the practical side of this transition in the next pieces: why interoperability and ecosystem readiness matter, how governance tooling makes net progress measurable, and how those decisions look across different infrastructure environments and industries.
Simon Patkovic
Field Quantum Security Officer IonQ
Simon has worked in quantum-safe security since 2019, including at ISARA, where he helped shape early cryptographic agility concepts, and with ID Quantique from 2022. He previously spent over a decade at BlackBerry as VP of Security Advisory and has contributed to NATO's Industry Advisory Group on quantum technologies. Before moving to the vendor side, he spent seven years as a security architect in financial services.
Frequently asked questions
Do we need to know when a quantum computer will break RSA before we start migrating?
No. The timeframe still matters for risk modelling, but it no longer determines whether to act. Estimates for factoring RSA-2048 have fallen from around 20 million noisy physical qubits in 2019 to below 100,000 in recent work, while hardware roadmaps accelerate towards hundreds of thousands of physical qubits before the end of the decade. None of that gives us a date — which is rather the point. Migration takes long enough that the decision to start cannot wait for the forecast to settle.
What is harvest now, decrypt later — and what can we do about it today?
Harvest-now-decrypt-later (HNDL) is the collection and retention of encrypted information today for cryptanalysis later. Executive Order 14412 recognises it explicitly, setting the key-establishment deadline ahead of signatures. Anything with a long confidentiality life is exposed now: trading strategies, client relationships, research IP, operational telemetry — and datasets aggregated over time can hold more value still. The practical first move is to reduce exposure where traffic aggregates rather than working asset by asset, and to keep the signature workstream running in parallel, since forgery risk — Trust Now, Forge Later — takes even longer to unwind.
What does cryptographic agility mean in practice?
Being able to change cryptography without changing the infrastructure around it. The test is a simple one: if the guidance shifted the quarter after you had upgraded much of your network estate, how much would move with a policy change, and how much would need another multi-year forklift? In core networks, agility usually means separating quantum-safe key delivery from the data plane lifecycle — key material handed out-of-band to encryptors already in place, so the cryptographic approach stays flexible as standards continue to move.
A Note Regarding Forward-Looking Statements
This document contains forward-looking statements. All statements contained in this document other than statements of historical fact are forward-looking statements, including statements regarding roadmaps, milestones, product timelines, and fault-tolerance objectives. In some cases, you can identify these statements by forward-looking words such as “pathway,” “build,” “plan,” “believe,” “estimate,” “should,” “could,” “would,” “will,” and other similar expressions. These statements are only predictions based on our expectations and projections about future events as of the date of this document and are subject to a number of risks, uncertainties and assumptions that may prove incorrect, any of which could cause actual results to differ materially from those expressed or implied by such statements, including, among others, those described under the heading “Risk Factors” in our Annual Report on Form 10-K for the year ended December 31, 2025 and our Quarterly Report on Form 10-Q for the quarter ended June 30, 2026 filed with the Securities and Exchange Commission. New risks emerge from time to time, and it is not possible for our management to predict all risks, nor can management assess the impact of all factors on our business or the extent to which any factor, or combination of factors, may cause actual results to differ materially from those contained in any forward-looking statement we make. Investors are cautioned not to place undue reliance on any such forward-looking statements, which speak only as of the date they are made. Except as otherwise required by law, we undertake no obligation to update any forward-looking statement, whether as a result of new information, future events or otherwise.
