Boards asked to fund a post-quantum programme reasonably want to know why now, given that the threat is a machine nobody has built yet. The usual answer involves cryptographic detail that does not help the decision. There is a simpler framing, and it has been the standard one in the field for years.
The three numbers
Michele Mosca framed the question as a comparison between three quantities. Two of them are entirely within your organisation, and you can estimate both this quarter.
- X, the number of years your data must stay confidential after it is created
- Y, the number of years your organisation needs to complete its migration
- Z, the number of years before a cryptographically relevant quantum computer exists
If X plus Y is greater than Z, you are already exposed. Data you create today will still be sensitive at the point it can be decrypted.
Why the uncertain number matters least
Z is the number everyone argues about, and it is the one you cannot influence. It is also, for most organisations, not the one that decides the answer.
Consider a health insurer. Records stay sensitive for the lifetime of the patient, so X is measured in decades. A migration across a large regulated estate, with appliances and third parties in scope, is realistically five to ten years, so Y is large too. At that point X plus Y exceeds any credible estimate of Z, and the argument about whether Z is ten years or twenty-five becomes irrelevant to the decision.
The inverse is equally useful. A retailer whose most sensitive data is a session token with a lifetime of hours has an X near zero. Their exposure is driven almost entirely by Y, which is a delivery problem rather than a cryptographic one.
What this changes about the plan
Framing exposure this way moves the conversation away from a single enterprise-wide deadline, which is always either too aggressive for the hard systems or too relaxed for the exposed ones.
- 01Classify data by sensitivity lifetime rather than by the usual confidentiality tiers. This is the X input, and it is usually the missing one.
- 02Estimate Y per system rather than for the organisation. A modern service behind a load balancer and a mainframe integration do not share a migration timeline.
- 03Rank systems by X plus Y. That ordering, not a blanket deadline, is the roadmap.
- 04Treat harvestable traffic as the first priority. Data crossing a network today can be captured today.
The honest caveats
Z is an estimate, and anyone presenting it as a date is overreaching. The right way to present it to a board is as a range with the source named, revisited annually, rather than as a fact.
Y is also routinely underestimated, usually by a factor of two or more, because the estimate is made before the inventory exists. That is an argument for building the inventory first and the timeline second, not for delaying both.