The inequality in one line
Let X be the number of years your data must stay confidential, Y the number of years it takes you to migrate to post-quantum cryptography, and Z the number of years until a quantum computer can break today's public-key crypto. If X + Y > Z, you have a problem: your data is still sensitive at the moment it becomes decryptable. Mosca's theorem is simply that comparison, applied per data class.
Michele Mosca's inequality is the precise, quantitative statement of the harvest-now-decrypt-later argument. Where that threat model tells you an adversary is recording ciphertext today to decrypt later, Mosca's theorem tells you exactly which of your secrets that actually endangers — and, just as usefully, which ones it does not. It turns a vague fear about future quantum computers into a decision you can make now, system by system.
The three terms
The whole model is three time spans measured from today. Get each one roughly right and the comparison does the rest.
- **X — confidentiality lifetime.** How long the data must remain secret. This comes straight from data classification and retention: health records, state secrets, biometric identifiers, and long-term contracts stay sensitive for decades; an ephemeral session token is sensitive for effectively zero years.
- **Y — migration time.** How long it realistically takes your organization to move to post-quantum cryptography end to end — find every use of vulnerable crypto, plan the change, and roll it out without breaking production. For a real organization this is measured in years, not weeks.
- **Z — time to a quantum break.** How long until a cryptographically-relevant quantum computer can break RSA and elliptic-curve crypto. Nobody knows Z precisely, which is exactly the point: you plan against a range and against policy deadlines, not a single date.
Estimating each term
X and Y you own; Z you have to bound from the outside. For X, segment by data class rather than picking one number for the whole organization — the same TLS endpoint may carry both decade-long records and throwaway telemetry. For Y, be honest: the number that matters is elapsed calendar time to reach substantial coverage, including discovery and testing, not the effort of a single upgrade.
Z is genuinely uncertain, so anchor it to conservative external references rather than optimism. Expert surveys such as the Global Risk Institute's Quantum Threat Timeline put a non-trivial probability on a break within the next decade or two, and regulators have already encoded that: the NIST migration timeline (IR 8547) deprecates classical public-key crypto after 2030 and disallows it after 2035, and CNSA 2.0 targets 2033. Treat those deadlines as an effective upper bound on a safe Z — if your X + Y crosses them, the policy has already decided for you.
Don't treat Z as knowable — and don't apply one X to everything
The trap is waiting for Z to become certain before acting. Because the harvesting is happening now and Y is large, the decision has to be made while Z is still a range — by the time Z is known, the exposure window has already closed on your longest-lived data. The second trap is using a single organization-wide X; segment by data class, or you will either over-invest protecting throwaway data or under-protect the records that matter for decades.
Turning it into a priority
Compute X + Y − Z for each data class. The systems where X + Y most exceeds Z are the ones whose secrets are guaranteed to be decryptable while still sensitive — they migrate first. Systems where X is near zero (ephemeral, low-value data) can wait, because even a near-term Z leaves nothing worth harvesting. This ranking is only as good as your knowledge of where vulnerable crypto lives, which is why it depends on a cryptographic inventory to enumerate every algorithm and its data class, and why its output feeds directly into a migration roadmap sequenced by exposure. For a worked walkthrough of the same maths, see our post on Mosca's theorem.
How quantakrypto helps
Mosca's theorem is easy to state and hard to instrument: the numbers only mean something once you know which systems carry which data under which algorithms. Our audit produces the cryptographic inventory and the per-class X, Y, and Z estimates that make the inequality concrete; our migration work turns the ranking into a sequenced rollout that shrinks Y before Z runs out; and our training makes this reasoning part of how your teams classify data and design systems in the first place. Start with the inventory — you cannot compute X + Y > Z for crypto you have not found.