The Mosca Inequality Explained: When Should You Migrate to PQC?

One of the most common questions in post-quantum cryptography is deceptively simple: when do we need to start migrating? The Mosca Inequality, introduced by cryptographer Michele Mosca of the University of Waterloo, provides a rigorous framework to answer this question with three measurable variables. It has become the standard tool for translating quantum computing timelines into concrete migration deadlines.

The Formula

The Mosca Inequality states that you must begin your migration when:

X + Y > Z

Where:

X = The time needed to fully migrate your cryptographic infrastructure to post-quantum algorithms (the migration timeline).
Y = The number of years your data must remain confidential after it is encrypted (the secrecy shelf life).
Z = The estimated number of years until a cryptographically relevant quantum computer (CRQC) exists.

If X + Y exceeds Z, your data will be vulnerable before you can protect it. The migration is already overdue. If X + Y equals Z, you are at the deadline -- any delay creates a window of vulnerability. Only when X + Y is safely less than Z do you have time remaining.

The elegance of Mosca's framework is that it separates the problem into three independently measurable variables, each owned by a different part of the organization. Your engineering team estimates X. Your data governance team determines Y. Your threat intelligence team tracks Z. The inequality combines them into a single decision point.

Breaking Down Each Variable

X: Migration Timeline

This is the variable that organizations most consistently underestimate. Migrating cryptographic infrastructure is not a software patch or a configuration change -- it is a multi-year program that touches every layer of your technology stack.

A realistic migration involves:

Discovery: Inventorying every cryptographic algorithm, protocol, certificate, and key in your infrastructure. For a mid-size enterprise, this alone can take 3-6 months when done comprehensively.
Assessment: Classifying each cryptographic asset by quantum vulnerability, mapping dependencies, and identifying which systems protect long-lived data. Another 2-4 months.
Architecture: Designing the target state -- which algorithms to use, how to implement hybrid mode, how to maintain backward compatibility, and how to handle third-party dependencies.
Implementation: Deploying post-quantum algorithms across all identified systems. This includes TLS configuration changes, certificate reissuance, application-layer protocol updates, and embedded system firmware upgrades.
Testing: Validating that all systems interoperate correctly with post-quantum algorithms, that performance meets requirements, and that no regressions have been introduced.
Rollout: Staged deployment to production, with monitoring and rollback capability.

For a typical enterprise with moderate complexity (several hundred applications, a managed PKI, cloud infrastructure, and some legacy systems), realistic migration timelines range from 3 to 8 years. Organizations with extensive embedded systems, hardware security modules (HSMs), SCADA/OT networks, or deeply coupled legacy protocols can face timelines of 8-12 years or more.

Government agencies operating under mandates like OMB M-23-02 and CNSA 2.0 are working against defined deadlines, but even they acknowledge that full migration is a multi-year undertaking. The DoD's target of exclusive CNSA 2.0 usage by 2035 implies a migration period of approximately 10 years from the 2025 start date.

How to estimate your X: Start with a cryptographic inventory. Count the number of systems using quantum-vulnerable algorithms. Estimate the level of effort to upgrade each category (TLS endpoints, certificates, application-layer crypto, embedded systems). Factor in testing, staged rollout, and the reality that not all systems can be upgraded simultaneously due to interoperability requirements.

Y: Secrecy Shelf Life

This variable asks a fundamental question about your data: how long does it need to remain confidential? The answer is not a single number -- different data assets within the same organization have different shelf life requirements.

The critical insight is that your Y value is determined by your most sensitive, longest-lived data that transits quantum-vulnerable channels. If 95% of your data has a shelf life of 2 years but 5% has a shelf life of 30 years, and both transit the same RSA-encrypted channels, your effective Y is 30 years.

Common shelf life values by industry:

Data Type	Typical Shelf Life	Governing Standard
Web session tokens	Hours to days	N/A
API authentication tokens	Days to months	N/A
Financial transactions	7-10 years	SOX, PCI-DSS
Tax records	7 years	IRS requirements
Healthcare records	20-50 years	HIPAA
Genetic data	50+ years	GINA, GDPR
Attorney-client privileged communications	Indefinite	ABA Rules
Trade secrets	Indefinite	DTSA
Classified intelligence (Top Secret)	25-75 years	EO 13526
Nuclear weapons data (RD/FRD)	Indefinite	Atomic Energy Act

How to determine your Y: Work with your data governance, legal, and compliance teams to classify your data assets by confidentiality requirement. Identify the maximum shelf life across all data types that transit quantum-vulnerable encryption. That is your Y.

Z: Quantum Threat Timeline

This is the most uncertain variable, and the one most likely to change over time. Z represents the number of years from now until a CRQC capable of breaking RSA-2048 (or equivalent) becomes operational.

Current estimates from major research organizations and intelligence agencies:

Optimistic (nation-state breakthrough): 5-8 years (2031-2034)
Consensus estimate: 10-15 years (2036-2041)
Conservative (significant obstacles remain): 15-25 years (2041-2051)

Several factors drive uncertainty in Z:

