Mosca's Inequality: The Formula That Tells You If You're Already Too Late on Post-Quantum Migration

TL;DR: Mosca's Inequality (X + Y > Z) is a three-variable test for whether your organization has already missed the window to migrate to post-quantum cryptography. Add the shelf life of your data (X) to the duration of your migration (Y) and compare to the years until a cryptographically relevant quantum computer arrives (Z). If X + Y is greater than Z, you have a problem. For most organizations handling data that needs to stay secret for a decade or more, the inequality has already been violated.

There's a tempting way to think about post-quantum migration that goes like this: NIST finalized the PQC standards in 2024, the aggressive CRQC forecasts put a cryptographically relevant quantum computer around 2029, the conservative ones put it past 2040, and if we start our migration in 2026 and finish by 2030 we have plenty of buffer. Easy.

That reasoning is wrong, and the framework that shows why was written by a Canadian cryptographer named Michele Mosca in 2015.

The formula

Mosca's Inequality is three variables and one comparison:

If   X + Y > Z   →   you have a problem.

X = how long your data must stay confidential
Y = how long your migration to post-quantum cryptography will take
Z = how long until a cryptographically relevant quantum computer exists

X is a property of your data, not your systems. A health record has an X of 30 years because it needs to stay secret for the patient's lifetime. An OAuth refresh token has an X of days. A genetic profile has an X of forever, because you cannot change someone's DNA if it leaks. Pick the data class with the longest X, that's the one driving your planning.

Y is a property of your organization. For a focused mid-sized company, Y is 3 to 5 years once you include cryptographic discovery, dependency analysis, library updates, PKI transitions, HSM firmware, third-party vendor migrations, and testing. Large enterprises with mainframes or international subsidiaries routinely hit 5 to 10 years.

Z is a property of physics and engineering, and nobody knows the real answer. Current public estimates range from 2029 (Gartner's aggressive forecast) to 2040+ (conservative academic estimates). The UK NCSC plans for full migration by 2035. The US NSA CNSA 2.0 mandates January 2027 for new national security system acquisitions.

The exposure gap

Here's the visual that makes the framework click:

Look at the 2029 record. It was encrypted one year before migration completes, with an algorithm that was perfectly secure at the time of encryption. Its confidentiality requirement runs to 2059. But a CRQC arrives in 2038, and from that day onward, every adversary holding a copy of that ciphertext can read it. That's a 21-year exposure gap for a record produced while you were still inside your migration window.

The 2031 record, encrypted with PQC, has no gap. That's the whole point of migration.

One worked example

Healthcare SaaS with 30-year health records.

• X = 30 years (HIPAA and EU medical record laws)

• Y = 4 years (mid-sized SaaS company, reasonable plan)

• Z = 12 years (assuming CRQC in 2038)

X + Y = 34. Z = 12. The inequality is violated by 22 years.

The honest reading: every record you've encrypted with RSA or ECC to date, and every record you encrypt until your migration completes, has an exposure gap. If a harvest-now-decrypt-later collector captured any of that ciphertext, it becomes readable when CRQC arrives, even though the patient's right to medical confidentiality extends into the 2050s.

You can't make the inequality hold perfectly. You can minimize the damage.

What this framework gives you

Three practical outputs:

A prioritization signal. Compute X + Y for each data class in your organization. The ones where the inequality is violated by the largest margin are the ones you migrate first. Health records before application logs. Financial transactions before session tokens. Trade secrets before whatever has a six-month shelf life.

A realism check on Y. If your internal migration plan puts Y at one year, you are either a very small company, or you are underestimating. The median Y across realistic plans is 3 to 5 years. Run your own numbers against industry-specific tables and see if they hold up.

A strategic case for re-encryption. Source-level migration (changing your code to use ML-KEM and ML-DSA) is only half the job. Re-encrypting the ciphertext you've already produced, across databases, backups, and archives, is the other half. Teams that start it in 2026 will get it done. Teams that wait until source-level migration completes in 2030 will be starting a multi-year data migration exactly when the exposure window is closing.

What's not in this post

This post is the short version. The full technical framework, with parameterization tables for X across twelve data classes, Y across ten migration phases, Z across seven agency and industry sources, four worked examples (healthcare, FinTech, generic B2B SaaS, defense), a complete re-encryption decision table, and a discussion of what Mosca's inequality doesn't capture, is in the technical white paper.

Download the technical white paper Mosca's Inequality: A Practical Framework for Post-Quantum Migration Planning. 4,000 words, 16 pages, includes the full exposure-gap diagram, industry-specific parameterization tables, worked examples, and the re-encryption decision framework. You can download the Mosca's Inequality: A Practical Framework for Post-Quantum Migration Planning:

Zerberus is building a post-quantum cryptography readiness platform for engineering teams. It produces a CycloneDX 1.6 Cryptographic Bill of Materials (CBOM) from your application source code, scores quantum exposure against NIST quantum security levels, and runs inside your existing workflow, not inside a consulting engagement. Currently open to pilot customers.

For pilot enquiries: leads@zerberus.ai

Related reading: Harvest Now, Decrypt Later (HNDL): A Developer's Guide to the Quantum Threat Already Underway. The attack model that makes Mosca's inequality urgent in the first place.