Mosca theorem quantum risk calculation for OT networks

A Mosca theorem quantum risk calculation is a simple time-based test. You add how long your data must stay secret (X) to how long it takes you to migrate to quantum-safe cryptography (Y), and compare the total with the expected arrival of a cryptographically relevant quantum computer (Z). If X + Y exceeds Z, traffic recorded today is already exposed.

For operators of OT and critical infrastructure this is not an abstract exercise. Links between control centres, substations, pumping stations, plants, cloud historians and remote engineers carry data with a long life, while the networks themselves change slowly. This article shows how to fill in each variable for those links, which flows to migrate first, and how to put the result in front of a board or regulator.

What is Mosca’s inequality and how do you apply it to critical infrastructure data?

Mosca’s inequality states that you have a problem if X + Y > Z, where X is data shelf life, Y is migration time and Z is the time until quantum computers can break today’s public-key cryptography. For critical infrastructure you apply it per data flow, not per organisation.

The formula comes from Michele Mosca’s work on quantum risk. Europol’s Innovation Lab describes it as Mosca’s Inequality Theorem, referencing the 2017 ‘A Methodology for Quantum Risk Assessment’ by Mosca and Mulholland for the Global Risk Institute. The underlying concern is “store now, decrypt later”: actors may already today harvest encrypted data with a view to decrypting it once quantum computers are universally available, triggering the need to review for how long data should be kept secure.

In practice, the vulnerable part of a site-to-site or remote access link is the key exchange. Symmetric payload ciphers with adequate key lengths are not the weak point; the classical asymmetric handshake (RSA, Diffie-Hellman, ECDH) that agrees the session key is. A recording of the handshake plus the encrypted payload is enough for later decryption once that handshake can be broken.

Filling in Z without pretending to know the date

Z is the variable nobody can pin down. NIST’s own answer to when a threatening quantum computer will appear is blunt: “No one knows. Researchers need to surmount many technical challenges before this can happen. Experts’ estimates range from a few years to a few decades.” The practical response is to use a range taken from published expert surveys.

Statistic (Global Risk Institute survey, 2024, via OECD): In a survey of 32 leading science and industry experts in the field, approximately two-thirds estimated a 50% or greater likelihood of the arrival of a cryptographically relevant quantum computer within the next 15 years (Mosca and Piani, 2024).

Policy deadlines give a second anchor for Z. Regulators have effectively chosen a Z for you, and your calculation should show whether you will meet it.

How long must operational data such as grid topology, process recipes or control commands stay confidential?

Shelf life (X) for OT data is set by how long the information stays useful to someone planning disruption or copying know-how, which for topology and recipes is often as long as the asset itself. Short-lived control commands have a low X for confidentiality but usually travel on the same links as long-lived data.

Do not take X from a records retention schedule. Retention rules say how long you must keep data; Mosca’s X asks how long its disclosure would still cause harm. The following categories cover most OT traffic between sites, clouds and remote users:

The European Commission’s Fabiana Da Pieve made the OT point directly in an ENISA-hosted presentation on the EU roadmap: devices deployed today remain in the field for decades. Configuration data describing those devices inherits that lifetime.

How do you estimate the migration time for site-to-site and remote access links?

Migration time (Y) is the sum of inventory, decision and procurement, testing, and rollout inside OT change windows, multiplied across every link and every site. In most OT estates the governance and outage planning take far longer than the technical installation.

Start with an inventory

You cannot estimate Y for links you have not listed. The NCCoE Migration to Post-Quantum Cryptography project (NIST SP 1800-38) addresses exactly this step. Volume B covers automated discovery tools. These tools identify instances of quantum-vulnerable public-key algorithms that are widely deployed across an organization to create a cryptographic algorithm inventory that will help an organization to develop its migration roadmap. The project is a broad effort: CISA is a collaborator along with over 28 industry partners in the NIST National Cybersecurity Center of Excellence’s (NCCoE) “Migration to PQC” project.