Error correction progress: Logical qubit counts continue to improve as error correction techniques advance. The number of physical qubits needed to factor RSA-2048 has decreased from millions to hundreds of thousands as algorithms and hardware improve.
Hardware scaling: IBM, Google, Quantinuum, and other hardware vendors are making steady progress on qubit count and quality. Whether this progress continues at its current rate or hits physical limitations is uncertain.
Algorithmic improvements: New quantum algorithms or optimizations to Shor's algorithm could reduce the requirements for breaking classical cryptography.
Unknown unknowns: A classified quantum computing program at a nation-state level could be further advanced than publicly known efforts.

The prudent approach is to use a moderate estimate for planning (10-12 years) while acknowledging that the optimistic scenario is possible. If your inequality is already triggered under the moderate estimate, the exact value of Z does not matter -- you need to act regardless.

How to track your Z: Follow publications from NIST, NSA, and leading quantum computing research groups. Revisit your Z estimate annually. If Z decreases (because of new hardware breakthroughs or algorithmic advances), check whether your inequality is still satisfied.

Practical Examples

Example 1: Healthcare System

A regional hospital network:

X = 6 years. Complex infrastructure with legacy EMR systems, medical devices with embedded cryptography, a mature PKI, and hundreds of vendor integrations. Full migration is a major program.
Y = 30 years. Patient records must remain confidential for the patient's lifetime under HIPAA. Genetic data even longer.
Z = 12 years. Moderate CRQC timeline estimate.

The inequality: 6 + 30 = 36 > 12. The migration is massively overdue. Even with a conservative Z of 20 years, 36 still exceeds 20. This organization should have started years ago, and every month of delay extends the window of vulnerability.

Example 2: Financial Services Firm

A mid-size bank:

X = 4 years. Modernized infrastructure but complex regulatory requirements and extensive third-party integrations.
Y = 10 years. Financial records subject to SOX and PCI-DSS retention requirements.
Z = 12 years.

The inequality: 4 + 10 = 14 > 12. Migration should have started 2 years ago. The bank is behind schedule.

Example 3: Cloud-Native SaaS Startup

A B2B SaaS company:

X = 1 year. Modern cloud-native infrastructure, no legacy systems, automated deployment pipelines.
Y = 3 years. Business data with relatively short confidentiality requirements.
Z = 12 years.

The inequality: 1 + 3 = 4 < 12. There is time remaining, but starting now means a smooth, low-pressure transition. Waiting until 2033 would put them at the deadline.

Example 4: Defense Contractor

A company handling classified DoD data:

X = 8 years. SCADA systems, HSMs, air-gapped networks, and extensive compliance requirements.
Y = 50 years. Classified material with decades-long confidentiality requirements.
Z = 12 years.

The inequality: 8 + 50 = 58 > 12. The migration is catastrophically overdue from a theoretical standpoint. This is why the NSA issued CNSA 2.0 with aggressive timelines -- organizations in this category have no time to spare.

Using the Inequality to Drive Organizational Action

The Mosca Inequality is not just a theoretical tool. It is a decision-making framework that translates quantum risk into business terms. Here is how to use it effectively:

For Security Leadership

Present the inequality to your CISO and CTO with your organization's specific numbers. Frame it clearly: "Our data needs to stay secret for Y years. Migration will take X years. If X + Y exceeds the threat timeline Z, we are already behind." The math is simple enough for any executive to understand, and the conclusion is unambiguous.

For Board Presentations

The Mosca Inequality produces a single, defensible answer to "Do we need to act now?" If the inequality is triggered, the answer is yes, full stop. The board does not need to understand lattice cryptography or Shor's algorithm -- they need to understand that the math says the timeline for action has passed.

For Budget Justification

When requesting funding for PQC migration, the Mosca Inequality provides the justification. If X + Y > Z, every month of delay is a month of additional risk. Quantify this by connecting to your HNDL Score -- the higher the HNDL Score, the more damage each month of delay represents.

For Vendor Negotiations

Use the inequality when evaluating vendor timelines. If a critical vendor tells you they will not support PQC until 2030, factor that into your X. If it pushes X + Y past Z, that vendor dependency is a material risk that needs to be addressed -- either by accelerating the vendor's timeline, finding an alternative, or implementing compensating controls.

Reducing Your Variables

If the inequality is triggered, you have three levers:

Reduce X by investing in migration acceleration. Automate discovery, deploy hybrid mode early, and parallelize migration workstreams. The Q by Wentzel platform helps reduce X by automating cryptographic discovery and providing a migration roadmap.

Reduce Y by segmenting your network so that long-lived sensitive data transits only PQC-protected channels, while less sensitive data can remain on classical encryption for now. This does not reduce your overall Y, but it reduces the scope of systems that need to be migrated immediately.

Acknowledge Z is uncertain and plan for the optimistic scenario. If your migration plan works under Z = 8 years, it definitely works under Z = 15 years. Building margin into your plan protects against surprises.

The Most Important Step

Calculate your own values. Run a cryptographic inventory. Estimate your migration complexity. Classify your data sensitivity. Plug in the numbers. The math will tell you whether action is required today -- and for most organizations handling any data with multi-year confidentiality requirements, it will tell you that the time to start was years ago.

The Mosca Inequality does not tell you what to do. It tells you when. And for a growing number of organizations, the answer is: now.