In operational technology, "just patch it" is rarely an option. Controllers run for decades, vendors must qualify every update, and downtime is scheduled months ahead. OT vulnerability management is therefore less about patching fast and more about deciding which risks matter, reducing them with compensating controls, and tracking what remains.
The Problem in Real Environments
A typical OT site carries a long tail of known vulnerabilities: Windows-based HMIs and engineering workstations on older builds, historians tied to a specific database version, PLCs and RTUs running firmware with published advisories, and network devices that have not been updated since commissioning. Many of these assets cannot be patched quickly, for reasons that are legitimate:
- Vendor qualification: the control system vendor supports only specific OS and patch combinations. Applying an unqualified patch can void support or break the application.
- Maintenance windows: many processes run continuously, so firmware updates and reboots wait for a planned outage, sometimes once or twice a year.
- Certification and validation: in regulated sectors such as pharmaceuticals or safety systems, a change may trigger revalidation.
- No fix exists: the product is end of life, or the weakness is a design property, such as an industrial protocol with no authentication.
Meanwhile, vulnerability scanners and advisories keep producing findings. Teams end up with spreadsheets of hundreds of CVEs, no clear priority, and a sense that the problem is unmanageable.
Why Common Approaches Fail
- Prioritizing by CVSS score alone. CVSS base scores describe the vulnerability in the abstract. They do not tell you whether the asset is reachable, whether exploitation is happening, or what happens to the process if it is exploited.
- Applying IT patch cadence to OT. Monthly patch cycles pushed from an enterprise tool to OT hosts cause outages and, after the first incident, a loss of trust between IT and operations.
- Active scanning without care. Aggressive network scans have been known to disrupt fragile controllers. Asset and vulnerability data in OT should come mainly from passive monitoring, vendor inventories and configuration exports, with active queries used selectively and with operations approval.
- Treating "cannot patch" as "accept the risk". Without compensating controls and a record of residual risk, an unpatched system is simply ignored.
Risk-Based Triage: Exposure, Exploitability, Consequence
The goal of triage is to sort findings into a small number of action categories. Assess each vulnerability, or group of similar vulnerabilities, on three axes.
Exposure
How reachable is the vulnerable service? A flaw in a historian web interface that is reachable from the corporate network is far more urgent than the same flaw on an isolated cell controller with no routed path. Consider:
- Which zone the asset sits in, and what conduits connect that zone to less-trusted networks.
- Whether the vulnerable port or protocol is actually allowed through the boundary firewalls.
- Remote access paths, including vendor connections, cellular modems and jump hosts.
- Whether exploitation needs local access, such as removable media or a logged-in user.
Exploitability
Is the vulnerability being exploited, or is it likely to be? Useful signals include CISA's Known Exploited Vulnerabilities (KEV) catalog, CISA ICS advisories, vendor security notices, the Exploit Prediction Scoring System (EPSS) for IT-type software, and threat intelligence relevant to your sector. A known-exploited flaw in a remote access appliance at the IT/OT boundary should move to the top of the list regardless of its base score.
Consequence
What happens to the process if the asset is compromised? This is the axis IT tools cannot answer, and it needs operations and engineering input. Loss of view on a non-critical utility system is different from unauthorized writes to a controller that manages pressure, temperature or dosing. Link consequence to the zone's security level target and to the site's process hazard analysis where one exists. IEC 62443-3-2 provides a structured method for this kind of zone-level risk assessment.
Turning the axes into actions
| Category | Typical profile | Action |
|---|---|---|
| Act now | Exposed to less-trusted networks, known exploited, high consequence | Immediate compensating controls; emergency change or next available window for the fix |
| Next window | Reachable within OT, credible exploit path, moderate to high consequence | Qualify patch with vendor; schedule for the next maintenance window; interim controls |
| Mitigate and monitor | Low exposure or no fix available | Compensating controls, monitoring rules, residual risk recorded |
| Track | Not reachable, low consequence | Address during planned upgrades; review periodically |
CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) uses a similar decision-tree logic and is worth reviewing if you want a documented, repeatable method.
Vendor Qualification of Patches
Most control system vendors publish lists of tested and approved patches for their platforms, usually lagging the OS vendor's release by some weeks. Build your process around that reality:
- Subscribe to each vendor's security notification channel and patch qualification list, and record which assets each list applies to.
- Include patch qualification and security notification obligations in support contracts and new procurements. IEC 62443-2-4 sets out requirements for service providers, and IEC 62443-4-1 covers the product supplier's secure development lifecycle, including security update management.
- Test qualified patches on a representative test system or a virtual replica before production. If you have no test system, start with the least critical redundant node.
- Keep rollback ready: a golden image or snapshot taken immediately before the change, plus the verified controller backup.
IEC TR 62443-2-3 addresses patch management in the IACS environment specifically, covering the asset owner's and the vendor's roles in the patch lifecycle. It is a useful reference when negotiating responsibilities with suppliers.
Maintenance Windows
Treat maintenance windows as a scarce resource and plan security work into them, rather than competing with mechanical work at the last minute.
- Maintain a rolling list of security changes waiting for each window, ranked by triage category.
- Bundle firmware updates, OS patches, configuration hardening and backup verification into the same window to reduce the number of restarts.
- Coordinate with operations and maintenance planners early, since outage schedules are often fixed months ahead.
- Use redundancy where it exists: patch the standby server or controller, fail over, verify, then patch the primary.
- Document what was not completed in a window and why, so it carries forward rather than disappearing.
Compensating Controls
When a patch is not available or not yet possible, compensating controls reduce the likelihood or impact of exploitation. They are not a permanent substitute for fixing the vulnerability, but in OT they often carry most of the risk reduction for years.
Segmentation and conduit restriction
Place vulnerable assets in zones with tightly defined conduits, aligned with IEC 62443-3-3 SR 5.1 (network segmentation). Restrict which hosts can reach the vulnerable service, ideally to a named set of engineering workstations or servers. Remove direct routes from IT to Level 1 and Level 2 assets, and force all access through a DMZ and jump hosts.
Application allow-listing
On Windows-based HMIs, engineering workstations and servers, allow-listing prevents unapproved executables from running and is usually a better fit than signature-based antivirus for static OT hosts. It supports SR 3.2 (protection from malicious code). Coordinate with the vendor, test in audit mode first, and plan how approved updates will be added to the allow-list.
Protocol filtering
Industrial firewalls and deep packet inspection can restrict industrial protocols by function, for example allowing read operations from the historian while blocking writes and program downloads except from approved engineering stations. This is particularly valuable for protocols that lack authentication by design.
Hardening and access control
- Disable unused services and ports on vulnerable hosts and devices.
- Control removable media with scanning kiosks and device control policies.
- Use controller key switches or software run-mode locks where available, so logic cannot be changed remotely during normal operation.
- Require MFA, approval and session recording for vendor and engineering remote access, and disable it when not in use.
Monitoring
Passive OT network monitoring, aligned with SR 6.2 (continuous monitoring), turns an unpatched vulnerability into something you can watch. Build specific detections for each high-risk unpatched asset: new connections to the vulnerable service, program downloads or firmware changes outside change windows, and new remote access sessions. A compensating control without a corresponding detection is much weaker than one paired with an alert someone actually reviews.
Tracking Residual Risk
Every vulnerability that is not fixed needs a record. Without one, compensating controls drift, exceptions become permanent, and nobody knows what risk the organization is carrying.
A practical residual risk record includes:
- The asset, zone and vulnerability (or group of vulnerabilities).
- The triage category and the reasoning behind it.
- The compensating controls in place, and how each was verified.
- The planned fix and target window, or a statement that no fix is available.
- The risk owner, normally an operations or asset owner rather than the security team.
- A review date, with re-triage triggered earlier if the vulnerability appears in KEV or a new exploit is published.
Review the register with operations and engineering at a fixed interval, and report the trend upward: how many act-now items exist, how long they have been open, and how many rely on compensating controls alone.
Implementation Checklist
- Build an asset inventory with firmware, OS and application versions, using passive discovery and vendor data.
- Map assets to zones and conduits so exposure can be assessed consistently.
- Subscribe to vendor and CISA ICS advisories and match them to the inventory.
- Define triage categories using exposure, exploitability and consequence, with operations input on consequence.
- Agree on patch qualification and notification obligations with each key vendor.
- Plan security work into every maintenance window, with rollback ready.
- Apply segmentation, allow-listing, protocol filtering and monitoring for assets that cannot be patched.
- Keep a residual risk register with named owners and review dates.
Common Mistakes
- Measuring success by the total number of open CVEs rather than by exposure of high-consequence assets.
- Deploying compensating controls once and never verifying they still work after network changes.
- Forgetting network and security appliances at the IT/OT boundary, which are often both exposed and patchable.
- Leaving vendor remote access permanently enabled because it is convenient for support.
- Assigning residual risk ownership to security staff who cannot make operational trade-offs.
Where to Start
Start at the boundary. Identify every system reachable from IT or the internet, including remote access appliances, DMZ servers and historians, and make sure those are patched or tightly controlled. Then pick your highest-consequence zone, triage its vulnerabilities on exposure, exploitability and consequence, and put compensating controls and a residual risk record in place for anything you cannot fix this year. That gives you a defensible position quickly and a method you can extend across the rest of the site.