up:: Quantum Risk Models MOC

The Mosca Inequality, Worked

The Mosca inequality worked is Mosca’s theorem taken from a one-line slogan to a calculation you can run against your own assets. The rule is X + Y > Z: if the years your data must stay secret (X) plus the years your migration takes (Y) exceed the years until the cryptography can be broken (Z), you are already too late to protect that asset. This note plugs real numbers into that inequality for several asset classes, because the arithmetic is where the abstraction becomes a deadline. The examples use illustrative figures to show the method, and the honest way to run it is with a range of Z values rather than a single guessed date.

The short version:

• The rule is X + Y > Z, and working it means putting real year-counts on all three variables for a specific asset.
• X is the security shelf-life of the data or trust, Y is the honest migration time including inventory and vendor lag, and Z is the years until the relevant break.
• Because Z is uncertain, you run three values, a conservative (earlier) Z, a moderate Z, and an optimistic (later) Z, and see which assets fail the inequality under any of them.
• An asset that fails X + Y > Z under even the optimistic Z is unambiguously urgent, and its migration should already be moving.
• The worked numbers turn “quantum someday” into “this specific archive is already past its safe start date,” which is the sentence that moves a budget.

Think of it as a runway calculation for a plane that has to be wheels-up before the runway ends. X is how far the plane still has to taxi, Y is how long the takeoff roll takes, and Z is how much runway is left. If taxi plus takeoff is longer than the runway, you needed to start sooner, and no amount of optimism about the runway changes the physics.

How do you put numbers on X, Y, and Z?

You estimate each variable in years for the specific asset, and the discipline is in refusing to hand-wave any of the three:

Variable	What you estimate	A worked figure and its reasoning
X	Years the data or trust must stay secure	A medical record with lifetime relevance: 50 years. A signed firmware root of trust for a 15-year device: 15 years. A short-lived session token: under 1 year.
Y	Years the migration actually takes	A large enterprise with low crypto-agility and heavy vendor dependence: 5 to 7 years. An agile estate with central control: 2 to 3 years.
Z	Years until the relevant break	Run a band, not a point. A conservative Z of 8 years, a moderate Z of 12 years, an optimistic Z of 18 years, drawn from the Quantum Threat Timeline expert surveys.

The figures above are illustrative, chosen to show the shape of the reasoning rather than to assert a specific arrival date. The load-bearing move is that X measures the information’s required secrecy lifetime, which people routinely confuse with system lifetime or storage retention, and Y is the honest migration time including inventory, dependency mapping, procurement, vendor-support lag, and rollout, which is why it runs years longer than the “just flip a setting” intuition. Z is the one you cannot know, so you never commit to a single value.

Source: NIST, “Migration to Post-Quantum Cryptography,” NIST IR 8547 (framing X, Y, Z as data-security lifetime, migration time, and time-to-quantum).

Is a long-lived medical archive already too late?

Take an archive of patient records that stays sensitive for a working figure of X = 50 years, held by a large health system whose migration realistically takes Y = 6 years. Run the inequality across the Z band:

1. Conservative Z = 8 years. 50 + 6 = 56, and 56 > 8 is true by a wide margin. Deeply too late already.
2. Moderate Z = 12 years. 56 > 12 is true. Too late.
3. Optimistic Z = 18 years. 56 > 18 is true. Still too late.

This asset fails X + Y > Z under every value of Z, including the most optimistic. The interpretation is unambiguous: any patient record captured today under classical public-key protection, with a 50-year sensitivity horizon, is already in harvest-now-decrypt-later exposure, because the data will still matter long after the earliest plausible break. The migration for this class should already be underway, and no refinement of the quantum timeline changes that conclusion, because the sum on the left dwarfs even the largest Z.

Where does a mid-life internal service land?

Now take an internal service whose data stays sensitive for X = 7 years, in an organization that has invested in crypto-agility and can migrate in Y = 3 years. Run the band:

1. Conservative Z = 8 years. 7 + 3 = 10, and 10 > 8 is true. Too late under the conservative estimate.
2. Moderate Z = 12 years. 10 > 12 is false. Inside the safe margin.
3. Optimistic Z = 18 years. 10 > 18 is false. Comfortably safe.

This asset sits on the boundary. It fails the inequality under the conservative Z and passes under the moderate and optimistic ones, which is exactly the case the three-value band exists to expose. The reading is that this service is not in the deep-red urgency of the medical archive, but it is not safe to defer indefinitely either, because a single pessimistic-but-plausible break horizon puts it over the line. The right move is to schedule its migration deliberately, with the agility investment already paying off by holding Y down to 3 years. Note the leverage: if this same organization had left Y at 6 years, the sum would be 7 + 6 = 13, which fails even the moderate Z, so the agility work is what pulled the asset out of urgent territory.

