Patching and Vulnerability Management in OT

Why patching OT is hard

In IT, the default answer to a vulnerability is "patch it", and monthly patch cycles are routine (see vulnerability management). In operational technology the same answer runs into obstacles that are not laziness but physics, contracts and safety.

• Downtime. Installing a firmware update on a programmable logic controller (PLC) usually means stopping it, and stopping it stops the process it controls. In a power grid, taking a substation's controls out of service may require a planned outage and a different grid configuration; in a chemical plant it may wait for the yearly shutdown.
• Safety. A change to a safety instrumented system or to protection equipment may need its safety function verified again before it returns to service (see safety and reliability).
• Vendor qualification. Many control systems are only supported in a configuration the vendor has tested.
• Age. Systems stay in service for decades, and some run on operating systems or hardware that no longer receive updates at all.
• Risk of the patch itself. An update that changes timing or behavior can disturb a process that has run unchanged for years.

Vendor qualification

Vendor qualification is the testing and approval by a control system vendor that a patch, for example a Windows security update for the servers and human-machine interfaces (HMIs) of its supervisory control and data acquisition (SCADA) product, works correctly with its system. Vendors typically publish lists of qualified updates, often some time after the operating system vendor released them. Installing an unqualified patch can void support or, worse, break the system, so asset owners usually wait for qualification and plan around that delay.

ICS advisories

An ICS advisory is a published notice about a vulnerability in an industrial control product: the affected products and versions, a description and severity, often a CVE identifier and CVSS score (see CVE and CVSS), and the vendor's fix, workaround or recommended mitigations. The main sources:

• CISA, the US Cybersecurity and Infrastructure Security Agency, publishes ICS advisories continuously, numbered in the format ICSA-YY-DDD-NN, covering products from many vendors.
• Vendor PSIRTs (product security incident response teams): most large automation vendors publish their own advisories, often with more detail on affected versions and workarounds than anyone else.
• National CSIRTs: in the Netherlands, NCSC-NL publishes security advisories and, under the Cyberbeveiligingswet, shares threat information with the entities registered with it. In the United Kingdom the NCSC is the national CSIRT; in the United States, CISA (above) fills that role.

An advisory is only actionable if you can answer "do we have this, in this version, and where?" within hours. That is the job of the asset inventory: vendor, model and firmware version per device. Without it, every advisory starts a search through cabinets and spreadsheets.

Prioritizing with OT context

The general rule from IT applies even more strongly in OT: severity is not priority (see prioritizing beyond the score). The CVSS base score describes a vulnerability in the abstract; it knows nothing about where the device sits or what it controls. For OT, four questions change the picture:

• Exploitability: is it being exploited (for example, listed in CISA's Known Exploited Vulnerabilities catalog), is exploit code public, and does it need authentication or local access?
• Exposure: can it be reached from the internet, from the office network, only from inside its OT zone, or not over the network at all?
• Consequence: what is the worst physical outcome: lost data, loss of view or control of the process, or an effect on safety?
• Compensating controls: what already stands in the way, such as segmentation, allow-listing, or a controller's key switch locked in the RUN position?

Example: CVSS alone versus OT context

This sketch ranks five fictitious advisories twice: by CVSS base score, and by a simple OT-adjusted score that multiplies the CVSS score by factors for exposure, consequence and known exploitation, and lowers it for each working compensating control. The weights are invented for illustration; they are not a standard.

# Rank fictitious ICS advisories by CVSS alone and by an OT-adjusted score.
ADVISORIES = [
    # id, CVSS base, known exploited, exposure, worst consequence, compensating controls
    ("ADV-01 historian web UI", 9.8, False, "it-reachable", "data", ["segmented"]),
    ("ADV-02 remote-access gateway", 8.1, True, "internet", "control", []),
    ("ADV-03 PLC firmware", 7.5, False, "isolated", "control", ["segmented", "key switch in RUN"]),
    ("ADV-04 safety controller", 6.5, False, "ot-internal", "safety", []),
    ("ADV-05 engineering software", 7.8, True, "ot-internal", "control", []),
]

EXPOSURE = {"internet": 1.5, "it-reachable": 1.2, "ot-internal": 1.0, "isolated": 0.6}
CONSEQUENCE = {"data": 0.8, "control": 1.2, "safety": 1.5}


def ot_score(cvss, exploited, exposure, consequence, controls):
    score = cvss * EXPOSURE[exposure] * CONSEQUENCE[consequence]
    if exploited:
        score *= 1.5
    score *= 0.85 ** len(controls)   # each working control lowers the likelihood a bit
    return round(score, 1)


print("By CVSS alone:")
for name, cvss, *_ in sorted(ADVISORIES, key=lambda a: -a[1]):
    print(f"  {cvss:4.1f}  {name}")

print("By OT-adjusted score:")
ranked = sorted(ADVISORIES, key=lambda a: -ot_score(*a[1:]))
for name, cvss, exploited, exposure, consequence, controls in ranked:
    score = ot_score(cvss, exploited, exposure, consequence, controls)
    line = f"  {score:4.1f}  {name:<30} {exposure:<12} {consequence:<7}"
    print((line + " exploited") if exploited else line.rstrip())

By CVSS alone:
   9.8  ADV-01 historian web UI
   8.1  ADV-02 remote-access gateway
   7.8  ADV-05 engineering software
   7.5  ADV-03 PLC firmware
   6.5  ADV-04 safety controller
By OT-adjusted score:
  21.9  ADV-02 remote-access gateway   internet     control exploited
  14.0  ADV-05 engineering software    ot-internal  control exploited
   9.8  ADV-04 safety controller       ot-internal  safety
   8.0  ADV-01 historian web UI        it-reachable data
   3.9  ADV-03 PLC firmware            isolated     control

CVSS puts the historian's web interface first, at 9.8. With OT context it drops to fourth: it is segmented and its worst outcome is lost data. The exploited flaw in the internet-facing remote access gateway, only 8.1 in CVSS, moves to the top, because it is a door into OT that attackers are already using. The safety controller, lowest by CVSS, rises above the historian because its consequence is safety. Real programs use richer models, such as decision trees that combine exploitation status, exposure and impact on the mission, but the lesson is the same: the score is an input, not the answer.

Compensating controls

A compensating control is a measure that reduces the risk of a vulnerability in another way while the fix itself cannot be applied: it makes the vulnerability harder to reach, harder to exploit, or quicker to notice. In OT, compensating controls are not a stopgap; for many systems they are the main defense for years. Common ones:

• Segmentation and firewall rules: allow only the specific hosts and protocols the device needs, so the vulnerable service cannot be reached from elsewhere (see segmentation).
• Removing internet exposure: the first of CISA's primary mitigations for OT, and in 2026 again the root of attacks on internet-exposed PLCs.
• Allow-listing on HMIs and engineering workstations, so only approved programs can run (see application control).
• Disabling unused services, such as a controller's built-in web server or file transfer service that nobody uses.
• Physical protections: on many PLCs a key switch in the RUN position blocks remote program changes; CISA's 2026 advisory on manipulated PLCs recommends using it.
• Monitoring focused on the vulnerable service, so an attempt to exploit it is noticed (see asset inventory and monitoring).

Record the decision as an exception, as described in compensating controls and exceptions: which vulnerability, why it cannot be fixed now, which controls apply, who accepted the remaining risk, and when it will be reviewed. An exception without a review date tends to become permanent.

Maintenance windows and change management

Patches in OT are installed as planned changes, through the same change enablement process as any other modification of the installation, in a maintenance window agreed with operations (see the change schedule). In a grid, that window often follows the outage planning: a bay or substation's equipment can be updated when the grid can do without it. Redundancy helps: with duplicated SCADA servers or redundant controllers, the standby can be patched first, then made active, and the other patched afterward.

A good OT patch change includes:

• a current backup of the configuration and controller logic, so the known-good state can be restored;
• a tested rollback plan, including how long it takes;
• the people who can restore the process on site or on call;
• checks afterward: does the process behave as before, do the HMI values update, are the versions in the inventory updated?

Testing patches

Testing reduces the risk of the patch itself. The usual stages: the vendor's qualification; a test in your own lab or test bench with the same hardware, firmware and configuration as the field; and a first installation on a less critical or standby system, observed for a while before the rest follows. A test environment that resembles production is an investment many asset owners make for exactly this reason, and it doubles as a safe place to practice recovery.

End-of-life systems

An end-of-life system is a product that its vendor no longer supports with security updates or repairs, such as an HMI on an operating system that went out of support years ago, or a controller model whose firmware will never be updated again. In OT these systems are common, because the equipment they control may be good for decades more (see end of support).

Long-term strategies, usually combined:

• Contain: put the system in its own zone with tightly restricted conduits, allow-listing and monitoring, and remove anything it does not need.
• Extend: buy extended support where the vendor offers it, and secure spare parts before they disappear from the market.
• Plan replacement: include security support in lifecycle planning and budgets, so replacement is scheduled years ahead, aligned with planned outages or other renovation, instead of forced by a failure.
• Buy better: require a declared support period and security updates when purchasing new equipment, so today's purchase is not tomorrow's problem.

Firmware integrity

A patch is software that you are about to install deep inside the control system, so it must be the genuine one. Download firmware and patches only from the vendor's official source, and check the published hash or the vendor's digital signature before use (see hash functions). Newer devices verify signed firmware themselves and refuse an image that was altered.

Integrity checking does not stop after installation. Compare the firmware versions and controller programs in the field with the known-good versions in your inventory and backups; an unexplained difference is a security event, as the inventory comparison on the monitoring page shows. Stuxnet, which modified PLC logic while showing operators normal values, is the classic reason to verify what is really running (see threats and notable incidents).

The Cyber Resilience Act and vendors

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) changes the supplier side of the equation. It applies to products with digital elements sold in the EU, which includes much industrial equipment and software. It entered into force on 10 December 2024; manufacturers' obligations to report actively exploited vulnerabilities and severe incidents apply since 11 September 2026, and the main obligations apply from 11 December 2027.

For asset owners, the effect is mostly in procurement: products placed on the market under the main obligations come with vulnerability handling and security updates during a declared support period. It does not retrofit security onto the installed base: the main requirements do not apply to the PLC you bought in 2012, although its manufacturer must still report actively exploited vulnerabilities in it since 11 September 2026. See OT regulation for the full picture, and governance, frameworks and compliance for the CRA in general.

The United States and the United Kingdom have no equivalent law for industrial products. There, procurement requirements such as IEC 62443-4-1 (secure development) and, in US electricity, the NERC CIP-013 supply chain standard do this job. Vendors based there must still meet the CRA for what they sell in the EU.