OT vulnerability management is not IT patch management

“There is a 9.8 open. That has to be patched.”

It sounds decisive. But it is not a risk decision, it is reading out a number. And in an OT environment that is exactly where things go wrong, in two directions at once.

The first: you patch something nobody could reach, using a window you only get twice a year, while the real exposure stays where it was. The second, and this one is more expensive: you patch a system the vendor has not validated the update for, the HMI does not come back, and you have stopped your own production with a security measure.

The question is not “is there a CVE?”. The question is “can anyone realistically reach this, and what does it cost to do something about it?”

What a CVSS score does and does not tell you

CVSS describes properties of a vulnerability: how it can be reached, how complex exploitation is, which privileges it needs and what the impact on the product is. That is useful. It is simply not your risk, because CVSS knows nothing about your architecture, your process and your controls.

What almost nobody uses: CVSS v4.0 has Threat metrics (does exploit code exist, is it being used) and Environmental metrics (how critical is this asset here, what controls are already in place) alongside the Base metrics. The score in most reports is the Base score alone, and that one is deliberately context-free. This is not a flaw in CVSS. It is a misunderstanding about what you are holding.

Same objective, different implementation

This does not stand on its own. It is one case of a broader mistake: assuming that a control which works in IT can move into an industrial environment unchanged.

The security objective is usually identical. The implementation often cannot be. In IT, confidentiality weighs heavily, you patch quickly, and endpoints are standardised enough to manage centrally. In OT the same decision also has to account for:

• availability: the process has to keep running, and downtime is the damage;
• process safety: a wrong intervention can hurt people, not only data;
• equipment lifecycle: a fifteen-year-old PLC is not neglect, it is an investment rhythm;
• vendor certification: patching outside what the OEM has validated can cost you support or your certificate;
• deterministic communication: a few milliseconds of delay from a security control can put a controller out of step;
• maintenance windows: you cannot intervene when you want to, but when the process allows it;
• recoverability: can you get back, and have you ever tried.

That does not mean OT can do with weaker security. That is the wrong conclusion, and it is drawn often. It means the control has to be translated into the environment where it must work. A firewall rule that closes the attack path is frequently the better control in OT than a patch that stops the process. Not because it is less strict, but because the risk as a whole comes down further.

This is not IT security versus OT security. It is security that holds up when the consequences are physical.

Start with context, not with the score

Before you form an opinion about a vulnerability, you want a handful of facts. Not for the sake of completeness, but because every one of these can flip the decision:

• asset and zone: where does it sit, and behind which conduit;
• function: what does this thing do in the process;
• criticality: to safety, to production, or supporting;
• exposure: from where is it reachable, and by whom;
• attack path: through which steps does someone actually get there;
• exploit available: theory, proof of concept, or ready to use;
• active exploitation: is it being used right now, anywhere;
• privileges required: anonymous, user, or already inside;
• vendor support: is this product still supported;
• patch available and validated: by the OEM, for your version;
• downtime needed: restart, revalidation, or nothing;
• existing controls: what already absorbs this;
• fallback: can you get back if it goes wrong.

Thirteen points looks like a lot. In practice you fill them in within five minutes if your asset information is in order, and if it is not, you have learned that too. A vulnerability whose zone you cannot name is not a patching question but an architecture question.

Exposure before patch status

The order matters. Most organisations start at “is there a patch?” and only then get to “does it matter?”. Turn that around, because the first question costs money and the second one is free.

Can an attacker realistically reach and exploit this?

Walk the chain, in this order:

1. Source: where would an attack start? Internet, IT network, a supplier laptop, USB, an adjacent zone?
2. Reachability: is there a path from that source to this asset? Not in theory, but in the firewall rules as they stand today.
3. Vulnerable service: is the vulnerable component actually running, and is the port open? In OT products the vulnerable library often sits in a feature you do not use.
4. Privileges required: does someone need to log in first, or is it anonymous?
5. Impact: what happens if it succeeds: loss of view, loss of control, or just a service falling over?

If the chain breaks somewhere, the urgency is different. That is not an excuse to do nothing. It is the reasoning for why this one does not need to happen tonight.

Is it actually being exploited?

“An exploit exists” and “this is being used” are two different things, and there are public sources that tell them apart:

• the CISA KEV catalog, with vulnerabilities confirmed to be exploited. If your CVE is in there, the discussion about likelihood is over;
• EPSS, a probability that a vulnerability will be exploited in the next thirty days. Not certainty, but a far better sort order than CVSS alone;
• vendor VEX statements: an explicit statement on whether *this* product in *that* configuration is affected. Many OT vendors now publish machine-readable advisories in CSAF format with VEX included. A *not affected* from the manufacturer is among the strongest pieces of reasoning available, and it costs you nothing.