What about a firmware root of trust?

Take a code-signing or firmware root of trust that must keep verifying for the X = 15-year service life of the devices it protects, in a program where updating the signing infrastructure and re-provisioning fielded devices takes Y = 5 years. Run the band:

1. Conservative Z = 8 years. 15 + 5 = 20, and 20 > 8 is true. Too late.
2. Moderate Z = 12 years. 20 > 12 is true. Too late.
3. Optimistic Z = 18 years. 20 > 18 is true. Too late.

This asset fails under every Z, and it does so on the trust side rather than the confidentiality side, which is the Non-HNDL case. The threat is not that recorded data gets decrypted later. It is that once a quantum computer can forge signatures, a device with a 15-year field life is still trusting a signature scheme an attacker can now counterfeit, and the migration to re-provision fielded hardware is slow. The worked numbers show why signing and firmware trust belong in the first migration phase even though the felt urgency is lower than decryption: the long device life and the slow re-provisioning combine to blow past even an optimistic break horizon.

What do the worked numbers tell you to do?

They sort your assets into three buckets that map to a migration sequence, which is the whole reason to run the arithmetic rather than argue about the quantum timeline:

1. Fails under every Z (deep urgency). Long-X, long-Y assets like the medical archive and the firmware root of trust. These need to be moving now, because no plausible timeline makes waiting safe.
2. Fails under the conservative Z only (boundary). Moderate-X, moderate-Y assets like the internal service. These get a deliberate schedule and are the clearest place to see crypto-agility pay off by shrinking Y.
3. Passes under every Z (deferrable). Short-X, short-Y assets like ephemeral tokens and low-value telemetry. These wait, and spending scarce migration effort on them early is a misallocation.

The sequence falls out of the numbers. The theorem does not require you to predict the arrival of a cryptographically relevant quantum computer, it requires you to be honest about how long your data stays sensitive and how long your migration takes, and then the inequality tells you which assets have already run out of runway. That is the translation from “quantum is a someday problem” to “this specific archive is past its safe start date,” and the second sentence is the one that moves a budget.

Common misconceptions

1. “You need to know Z to use the inequality.” You need a band for Z, not a point. Assets that fail under every value in the band are urgent regardless of where the true Z lands, which is most of the assets that matter.
2. “X is just how long we keep the data.” X is how long the data must stay secret, which can run far longer than a retention policy and is the variable people most often understate.
3. “Y is the engineering time to swap the algorithm.” Y is the whole migration: inventory, dependency mapping, procurement, vendor lag, validated-module wait, and rollout. The swap is the small part.
4. “If we pass the inequality today, we are done.” The variables move. A rising X, a slipping Y, or a shortening Z can flip a passing asset to failing, so the calculation is a periodic check, not a one-time verdict.
5. “The numbers have to be exact.” They have to be honest and banded, not precise to the year. The method works on order-of-magnitude reasoning, because the assets that matter fail or pass by wide margins.

Questions people ask

How do I actually calculate my quantum migration deadline? Estimate X (years your data must stay secret) and Y (honest years to migrate) for the asset, then subtract their sum from a band of Z values. If X + Y exceeds even your optimistic Z, the safe start date was in the past, and the asset is urgent now.

What Z values should I use? Use a conservative, moderate, and optimistic year-count drawn from the Quantum Threat Timeline expert surveys rather than a single guess, and judge each asset against all three. The band, not the point, is what makes the answer defensible.

Why does the medical archive fail so badly? Because X is very large (50-year sensitivity), so X + Y overwhelms any plausible Z. Long-lived confidential data is the textbook harvest-now-decrypt-later case, and it is urgent under every timeline.

Does the inequality only apply to encrypted data? No. The firmware example fails on the trust side, where the risk is future signature forgery (Non-HNDL), and X + Y > Z governs it identically. Long-lived trust is as exposed as long-lived secrecy.

How does crypto-agility change the numbers? It shrinks Y. In the internal-service example, agility held Y at 3 years and kept the asset out of urgent territory, where a 6-year Y would have pushed it over the line under a moderate Z. Agility is the one variable you directly control.

How often should I re-run this? Treat it as a periodic check, because X can rise with new data classes, Y can slip as an estate grows, and Z can shorten as the science advances. An asset that passes today can fail next year if any variable moves against you.

---

Everything here is the map, given freely. When your team needs X, Y, and Z estimated for your own assets and turned into a defensible migration sequence with the numbers behind it, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.