PQC Explained: The Three Timelines That Decide Quantum Risk

Assessing quantum risk using three timelines

A quantum risk assessment compares three periods: how long data must remain confidential, how long cryptographic migration will take, and how long until a cryptographically relevant quantum computer exists. Where the first two added together exceed the third, exposure has already begun and the organisation is late rather than early.

What is a quantum risk assessment?

A quantum risk assessment is a structured calculation that establishes whether an organisation's cryptographic migration will complete before its data becomes readable by an adversary holding a quantum computer. It is a planning instrument, not a forecast of quantum computing progress.

The method derives from work by Michele Mosca at the University of Waterloo and is usually expressed as an inequality. If the confidentiality lifetime of the data, plus the time required to migrate the systems protecting it, is greater than the time remaining until a cryptographically relevant quantum computer (CRQC) exists, the organisation is already exposed. The value of the method is that it converts an unbounded question about quantum physics into three quantities that a security team can actually estimate.

Two of the three timelines are internal and measurable. Only the third is uncertain. That distribution matters, because it means most of the assessment is within the organisation's control and can be completed without resolving any debate about qubit counts.

The three timelines that determine quantum risk

Timeline X: required confidentiality lifetime

Timeline X is the period for which data must remain unreadable, measured from the point at which it is transmitted or stored. It is set by regulation, contract, and the practical sensitivity of the information, not by system retention policy.

Patient records, personnel security clearances, defence design data, adoption records, and long-term financial instruments routinely carry confidentiality requirements of twenty to a hundred years. Session data from a public website may carry none. The distinction is material because encrypted traffic captured today can be stored indefinitely and decrypted later, which is the harvest now, decrypt later threat model. Any data with a long X value is exposed the moment it crosses a network protected by RSA or elliptic curve key exchange.

Timeline Y: cryptographic migration time

Timeline Y is the elapsed time between starting a migration and completing it across the estate, including systems the organisation does not directly control. It covers discovery, planning, procurement, testing, deployment, validation, and the decommissioning of quantum-vulnerable algorithms.

Y is the timeline organisations estimate worst. It is not the time to enable a post-quantum cipher suite on a load balancer. It is the time to reach a state where no quantum-vulnerable key remains trusted anywhere in the estate, including hardware roots of trust, embedded devices, code signing infrastructure, and third-party interfaces.

Timeline Z: time until a CRQC exists

Timeline Z is the interval between now and the existence of a quantum computer capable of running Shor's algorithm at the scale required to recover RSA and elliptic curve private keys. It is the only genuinely unknown quantity in the assessment.

Z should be treated as a distribution rather than a date, and it should be treated as capable of contracting. It has contracted more than once. Assessments that fix Z at a single confident value are not risk assessments; they are assumptions with arithmetic attached.

How to calculate quantum risk exposure

The calculation is performed per data class or per system group, never once for the whole organisation. Aggregating a payments platform with a public marketing site produces a figure that describes neither.

Two observations follow from any completed version of this table. First, exposure is concentrated: most organisations find that a small number of data classes drive nearly all of the risk. Second, the classes that fail the inequality most severely are usually the ones with the longest migration times, because long-lived data tends to sit on long-lived infrastructure.

Why migration time is consistently underestimated

In practice, timeline Y is dominated by discovery and by dependencies, not by cryptographic implementation. Organisations can enumerate their public certificates quickly, because those are visible in certificate transparency logs and existing management platforms. They cannot enumerate cryptography embedded in application code, hardcoded trust stores, appliance firmware, VPN concentrators, industrial controllers or legacy integrations without a deliberate discovery programme.

That programme is frequently harder than it appears, because the documentation cannot be relied upon. On a defence sector health check following a service transition between suppliers, Unsung consultants had to conduct forensic analysis of the PKI platform itself to establish a baseline, because the knowledge transfer and documentation handover from the incumbent had not delivered one. Where an estate has changed hands, been outsourced, or simply run for years without review, discovery means establishing the facts from the systems rather than from the records.

The second constraint is supplier dependency. An organisation cannot migrate a platform its vendor has not upgraded. Where a system is supported under a multi-year contract with a fixed refresh cycle, migration time is set by that cycle rather than by internal capability. This is why the NCSC directs organisations to communicate requirements to suppliers during the discovery phase rather than at the point of migration.

