OT Cyber Risk Assessment: From Asset Criticality to Consequence

01Key takeaways

1. 01

   OT risk assessment ranks consequence first: what physical harm, safety event or loss of production could result, regardless of how the attack happens.

2. 02

   IEC 62443-3-2 gives a repeatable workflow: define the system under consideration, partition it into zones and conduits, then assess risk per zone against a tolerable-risk threshold.

3. 03

   A cyber PHA borrows from process-safety HAZOP. It links cyber-initiated scenarios to the same consequences that safety engineers already understand.

4. 04

   Likelihood in OT is dominated by reachability and exposure, not just vulnerability counts. An unreachable flaw is a lower-priority risk than a reachable one.

5. 05

   Reducing bidirectional reachability through segmentation, one-way transfer and scheduled disconnection lowers likelihood for risks you cannot patch or replace.

02What an OT risk assessment is

An OT risk assessment is a process for identifying, analyzing and evaluating cyber risk to industrial systems, then deciding how to treat it. The goal is not a longer vulnerability list. The goal is a ranked, defensible view of where a cyber event could cause unacceptable physical, safety, environmental or operational consequences, and what controls bring that risk to a tolerable level.

The distinguishing feature of OT risk assessment is its starting point. Instead of asking "what is vulnerable?", it asks "what happens if this process is manipulated, stopped or lied to?" That reframing matters because in operational technology the loss is measured in safety incidents, downtime, scrapped product or environmental release, not in records breached.

Short version: an OT risk assessment ranks risk by consequence to the physical process first, then works back to how an attacker could realistically cause it.

03Why OT risk is different from IT risk

IT risk assessment usually optimizes for confidentiality, integrity and availability of data, in roughly that order. OT inverts the priority. Availability and integrity of the process come first, and a safety dimension sits above all of them. A few seconds of unexpected behavior in a controller can have effects that no data-loss event ever would.

The systems are also different. OT assets can run for fifteen to twenty years, may not tolerate active scanning, and often cannot be patched on an IT cadence because the patch is unavailable, unvalidated by the vendor, or requires a plant outage. This means a standard CVSS-driven "patch the criticals" program is not a complete risk treatment. Many OT risks must be reduced by changing exposure and architecture, not by remediating the flaw.

IT risk lens

Protect data confidentiality, integrity and availability; remediate vulnerabilities on a regular patch cycle.

OT risk lens

Protect safety and process integrity and availability first; treat exposure and reachability as primary levers when patching is slow or impossible.

04Start with consequence and asset criticality

The most reliable input to an OT risk assessment is consequence, because it is the part operators understand best. Process engineers already know which loss-of-control scenarios are dangerous; safety studies have often documented them for years. A good assessment reuses that knowledge rather than reinventing it from a security viewpoint.

Asset criticality follows from consequence, not from cost or count. A small, cheap PLC that closes a relief path can be far more critical than an expensive historian. Rank assets by their role in worst-case scenarios: what they control, what they protect, and what depends on them. Tie each critical asset to the specific consequence it could enable so the rest of the assessment stays grounded in physical impact.

• Safety: injury, loss of life, or defeat of a safety instrumented function.
• Environmental: release, spill, emissions exceedance or regulatory breach.
• Production: lost output, off-spec batches, extended unplanned downtime.
• Equipment: damage to turbines, compressors, reactors or other long-lead assets.
• Cascading: loss of one process tripping or endangering connected systems.

05Cyber PHA: consequence analysis the OT way

A cyber PHA (process hazard analysis) adapts the HAZOP technique that process-safety teams already use. In a classic HAZOP, a facilitator walks through deviations such as "more flow" or "no pressure" and traces causes and consequences. A cyber PHA adds a cyber-initiating cause: what if a controller setpoint, a sensor reading or a logic block were manipulated by an attacker rather than failing by chance?

The power of this method is that it speaks the plant's language. It links cyber scenarios to the same consequence severities the safety case already uses, so security risk can be ranked on a scale management already trusts. It also exposes the scenarios that matter: not every vulnerability maps to a dangerous deviation, and some dangerous deviations need no software flaw at all, only an open path and valid commands.

A cyber PHA does not replace the standard hazard study. It runs alongside it, adding malicious, intelligent initiating causes to deviations the safety team has already analyzed.

06The IEC 62443-3-2 workflow

IEC 62443-3-2 defines a repeatable risk-assessment process for industrial automation and control systems. It begins by identifying the System under Consideration (SuC): the boundary of what is being assessed. It then runs an initial high-level risk assessment to find where the worst consequences could occur.

Next, the system is partitioned into zones (groups of assets with shared security requirements) and conduits (the communication paths between them). For each zone and conduit, the team performs a detailed risk assessment, comparing the residual risk against a defined tolerable-risk threshold and assigning a target Security Level (SL-T) where the gap is too large. The output is documented requirements, not just findings.

