Mosca’s Theorem
Mosca’s theorem is the timing rule that turns “quantum will break RSA someday” into your own deadline. It says that if the time your data must stay secret (X), plus the time it takes you to migrate (Y), is greater than the time until the cryptography can be broken (Z), then you’re already too late. In one line of arithmetic, X + Y > Z, it converts an abstract industry timeline into a decision you can act on today.
The short version:
- The rule is
X + Y > Z. If it’s true, you should already be moving. - X = how long the data or trust must stay secure. Y = how long migration actually takes, almost always underestimated. Z = how long until a capable quantum computer arrives, genuinely uncertain.
- It works because Z is uncertain, not in spite of it. You don’t need to predict the arrival date to know which assets are too important to gamble on.
- It reframes the whole conversation away from “when do quantum computers arrive?” and toward “how long do we need this protected, and how long will migrating take?”
The trap it disarms is the natural one: “we don’t need to migrate today, because the attack isn’t possible today.” That misses the overlap. If the data can be collected now, will still matter later, and takes years to re-protect, then future compromise is being locked in by present inaction.
What is the X + Y > Z rule?
The formula is X + Y > Z. Read it as a runway check: the thing has to stay secure for X years, migration takes Y years, and the protection may fall in Z years. If the first two together exceed the third, you’re operating inside the danger zone right now.
Its real power is that it captures delayed regret. The mistake it exposes is judging risk only by an attacker’s current capability, instead of by the overlap between how long your data stays sensitive and how long your migration drags. A quantum computer doesn’t have to exist today for you to already be late.
Two things make it robust rather than a guessing game:
- “Breakable” (Z) is tied to the relevant adversary and use case, not a single global doomsday. Z can mean the point where Shor’s algorithm becomes practical against the specific public-key systems you run, or where a class of data becomes worth decrypting, or where an attacker can forge a trust relationship rather than just decrypt.
- The theorem doesn’t require prophecy. Under uncertainty it still answers the useful questions: which assets are too important to gamble on, which migrations are so slow that waiting is irresponsible, and which trust relationships are too central to defer.
What do X, Y, and Z mean in practice?
The theorem only bites once you translate X, Y, and Z into real facts about a real environment.
| Variable | What it measures | Why it gets underestimated |
|---|---|---|
| X | How long the data or trust must stay secure | Confused with system lifetime, contract length, or retention |
| Y | How long migration actually takes | Cryptography is buried in products, vendors, firmware, and legacy |
| Z | How long until the cryptography can be broken | Genuinely uncertain, so it gets hand-waved away |
X, the required security lifetime. This is the most misread variable. X measures how long the information or trust relationship must stay secure, which people routinely confuse with how long the system exists, how long the contract runs, or how long the cryptography is deployed. Health records, legal strategy, defense data, trade secrets, long-relevance personal data, roots of trust, firmware anchors, and signed audit records all carry high X. Ephemeral telemetry and short-lived tokens with no retained value carry low X. The forcing question for a leader is simply: how long must this stay confidential, and how long must this signature stay trustworthy?
Y, the migration time. Almost always underestimated, because it’s far more than flipping a setting. Y includes inventory, dependency mapping, standards selection, vendor-support lag, procurement cycles, engineering effort, rollout sequencing, trust-store updates, validator upgrades, hardware refresh, re-encryption or re-signing where needed, and governance changes. Cryptography is buried deep in products, appliances, firmware, partner dependencies, and managed services, so Y in a real estate is often years longer than executives expect. Y is usually the variable that reveals “we can wait” to be false.
Z, the time until break. The most uncertain, but not the least useful. Estimate it from adversary sophistication, the value of the target, sector profile, data sensitivity, public scientific progress, and whether the concern is confidentiality decryption or trust forgery. The honest way to handle its uncertainty is to run several values: a conservative Z (earlier arrival), a moderate Z (a midpoint), and an optimistic Z (later). Even with Z unknown, some assets clearly fall into urgent territory under any of the three, and those are the ones that don’t need a resolved timeline to justify moving. The Quantum Threat Timeline gathers the expert-survey estimates that feed these bands, and the arrival itself is a CRQC question, a global technological event that’s exogenous to any one organization’s choices.
How do you reason with Mosca’s theorem?
Use the theorem as a triage lens, applied to asset classes rather than to individual algorithms. Sort the environment by asking which data or trust relationships have the longest required lifetime, which systems will be hardest to migrate, and which cryptographic dependencies are likely to become unsafe first. Scoring by category, public-facing transport, internal service identity, archives and backups, PKI trust anchors, code and firmware signing, identity federation, long-lived secrets, is far more useful than listing which systems use ECC.
It’s also the cleanest translation device from cryptography into executive urgency. Leaders respond to “will this still matter in 10 years, how long would replacing it take, and are we already behind if we wait three more years?” far better than to “do you use ECC?” The theorem gives a disciplined middle path between the two failure modes: not the underreaction of “quantum is too far away to matter,” and not the overreaction of “everything is broken right now,” but the accurate “some things are urgent, and urgency depends on data lifetime, migration difficulty, and adversary timeline.”
How does Mosca’s theorem relate to the other risk models?
Mosca handles timing. It combines with the models that handle kind and consequence.
- With HNDL, this is where it’s most famous. HNDL exposure exists when data can be captured now, will still matter later, and depends on public-key protection that may fall. Mosca decides whether that exposure is urgent: if confidentiality lifetime is long, migration is long, and the break horizon is shorter than both combined, HNDL migration starts now.
- With Non-HNDL, the same timing logic applies to trust rather than secrecy. A certificate authority whose trust must stay valid for years, firmware signatures that must keep verifying, long-lived code-signing trust: the issue is delayed trust failure, but
X + Y > Zgoverns it identically. - With blast radius, Mosca tells you when and blast radius tells you how bad. Together they decide what lands in the first phase: the theorem reveals where long-lived sensitivity overlaps with slow migration, and blast radius sizes the damage there. A mature roadmap uses both.
Common misconceptions
- “Mosca’s theorem predicts when quantum computers arrive.” No. It’s a timing framework, not a forecast engine. Z is an input, and an uncertain one.
- “If Z is uncertain, the theorem is useless.” The opposite. It’s built for prioritization under uncertainty, which is why the conservative/moderate/optimistic bands matter.
- “It only applies to confidentiality.” No. It applies just as well to long-lived trust and authenticity.
- “It means every system is urgent.” No. It separates the urgent from the deferrable.
- “X is just data retention.” No. X is the required security lifetime, which can run longer or shorter than raw storage retention.
- “Y is just a technical migration.” No. Y includes governance, rollout, vendor coordination, validation, hardware, and ecosystem lag.
Everything here is the map, given freely. When your team needs X, Y, and Z mapped to your own systems and turned into a defensible sequence, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.