The migration window, with the arithmetic

Most post-quantum urgency arguments are adjectives. This one is arithmetic. The Mosca inequality reduces the question to three durations, two of which you already know, and it produces an answer that is either comfortable or uncomfortable without anybody needing to predict a date. Below is the inequality, the definitions, and three worked examples with every assumed input labelled so you can replace them.

#The inequality

Michele Mosca’s formulation asks how long your data must stay secret, how long your migration will take, and how long you have before an adversary can break the cryptography you are using now. If the first two added together exceed the third, the migration should already be under way.

X  =  years this data must remain confidential
Y  =  years required to complete the migration
Z  =  years until a capable adversary plausibly exists

if  (X + Y)  >  Z      you are already late, by (X + Y - Z) years
if  (X + Y)  <  Z      you have (Z - X - Y) years of slack
if  (X + Y)  =  Z      you have no margin for slippage

The structure is what makes it useful. X and Y are properties of your organisation, and you can establish both without any view on quantum computing. Z is the uncertain term, and the inequality lets you test your position across a range of values for Z rather than committing to one.

#Defining each term without hand-waving

X — secrecy horizon

The number of years from today during which disclosure of this data would still cause harm. Take it from statutory retention rules, contractual confidentiality terms, clinical duty of care, or the working life of the asset being protected. Not an average across the estate: compute it per data flow, because a payments log and a clinical archive are not the same problem.

Y — migration duration

The number of years from a funded start to the point where the last long-horizon flow is protected by quantum-resistant key establishment. Include discovery, vendor and hardware dependencies, certificate and PKI rework, testing, performance validation, change windows and the systems you do not control. Most estimates are wrong because they measure the first pilot rather than the last laggard.

Z — time to capability

The number of years until an adversary with the resources you actually face can break the asymmetric cryptography in question. Treat this as a range drawn from published expert surveys and standards-body deprecation schedules, never as a point estimate, and never as your own forecast.

#Three worked examples

Each example below states its inputs explicitly and labels them as assumptions. None of them is a prediction. They exist to show the shape of the answer, and to be overwritten with your own figures.

#Example A — a life insurer

X + Y is 35, against a Z of 15. The insurer is late by 20 years on those records. The conclusion does not change if you double Z to 30: X + Y still exceeds it. That robustness is the point. For a secrecy horizon of 30 years, the answer is the same across every plausible value of Z, which is why an insurer does not need a date to justify starting.

#Example B — a business-to-business SaaS platform

For operational traffic, X + Y is 4 against a Z of 15, which leaves 11 years of slack. For the signing anchor, X + Y is 14 against the same Z, leaving one year. Two conclusions from one organisation: the day-to-day traffic is genuinely not urgent, and the signing infrastructure is. This is the most common real result, and it is invisible to any assessment that computes a single number for the whole estate.

#Example C — a government records archive

X + Y is 57 against a Z of 20. Late by 37 years, using the most favourable Z in this article. When the arithmetic produces a number like that, the useful response is not a faster migration programme. It is to accept that some material already recorded in transit cannot be protected retrospectively, and to concentrate on bounding future exposure and on which archives should never have crossed a network in the first place.

#Why we do not publish a date

A single countdown to a named day is a marketing device. It converts a genuine range of expert opinion into a false precision that is easy to put in a hero banner and impossible to defend. It also fails in both directions: if the date passes uneventfully the whole argument looks discredited, and if capability arrives earlier everyone who planned against the date is unprotected.

• Expert surveys report distributions, with wide spreads and substantial probability mass at both ends. A distribution is not a date, and collapsing it to one discards the information that matters.
• Estimates move as engineering and cryptanalysis advance. A figure published three years ago should not be quoted as current.
• Adversary capability is not a single global event. A well-resourced state service and an opportunistic criminal group reach the same capability at different times, so your Z depends on who you are defending against.
• The dates that are real are policy dates, not physics dates. NIST published FIPS 203, 204 and 205 in August 2024, the NSA has published a CNSA 2.0 transition timeline, and EU DORA has applied since 17 January 2025. Those are commitments you can plan against.

The Quantum Window on this site measures elapsed time against published standards deadlines. It is a progress bar on a policy schedule, not a prediction of when hardware arrives, and we label it that way deliberately. Regulatory detail sits in CNSA 2.0 and the federal timeline and DORA and financial-sector obligations.

#Using the result

The inequality tells you whether to start and roughly how hard to push. It does not tell you what to do first. That requires knowing which assets carry the long-horizon flows, and how confident the classification is.

1. 01Compute X per data flow, not per organisation. Publish the source of each figure so it can be challenged.
2. 02Derive Y from a completed discovery pass rather than an assumed inventory. See How discovery finds cryptography.
3. 03Test Z across a range, including a value you consider pessimistic and one you consider optimistic. Record which flows change verdict between them, because those are the genuinely uncertain cases.
4. 04Rank the flows where the inequality already fails, then sequence them using Sequencing a migration.
5. 05Re-run the whole calculation annually. X shrinks with the calendar, Y shrinks as work completes, and Z moves as the literature does.