• Identify the System under Consideration and its boundary.
• Perform an initial high-level risk assessment to find worst-case consequences.
• Partition the SuC into zones and conduits based on criticality and trust.
• Conduct detailed risk assessment per zone and conduit.
• Compare residual risk to the tolerable-risk threshold and set target security levels.
• Document risk-treatment decisions and the residual risk that remains.

07Likelihood vs impact in OT

Risk is usually expressed as a function of likelihood and impact. In OT, impact is the consequence work described above. Likelihood is where teams most often go wrong, because they import IT habits and equate likelihood with vulnerability count or CVSS score.

In practice, OT likelihood is dominated by reachability and exposure. A severe vulnerability on an asset that has no network path to any attacker is a lower-priority risk than a moderate one that is directly reachable from the enterprise network or the internet. Likelihood should reflect how an attacker could actually arrive: remote access paths, flat networks, dual-homed engineering workstations, removable media and supply-chain entry points. Threat models such as MITRE ATT&CK for ICS help describe the techniques an adversary would need to chain, and each required step that is removed lowers the likelihood.

Impact

The process consequence if the scenario succeeds, ranked on the same severity scale as the safety case.

Likelihood

How realistically an attacker can reach and execute the scenario, driven heavily by exposure, reachability and the number of steps required.

Risk

The combination of the two, evaluated against a documented tolerable-risk threshold for that zone.

08Zone and conduit risk, and tolerable risk

Assessing risk per zone keeps the analysis honest. Each zone groups assets that share consequence and trust characteristics, so a single tolerable-risk threshold can apply across it. Conduits then become the focus of much of the treatment, because they are where reachability is granted or denied between zones of different trust.

Tolerable risk is the threshold the organization will accept without further reduction. It must be defined before the detailed assessment, ideally by the same governance that owns process-safety risk acceptance, so security risk is judged on an existing and trusted scale. Where residual risk for a zone exceeds tolerable risk, the conduit design is one of the strongest levers: tightening, filtering, making one-way, or removing a path can move a zone below threshold without touching the unpatchable assets inside it.

This is also where architecture and risk meet. A conduit that only needs to carry data outward can be reduced to a one-way path; a path that is only needed at defined times can be disconnected by default. Both reduce likelihood at the conduit rather than depending on every asset in the zone being hardened.

09Common pitfalls that distort the result

Most flawed OT risk assessments fail in predictable ways. They are usually too IT-shaped, too tool-driven, or too disconnected from the people who run the process. The fix is rarely a better scanner; it is better scoping and better consequence work.

• Scoring risk from CVSS alone, ignoring whether the vulnerable asset is reachable or consequential.
• Treating likelihood as a fixed number instead of something architecture changes can lower.
• Skipping consequence analysis and jumping straight to asset and vulnerability lists.
• Drawing zones around vendors or network switches rather than around consequence and trust.
• Setting tolerable risk after the assessment, so the threshold conveniently matches the result.
• Running the study without process or safety engineers, losing the realism that makes it credible.

A useful test: if an assessment would rank the same way after deleting the plant's physical context, it is an IT assessment wearing OT labels.

10Where exposure reduction fits in treatment

Once risks are ranked, treatment follows the usual options: reduce, accept, transfer or avoid. In OT, reduction often cannot mean patching, so it means changing exposure. Reducing the number and breadth of conduits, removing bidirectional reachability where it is not needed, and adding monitoring all lower likelihood for risks that would otherwise stay high because the underlying asset cannot change.

For conduits that only carry telemetry, logs, historian data or backups outward, one-way transfer is a direct way to drive return-path likelihood toward zero for that boundary. For systems that only need connectivity at defined intervals, scheduled disconnection shrinks the window of exposure. These are architectural treatments: they change the risk equation at the conduit rather than asking every device in the zone to be perfectly hardened.

Where a risk assessment shows a publication-only conduit carrying unacceptable inbound reachability, a one-way control such as an AirGapNet unidirectional transfer path can be weighed against firewall tightening and segmentation. It is one treatment option among several, and the assessment, not the product, should decide whether the boundary needs to be one-way, time-limited, or simply better governed.

11From assessment to a living program

A risk assessment is a snapshot, and OT environments change: new connections appear, vendors are added, processes are modified. The assessment should therefore be tied to management of change, so that any new conduit or asset triggers a reassessment of the affected zone rather than waiting for the next annual cycle.

Begin with the highest-consequence scenarios, define tolerable risk with the people who own safety risk, partition into zones and conduits, and treat the conduits first because that is where reachability and likelihood are easiest to change. Record residual risk explicitly so that acceptance is a deliberate decision and not an accident of an incomplete study. Done this way, the assessment becomes the backbone of the OT security program rather than a one-off document.

FAQFrequently asked questions

SRCSources of record