Mosca's inequality, in numbers. The only variable you control is when you start.

In the first article in this series, I promised to come back to a calculation, with numbers. This is it.

Mosca's inequality appears in almost every presentation on post-quantum cryptography. It is often quoted and rarely applied. It usually stays on a slide: a formula, three letters, an alarming conclusion. Between the formula and the decision, the step that matters is almost always missing: doing the calculation on your own data.

It is sometimes called “Mosca's theorem”, but it is not a theorem. It proves nothing. It is a planning tool, proposed by Michele Mosca in 2015 and published in IEEE Security & Privacy in 2018. Its value lies in forcing a question that organizations tend to avoid.

Three variables

The original formula is simple: if X + Y > Z, you have a problem.

X is the confidentiality lifetime: how long the data you protect today must stay secret. Not how long you keep it, but how long its disclosure could cause harm.

Y is the migration time: how long it takes to replace vulnerable cryptography in every system that matters. Not just in your own code — it also covers suppliers, HSMs, network equipment, contracts, procurement cycles, testing and approvals.

Z is the time until a quantum computer capable of breaking RSA and ECC appears. The literature calls it a CRQC (cryptographically relevant quantum computer).

Of the three, Z is the only variable that cannot be controlled. Paradoxically, it is also the only one anyone talks about.

Why X starts today

The inequality matters now for a simple reason: data doesn't have to be decrypted at the moment it is intercepted. It can be stored. The strategy has a name: harvest now, decrypt later (HNDL). An adversary recording the traffic between two data centers today doesn't need a quantum computer today. They need one before the data loses its value.

That moves the clock. Exposure doesn't begin on Q-day, but at the moment of interception. Any key exchange done today with RSA or ECDH has a confidentiality that depends on a date in the future.

The calculation

Let's put numbers on it, starting from autumn 2026.

For Y, I use the estimate in the DNSC document: 6–8 years for systems of medium and high complexity. The EU coordinated roadmap speaks of 5–10 years. This is not a pessimistic estimate. It is an estimate for organizations that start now.

For Z, I use the 2025 Global Risk Institute report. The experts surveyed estimate a 28–49% probability that a CRQC exists by 2035, and 51–70% by 2040. On the 20-year horizon, to 2045, almost all respondents put the probability above 50%. These figures refer to RSA-2048. For elliptic curves, the resource estimates are lower, because ECC uses shorter keys than RSA.

Let's apply the formula to three categories of data.

Session data. An authorized transaction or a login has an X of minutes or days. X + Y is effectively just Y, which means 2032–2034. Here the inequality says you have time, if you start now. There is a catch: a short session can carry long-lived data. X belongs to the data, not to the channel.

Data with a ten-year horizon. Credit files, customers' financial information and confidential communications have X = 10 years. Data protected today must therefore hold until 2042–2044. For that horizon, experts consider a CRQC more likely to exist than not. The inequality is already violated, with a probability few would accept for any other kind of risk.

Data with lifelong confidentiality. For medical records, genetic data or the identities of protected persons, X exceeds any reasonable estimate of Z. For this data, the inequality has never been satisfied. Everything transmitted so far over vulnerable channels is already exposed. The only question left is how much more you add.

The missing variable

The formula assumes migration starts today. It rarely does. The honest form has one more term:

D is the time until migration actually starts.

In the short term, D is the only variable you control completely. X is fixed by the nature of the data and by law. Z doesn't depend on anyone in the organization. Y can be reduced, but only through investments that take years: crypto-agility, inventory, internal standardization. D, on the other hand, is decided in a meeting.

Every year of delay adds exactly one year to the left-hand side of the inequality. Nothing on the right-hand side moves to compensate.

Where the formula applies differently

The inequality was designed for confidentiality. For digital signatures, the logic is different, and the difference is often overlooked.

A signature cannot be harvested today and forged retroactively. The risk appears at time Z. That changes what X means. For a root of trust (a certificate authority, a firmware signing key, a qualified certificate), the question is how long the key generated today will be in use.

A device installed in 2027, with an RSA public key embedded in its firmware and a 15-year lifespan, will still be running in 2042. If that key cannot be replaced remotely, the risk was accepted on the day of purchase — probably without anyone having thought about it.

Electronic archives with long-term evidential value work the same way. They depend on timestamps being renewed before the algorithms they use become insecure, and that, too, is a Mosca-style calculation.

What the inequality actually does

Mosca's inequality predicts nothing. It doesn't tell you when a CRQC will appear. It tells you which of your data is already outside the safety window, under whatever assumption about Z you choose.

So it is a sorting tool, not a forecasting tool. It applies to categories of data and to systems, not to the organization as a whole. A bank doesn't have a single X. It has dozens.

This is where the practical problem arises. To calculate X, you need to know where the data is and how long it must be protected. To estimate Y, you need to know what cryptography you use, where, and who controls it. Without a clear and complete inventory, none of these questions can be answered, and the inequality remains a formula on a slide.

The first phase of the DNSC roadmap, due on 31 December 2026 for essential and important entities, is exactly this inventory: the CBOM. Few organizations will have a complete one by then. All of them can have one that covers the data categories with a large X. That is where it is worth starting.

The 2030 and 2035 deadlines can be read as the regulators' answer to Mosca's inequality, calculated for the economy as a whole. Each organization has to do the same calculation for its own data. For some categories, the result will be reassuring. For others, it will show that the right moment to start has already passed.

Z doesn't depend on you. D does.