This is also where most of the noise goes. A quarter of what a scanner reports disappears on a VEX statement or on “that feature is not running here”.

The fix carries risk of its own

This is where the factors above converge, because patching is the control they all press on at once. In IT a patch is usually the safe choice. In OT, patching is a change to a running process: and a change carries a risk profile of its own, separate from the vulnerability you meant to remove.

What goes wrong in practice is rarely spectacular: an HMI that no longer talks to the controller after the update, a production stop that costs more than the scenario you were covering, or a fallback everyone assumed worked until the moment it was needed. A control that stops your process is not the safe choice, however good it looks on paper.

And separately, because it genuinely is different: a change to a safety instrumented system is not a patch. That falls under functional safety (IEC 61511) and requires a management-of-change process with revalidation. Putting a SIS update on the same list as an HMI update will produce an expensive mistake sooner or later.

IEC 62443-2-3 is about exactly this: patch management in an IACS environment, including the division of roles between you and your supplier. Its core is that a patch only becomes an option once the supplier has validated it for your version, and and that the time between “CVE published” and “validated patch available” simply exists. That period is not a gap in your process. That period is your process.

The decision: four outcomes, no fifth

Every vulnerability ends in exactly one of four outcomes. Not in “on the list”, because that is not a decision.

This shape is not new, and that is the point: it is essentially SSVC, the decision-tree approach CISA uses instead of sorting by score. Following a recognised method rather than a scheme of your own saves a discussion at the first audit.

PATCH

When a vendor-validated patch exists, the exposure matters, and the operational impact fits an available window. That is the easy outcome, and in OT the least common one.

MITIGATE

You do not remove the vulnerability, you remove the path to it. In practice this is the most used outcome, and often the best one:

• a firewall rule or ACL that closes the path;
• disabling the vulnerable feature or port if you do not use it;
• restricting remote access to a jump host with session recording;
• tightening the zone boundary;
• protocol filtering, so only the commands that are needed get through;
• application allowlisting on the workstation;
• targeted detection on precisely this behaviour, so you notice if it happens.

A mitigation is only finished once you have verified it does what you think. A firewall rule sitting next to the real path only provides a better feeling.

MONITOR

When exposure is low, exploitation is theoretical, existing controls demonstrably work, and the patch risk is larger than the current cyber risk.

Monitor is a decision, not a holding pattern. To be allowed to use this outcome you must be able to say: what exactly are we watching, where would it show up, and on what date do we look again. If one of those three is missing, it is not monitoring but postponement.

ACCEPT

Only when the residual risk is explicitly understood and owned. Four conditions, and they are hard:

1. the residual risk is described in consequences, not in a score;
2. there is a person carrying it, and a department is not an owner;
3. the decision is recorded, with the reasoning alongside it;
4. there is a review date, and it sits in someone's calendar.

A recorded accept like that is stronger at board level than a list of five hundred open findings. It shows that someone thought about it. An open list only shows that someone scanned.

The decision card: to structure the discussion

Alongside the decision tree it helps to put seven factors side by side. Not to calculate a number, but to see what the discussion is actually about.

Deliberately no total score. A sum invites averaging, and with vulnerabilities averaging is dangerous: one factor at the far right, say “reachable from the internet”, outweighs six favourable factors combined. Use the card to structure the discussion, not to automate the decision.

Seven questions before you patch

If you take one thing from this article into your next meeting, take these seven:

1. Can an attacker reach it?
2. Is exploitation practical or only theoretical?
3. What process does the asset support?
4. What happens if exploitation succeeds?
5. Which compensating controls already exist?
6. What operational risk does patching introduce?
7. Who owns the residual risk if we do not patch?

That last one is the most important, and usually the only one nobody answers.

Why this holds up outside your own organisation too

NIS2 explicitly asks, in Article 21, for vulnerability handling as part of your measures. What a regulator or auditor wants to see is not an empty list, because that does not exist, but a traceable decision per vulnerability: what did you know, what did you weigh, what did you decide, who owns it, when do you look again.

That is exactly what this approach produces. Not as a by-product of compliance, but because it is how you work responsibly in an OT environment without shutting down your own production.

Further reading

• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS: Exploit Prediction Scoring System
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: CVSS v4.0
• ISA: ISA/IEC 62443 series of standards
• CyberBusters: A VLAN is not an IEC 62443 segmentation strategy

If you want to get this sharp with your own team, the PECB IEC 62443 training covers the risk approach this decision process rests on.