Mosca's Theorem Explained: How to Calculate Your Organization's Quantum Risk Deadline

If you only learn one equation about the quantum threat, make it this one:

X + Y > Z

It is called Mosca's Theorem, after cryptographer Michele Mosca, and it is the fastest way to turn an abstract worry — "quantum computers will one day break our encryption" — into a concrete, defensible decision about whether you need to act now. This guide explains each variable, walks through worked examples, and shows where IQCDL fits into closing the gap.

The one-line version

Mosca's Theorem says you have a problem today if:

• X — the number of years your data must stay secret, plus
• Y — the number of years it will take you to migrate your systems to quantum-safe cryptography, is greater than
• Z — the number of years until a cryptographically relevant quantum computer (CRQC) exists.

In plain English: if it will take you longer to become quantum-safe than the time you have left before quantum computers can read your data — and your data still needs to be secret by then — you are already behind.

The three variables, in detail

X — the shelf-life of your secrets

This is how long a given class of data must remain confidential. It varies enormously:

• Session tokens and short-lived API keys: hours to days.
• Customer financial records and health data: often 7–10 years for regulatory reasons.
• Root keys in a PKI, state secrets, long-term contracts, intellectual property: 10–30+ years.

The critical insight is the "Harvest Now, Decrypt Later" (HNDL) attack. Adversaries can capture your encrypted traffic today and simply store it until a quantum computer can decrypt it. That means data with a long X is already at risk right now, even though no quantum computer has broken it yet.

Y — your migration time

This is the realistic, end-to-end time to replace vulnerable cryptography across your estate: discovery (building a Cryptographic Bill of Materials, or CBOM), algorithm selection, vendor coordination, testing, phased rollout, and decommissioning. For a large enterprise this is rarely a single budget cycle — credible estimates routinely run 5–10+ years for a full migration across applications, devices, and third-party dependencies. You cannot swap cryptographic infrastructure overnight.

Z — the quantum threat horizon

This is the hardest variable to pin down because it is a forecast, not a measurement. Estimates for a cryptographically relevant quantum computer vary across the security community, with many credible expert surveys clustering around the 2030–2035 window and meaningful probability earlier. Because Z is uncertain, prudent risk management treats it as a range and plans against the earlier end — not the comfortable one.

IQCDL position: Treat Z as a planning range, not a fixed date. The responsible move is to make X + Y small enough that you are safe even if Z arrives early.

Worked examples

Example 1 — A bank's customer records

• X = 10 years (regulatory retention + confidentiality)
• Y = 6 years (large, regulated estate)
• Z = 8 years (planning against the earlier end of the horizon)

X + Y = 16, which is greater than Z = 8. Result: action is overdue. The bank should already be inventorying cryptography and piloting post-quantum algorithms.

Example 2 — A startup's marketing site

• X = 1 year (no long-lived secrets)
• Y = 1 year (small, modern, crypto-agile stack)
• Z = 8 years

X + Y = 2, which is less than Z = 8. Result: lower urgency — but the startup should still adopt crypto-agility so Y stays small as it grows.

The lesson: the same Z produces completely different deadlines depending on your X and Y. Mosca's Theorem is not a doomsday clock; it is a per-data-class triage tool.

What "becoming quantum-safe" actually involves

The destination is defined by real standards. In August 2024, NIST finalized its first three post-quantum cryptography standards:

• FIPS 203 — ML-KEM (based on CRYSTALS-Kyber), for key encapsulation.
• FIPS 204 — ML-DSA (based on CRYSTALS-Dilithium), for digital signatures.
• FIPS 205 — SLH-DSA (based on SPHINCS+), a hash-based signature alternative.

Migrating means moving your key exchange and signatures onto these algorithms — usually via hybrid schemes first (classical + PQC together) so you lose nothing if one side has a flaw — and building crypto-agility so you can swap algorithms again later without another multi-year project.

A five-step way to shrink X + Y

1. Inventory (CBOM). You cannot protect cryptography you cannot see. Catalogue every algorithm, key, certificate, and protocol.
2. Classify by X. Tag each data class with its required secrecy lifetime, then sort by HNDL exposure.
3. Pilot PQC on the crown jewels. Start hybrid TLS and PQC key exchange on the highest-X, longest-lived systems.
4. Engineer for crypto-agility. Abstract cryptography behind interfaces so future swaps are configuration, not re-architecture.
5. Train the people who will run it. A migration is only as good as the leaders who scope it and the engineers who implement it.

Where IQCDL fits

Mosca's Theorem tells you whether you are late. Capability tells you how fast you can catch up — which is exactly the Y you can control.

• The IQCDL Foundation Level equips CISOs, IT leaders, and compliance officers to run a Mosca's-Theorem risk assessment and scope a migration. It is mapped to NIST FIPS 203/204/205, ISO/IEC, IEEE, and the EU PQC Roadmap.
• The IQCDL Practitioner Level trains developers and security architects to implement CRYSTALS-Kyber, Dilithium, and SPHINCS+, build hybrid crypto-agile TLS, and produce a CBOM and migration roadmap.
• The free 2-minute Readiness Assessment gives you an AI-tailored starting estimate of your risk profile.

Lowering Y — through trained people and crypto-agile architecture — is the single most controllable lever in the equation.

Frequently asked questions

Is Mosca's Theorem a precise prediction? No. It is a risk-management heuristic. X and Y are knowable for your organization; Z is a forecast best treated as a range. Its value is forcing an explicit, defensible decision rather than vague concern.

Does a quantum computer already exist that can break encryption? Not publicly. But "Harvest Now, Decrypt Later" means long-lived data captured today can be decrypted once one does — which is why high-X data is already exposed.

What should we do first? Build a cryptographic inventory (CBOM) and classify data by secrecy lifetime (X). Everything else follows from knowing what you have and how long it must stay secret.