For connectivity, the inventory per link should record: endpoints, transport (public internet, leased line, private APN, satellite), current key exchange algorithm, who owns each end, whether the traffic must still pass a firewall for inspection, and the next available maintenance window.

Build Y from phases, not from a gut feeling

• Inventory and classification: often the slowest phase for estates with many small outstations.
• Design and approval: architecture review, change advisory board, possibly sector-specific approval.
• Procurement and lab testing: include latency and throughput tests against your protocols, since some OT protocols are sensitive to timing.
• Rollout: the number of sites divided by how many you can change per outage window, plus travel for unmanned locations.
• Remote users: client distribution and support for engineers and third-party maintainers.

The choice of approach changes Y considerably. Replacing or upgrading every router and firewall to support post-quantum protocols ties you to vendor roadmaps and hardware cycles. An overlay gateway approach adds a quantum-safe layer without touching existing equipment. Quantum Network’s QPN gateway, for example, is placed at each end of a link and integrated by adding or adapting a few routes; installation takes roughly 30 minutes per gateway for a team that knows its own network and IP addresses. In that model, Y is dominated by planning and change windows, not by the installation itself.

Which data flows should be migrated to quantum-safe encryption first?

Migrate first the flows where X + Y most clearly exceeds Z: long-lived data crossing networks you do not control, on links that take long to change. In practice that is usually inter-site and site-to-cloud traffic over the public internet, followed by remote access for engineers and vendors.

Two further criteria help break ties. First, prefer hybrid key exchange, which combines a classical and a post-quantum algorithm. ENISA’s integration study argued that the risk of post-quantum proposals being broken is high enough that such combinations are recommended even when they are not required. The EU roadmap likewise asks for hybrid deployments in which traditional schemes must NOT be weakened. Second, prefer crypto-agile solutions, so that an algorithm can be swapped without replacing hardware in the field.

For remote access, check that the client runs on the operating systems your engineers actually use and does not require opening inbound ports at the plant. As an example, Quantum Network’s QPN combines a classical part and ML-KEM (FIPS 203) into one session key, and its remote access client for Windows and macOS needs no incoming firewall ports.

How do you present a Mosca-based risk calculation to management or a regulator?

Present one row per data flow with explicit X, Y and a range for Z, show where X + Y crosses Z, and anchor the result to published regulatory milestones. Ask for a specific decision, not general awareness.

Use external dates as the reference for Z

Boards respond better to official timelines than to physics. Three references cover most European and transatlantic operators:

• EU Coordinated Implementation Roadmap for PQC (June 2025): All Member States should start transitioning to PQC by the end of 2026. At the same time, the protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030. The Commission’s own summary names critical infrastructure (eg water, energy, health care, finance and transportation) as high-risk. It builds on Commission Recommendation (EU) 2024/1101.
• NIST IR 8547 (initial public draft, November 2024): 112-bit security strength - deprecated after 2030, disallowed after 2035. NIST notes that earlier guidelines had projected that NIST would disallow public-key schemes that provide 112 bits of security on January 1, 2031, so the quantum transition replaces, rather than adds to, an existing deadline.
• ENISA: its integration study and later work on hybridisation give the technical rationale for hybrid, crypto-agile designs that a regulator will recognise.

The political signal matters too. Henna Virkkunen, Executive Vice-President of the European Commission, said at the roadmap’s publication that post-quantum cryptography is essential to ensure a high level of cybersecurity.

A one-page structure that works

1. Scope: number of links per category (site-to-site, edge-to-cloud, remote access).
2. Per-flow table: X with its justification, Y with its phases, and the year in which X + Y is reached if migration starts now.
3. Sensitivity: the same table under an early, central and late Z, so the board sees that the conclusion holds across scenarios.
4. Gap to milestone: which flows will not be migrated by end 2030 at the current pace.
5. Decision requested: budget, change-window capacity and an owner.

Keep the calculation as a living document. Update Z when new expert surveys or agency guidance appear, update Y as links are migrated, and record which flows have moved to hybrid key exchange. A regulator will want to see the trend over several reporting periods, not a single estimate.