Marin Ivezic
In November 2024, NIST published an initial public draft, IR 8547, setting out how classical public-key cryptography gets retired, and the underlying schedule is already in SP 800-131A Rev. 2: 112-bit-strength algorithms, RSA-2048 among them, are acceptable through 2030 and disallowed from 2031, when the minimum security strength rises to 128 bits. That gives most organisations a date on a calendar. It doesn’t tell them whether the date is comfortable or whether it passed some time ago, and that second question is the one Mosca’s Theorem was built to answer.
The theorem is one line of arithmetic. The answer it produces is usually uncomfortable, and two of the three variables are easy to get wrong on the first pass.
The inequality
Michele Mosca’s formulation compares three timelines:
- X is the confidentiality lifetime of your data. How many years does this information need to stay secret?
- Y is your migration time. How many years will it take to replace the vulnerable cryptography everywhere it runs?
- Z is the time remaining until an adversary can break that cryptography. Some write it as Q, for Q-Day.
If X + Y > Z, you’re late. Data protected today will still need protection at the point where the protection stops working, and the replacement won’t be finished in time.
Written out, the logic is almost dull. Applied to a real estate of systems, it stops being dull, because X and Y are both routinely underestimated and Z is not a number anyone gets to choose.
Estimating X
The first mistake is reading X off a data retention schedule. Retention tells you how long you keep something. X tells you how long its disclosure would still hurt, and the two rarely match.
Health records, sealed legal proceedings, source identities, merger positions, biometric templates and long-lived personal identifiers all carry an X measured in decades. A session token carries an X of minutes. Between those two extremes sit most enterprise systems, and the honest estimate usually comes from the business owner rather than from security.
Signatures behave differently, and this is where the arithmetic gets misread. A signature verified today and never again has an X close to zero, because an adversary with a quantum computer in 2035 gains nothing from forging a 2026 authentication. But a firmware signing key protecting a device that ships in 2028 with a fifteen-year service life needs to be trusted until 2043. The exposure is not in the data, it is in the root of trust, and it inherits the lifespan of the hardware.
So X is not one number. It is a small set of numbers, one per class of asset, and the migration sequence follows from ranking them.
Estimating Y
Y is the only variable you control, and it is the one most often stated as a wish.
A realistic Y has four components, and only the second is a normal engineering project. The first is discovery: building a cryptographic bill of materials, meaning a machine-readable inventory of every algorithm, key, certificate, protocol and library in use, together with where each one runs and what depends on it. Discovery is the component most often left out of the estimate entirely, and it routinely finds cryptography in places nobody had documented.
The second component is the migration of systems you control, where NIST’s standardised algorithms ML-KEM (formerly CRYSTALS-Kyber) and ML-DSA (formerly CRYSTALS-Dilithium) can be deployed on your own schedule. The third is everything gated by a vendor, where your timeline is their roadmap. The fourth is everything gated by hardware, including HSMs, payment terminals, industrial controllers and anything embedded, where replacement follows a refresh cycle that may run seven to ten years and cannot be accelerated by budget alone.
Add those honestly and Y for a large regulated enterprise lands between five and eight years. Stating four because four sounds achievable doesn’t shorten the work, it only moves the shortfall out of view.
Estimating Z
Z is not a prediction, and treating it as one is what stalls most programmes. The Global Risk Institute’s Quantum Threat Timeline report, which Mosca co-authors, gathers expert estimates and publishes them as probability distributions rather than as a date, precisely because no responsible estimate is a date.
For planning purposes there are two versions of Z, and the earlier one governs.
The cryptanalytic Z is when a cryptographically relevant quantum computer actually exists. Nobody knows it, and you probably won’t be told when it happens.
The regulatory Z is when your current cryptography stops being permitted. That one is already written down. NIST’s guidance disallows 112-bit strength, and RSA-2048 with it, from 2031. National security systems under CNSA 2.0 are expected to be fully transitioned by 2033. Sector supervisors, insurers and large enterprise customers are converging on similar horizons, and contract language tends to arrive earlier than regulation.
For most commercial organisations the regulatory Z binds first, and it has the useful property of being defensible in a budget conversation.
A worked example
Take a payments processor running the numbers in 2026.
X. Cardholder data and associated personal identifiers need to stay confidential for ten years. Some fraud-investigation records run longer, so ten is the working figure for the largest class.
Y. Eighteen months for inventory and prioritisation. Three years for internally controlled applications and internal PKI. A further two years for HSM replacement and partner-facing interfaces that follow contract renewal and hardware refresh. Y is six and a half years.
Z. Regulatory disallowance in 2031, which is five years away.
X + Y is 16.5 against a Z of 5. The programme is eleven and a half years under water. Migration completes in 2032, but data encrypted between now and then still needs to hold until 2036 and later, and the protection expires first.
Two levers exist, and neither is Z. X comes down by shortening retention, re-encrypting archives under new keys once the new algorithms are deployed, and separating the records that genuinely need a decade from the ones that were kept out of habit. Y comes down by starting discovery now, running vendor engagement in parallel with internal work rather than after it, and folding cryptographic requirements into hardware refresh cycles that were going to happen anyway.
Neither lever moves quickly, which is the entire argument for pulling them early.
Why the arithmetic isn’t symmetrical
If Y overruns, the usual consequence is a delayed project. For data with a long X, the consequence is different, because of what the industry calls harvest now, decrypt later: an adversary copies encrypted traffic or exfiltrates encrypted archives today, stores them, and decrypts once the capability exists.
Where that has happened, the breach is already complete. Only the disclosure is pending, and no future migration reaches back to protect the copy the adversary is holding. This is the reason X sits inside the inequality at all. Any other risk model would compare migration time to threat arrival and stop there.
The market’s instinct has been to wait for a clearer date before committing budget. On this particular risk that instinct is expensive, because the waiting period is precisely when the harvestable data is being generated.
Turning the number into a programme
Mosca’s Theorem produces a gap, not a plan. Closing the gap needs an inventory you trust, a prioritisation that follows X rather than convenience, and crypto-agility, meaning systems built so that the next algorithm change is a configuration decision rather than a second migration of this size.
Those are teachable skills, and they are the ones we build our post-quantum training around: cryptographic discovery, migration sequencing, vendor assessment, and the governance to keep a multi-year programme funded through the years when nothing visibly breaks. Our programmes are designed for the people who have to own the number once it has been calculated, and you can review the current certification paths at quantumacademy.com/.
For the migration methodology itself, the Post-Quantum Cryptography Migration Framework sets out the phased structure in detail. For deeper technical background on the threat model behind Z, PostQuantum.com remains the reference we point people to.
Run the arithmetic first. It’s the cheapest hour in the whole programme, and it tells you whether the rest of it is a plan or a race.