A critical vulnerability is published for software running on a plant segment that will not be patched for nine months. What do you do in the meantime?

Severity is the wrong first question

A published severity score is calculated for a generic deployment, and its assumptions are mostly about an asset reachable from a hostile network by an unauthenticated attacker. That is not the situation you are in, and treating the score as the priority means you will spend the week on something unexploitable while a lower-scored issue on an engineering workstation sits untouched.

The first question is reachability. From where can the affected service be addressed at all? What has to be true before an attacker is in a position to try — do they need a foothold in the enterprise zone, a session on a jump host, physical presence, or a specific credential? What does the vulnerability actually let them do on that asset: run code, read memory, crash the process? A denial of service on a controller is not a minor finding here, because the process consequence of that component stopping may be larger than data being read from it, which inverts the ranking a general-purpose scoring model would give you.

Answer those and you usually find one of three shapes. The asset is not reachable from anywhere outside its zone, in which case the finding is real but the exposure is conditional on a prior compromise, and it is handled through hardening the path. Or it is reachable from a zone that itself has broad access, which makes it urgent this week. Or, most often, nobody can tell you, which is its own finding.

The inventory problem, and why scanning is not free

You cannot assess exposure for an asset list you do not have, and plant asset inventories are usually stale, partly manual and incomplete in a specific way: the devices somebody added during a project three years ago are the ones missing. So the honest first action is frequently to find out what is there.

The instinct from IT is to scan, and here the scan is part of the risk. Some industrial devices have network stacks that were never designed to receive traffic they did not expect, and an aggressive discovery sweep can put a device into a state that requires a manual intervention to leave. So discovery leans on passive methods — mirroring traffic at a switch and identifying devices from what they already say, reading configuration from the engineering project files that define what the controllers are, pulling the device lists that the SCADA and historian configurations already contain, and asking the controls engineers, who often know more than any system does. Where active querying is used it is targeted, gentle, agreed with the site, and done in a window rather than at will.

This work is slower than a scan and it produces something the scan would not: an inventory annotated with what each device does to the process, which is what lets you rank findings by consequence rather than by score.

Move the control off the asset

The asset cannot be changed, so everything you do is around it. Ranked by how much exposure each option genuinely removes, rather than by how easy it is to write in a report:

Remove the path. If the affected service is reachable from a zone that has no requirement to reach it, tighten the conduit until only the specific sources that need it remain, on the specific port. This is the only measure that reduces the attacker population rather than the attacker's success rate, and it is often available because the permissive rule was never a requirement, just a convenience nobody revisited.

Disable or unbind the vulnerable function if the device offers that and the process does not need it. A web configuration interface enabled by default and used once during commissioning is the classic instance.

Patch the neighbours. This is the measure candidates underweight. The unpatchable device is rarely the entry point; it is the destination. The entry point is a Windows HMI on an unsupported build, an engineering laptop that moves between the plant network and a hotel, a historian with a management interface, or a vendor remote-access tool. Those are all patchable, and hardening them attacks the actual attack path. An answer that focuses entirely on the immovable asset and ignores the movable ones around it has optimised for the finding rather than for the risk.

Add detection at the conduit. If the exploit has a recognisable shape — a protocol function code that has no business being used in normal operation, a write to a memory area nothing legitimately writes to — then detecting attempts is worth having, since you cannot prevent them. Detection is not mitigation, and it should not be recorded as if it were.

Mitigating is not remediating, and the register should say so

The distinction matters because of what happens organisationally. Firewalling a vulnerable service does not fix it; it changes who can attempt to exploit it. That is a legitimate control and it must be recorded as a compensating control with the residual risk stated, an owner, and an expiry tied to the actual remediation event — the shutdown window when firmware can be applied, the migration off the unsupported operating system, the equipment replacement in next year's capital plan.

Three things then follow that are more about process than technology. The vendor's position needs to be in writing, because patching may be conditional on their validated configuration and applying it unilaterally can leave you unsupported on equipment you cannot support yourself; that constraint is real and it belongs in the record rather than being argued about later. Where remediation is genuinely years away, someone with authority to accept risk on behalf of production has to accept it explicitly, which is a very different conversation from an engineer quietly deciding it is fine. And the acceptance needs a review date, because the exposure changes without the vulnerability changing — a new integration project, a merged network, a vendor tunnel added for a support contract.

The failure that shows up two years later

The mitigation almost always gets implemented. What almost never happens is verification that it still exists. Firewall rules are edited during unrelated projects, a temporary allow added for a commissioning weekend is not removed, a network is flattened during a plant expansion, and the compensating control that the risk register still cites has quietly not been in force for eighteen months.

So the deliverable is not the rule change. It is the rule change plus a recurring check that the property still holds — a periodic review of the conduit's rule set against its documented intent, and ideally a test that confirms the affected port is unreachable from where it is supposed to be unreachable. Without that, you have not mitigated a vulnerability, you have written a sentence about it.