The third constraint is hardware. Roots of trust held in hardware security modules, secure elements, and smartcards may require firmware upgrades, model replacement, or full key ceremony repetition. Devices with a fifteen year service life installed today will still be operating past every published migration deadline.

A defensible Y estimate begins with a cryptographic inventory. Without one, Y is a guess, and an assessment built on a guessed Y produces a conclusion of no evidential value.

What current evidence says about timeline Z

Expert opinion has moved. The Global Risk Institute's Quantum Threat Timeline Report published in March 2026 by Mosca and Piani recorded that between 28 and 49 per cent of surveyed experts assigned a probability greater than 50 per cent to a CRQC existing within ten years.

Platform providers have moved faster than the regulatory schedule. Following algorithmic and error correction advances reported in early 2026, including a substantial improvement to the quantum algorithm for breaking elliptic curve cryptography and revised resource estimates for neutral atom architectures, Cloudflare, Google and Microsoft each brought forward full post-quantum migration targets to 2029. Cloudflare stated explicitly that these developments pulled expectations forward from the 2035 horizon that most national timelines assume.

That divergence is the practical point for a quantum risk assessment. Organisations whose planning assumes Z equals the regulatory deadline are assuming the most optimistic value available, at a moment when the organisations closest to the underlying research are not.

How UK and US deadlines affect quantum risk assessment

Regulatory dates do not set Z. They set the latest defensible completion date for Y, which is a different constraint and is frequently confused with the first.

Working backwards from the NCSC migration timelines, an organisation with a five year Y value that has not begun discovery in 2026 will not complete its highest-priority activities by 2031. The 2028 milestone is therefore the operative date for most UK organisations, not 2035.

How to run a quantum risk assessment

Step one: define the data classes

Group systems by the confidentiality lifetime of the data they protect, not by business unit or platform. Five to ten classes is normally sufficient.

Step two: establish X for each class

Take X from regulatory retention requirements, contractual confidentiality clauses, and the practical sensitivity period of the information. Record the source of each value so the figure can be defended under audit.

Step three: build the cryptographic inventory

Identify the algorithms, key sizes, protocols, certificates and hardware protecting each class. Output this as a cryptographic bill of materials so that it is machine-readable and can be maintained rather than repeated.

Step four: estimate Y from the inventory

Derive Y from observed constraints: supplier roadmaps, refresh cycles, hardware service life, change freeze windows, and testing requirements. Do not derive it from a target date that has already been chosen.

Step five: apply a range for Z

Test the inequality against several values of Z rather than one. A range of five, eight and twelve years is a reasonable starting set, and produces a clear view of which classes fail under every scenario.

Step six: record, prioritise and review

Record the result on the risk register with named ownership, prioritise the classes that fail under the widest range of Z values, and review the assessment annually or whenever a material change to Z is reported.

Common errors in timeline-based risk assessment

The most frequent error is a single organisation-wide calculation. Exposure is not uniform, and an averaged result conceals the classes that require action now.

The second is treating Y as an implementation estimate. Where discovery has not been completed, Y cannot be estimated at all, and the assessment should say so rather than produce a number.

The third is assuming symmetric cryptography is affected in the same way as asymmetric cryptography. It is not. AES-256 and SHA-384 remain appropriate under current analysis, while RSA, ECDSA, ECDH and Diffie-Hellman do not. An assessment that fails to separate the two overstates the scope of the problem and misdirects the budget.

The fourth is omitting authentication. Much early post-quantum work addressed encryption because harvest now, decrypt later was the dominant concern while Z was thought to be distant. A shorter Z raises the priority of signatures, code signing and long-lived credentials, because a forged authentication key grants direct access rather than retrospective disclosure.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services and critical national infrastructure.

We conduct cryptographic discovery and produce the inventory that makes a defensible Y estimate possible, through our PKI health check and cryptographic bill of materials services. We then support prioritisation, target architecture design, and the certificate lifecycle management capability required to execute a migration at the pace the assessment demands. Because we are vendor-neutral, the sequencing we recommend is determined by the assessment, not by a product roadmap.

For the wider context on standards, algorithms and migration approach, see our guide to post-quantum cryptography.