Patching vs. Compensating Controls: An OT Decision Framework
OT patch management fails not because operations teams are obstructionist, but because the assumptions underneath IT patch doctrine do not hold. Patches arrive late or not at all. Applying them requires production downtime. And patching one component does not close the network path that allowed an attacker to reach it. This guide provides a decision framework for making the patch-versus-compensating-control call deliberately, documenting it defensibly, and building the review process that keeps open findings from accumulating indefinitely.
The core tension
IT patch management assumes you can update software on a defined cycle without asking permission from the plant floor. Three things break that assumption in OT.
OT vendors lag disclosed vulnerabilities by months, and end-of-life hardware may never receive a fix. Roughly 30% of OT vulnerabilities have no vendor patch at the time of disclosure.
Applying a patch may require taking a production line offline. The maintenance window may be months away. A failed OT firmware update can leave equipment in a worse state than the vulnerability it was meant to address.
A backlog of open findings that neither team owns. IT security escalates. Operations refuses. Nothing gets documented. This guide is the framework for getting out of that loop.
The friction matrix
The friction matrix is a structured comparison of the true cost of patching versus the true cost of applying a compensating control for a given vulnerability. It forces the decision into the open before the IT team escalates and the operations team digs in.
Patching cost components
| Cost element | What to assess |
|---|---|
| Planned downtime | Duration of outage required. Whether a maintenance window is available or must be scheduled. Production impact in hours and dollar terms. |
| Vendor validation | Whether the vendor has tested the patch in your exact hardware/firmware combination. Whether applying an untested patch voids support. |
| Labor | Internal engineering time to apply, test, and verify. Vendor professional services if required. |
| Rollback risk | Whether a failed patch can be rolled back, and what the procedure is. Legacy systems often have no rollback path. |
| Requalification | Whether the patched system requires functional testing or regulatory requalification before returning to service. |
Compensating control cost components
| Cost element | What to assess |
|---|---|
| Control effectiveness | Does the compensating control actually block the attack path for this vulnerability, or does it reduce exposure without eliminating it? |
| Implementation effort | Firewall rule changes, microsegmentation policy updates, or virtual patching rule deployment. One-time cost. |
| Ongoing maintenance | Firewall rules require review. Microsegmentation policies must track network changes. This is a recurring cost. |
| Audit defensibility | Will an auditor accept this compensating control as equivalent to patching for compliance purposes? For NERC CIP and NIS2, the answer varies by standard and finding. |
| Residual risk | The compensating control reduces risk but does not eliminate it. What is the residual exposure? |
The friction matrix is not a spreadsheet that produces a score. It is a structured conversation that forces IT security, operations, and compliance to agree on what each option actually costs before the decision is made.
Patch or compensate: the decision criteria
- The patch is vendor-validated for your hardware and firmware version
- A maintenance window exists or can be scheduled at acceptable production cost
- The vulnerability has a credible exploitation path in your environment, not just a high CVSS score in the abstract
- Patching closes the attack path, not just the finding
- No patch exists or the system is end-of-life
- Downtime cost is prohibitive relative to the risk for this specific vulnerability
- The maintenance window is months away and interim risk reduction is needed
- The system requires regulatory requalification after patching, making the patch cycle more disruptive than the vulnerability itself
The documented rationale is what you show the auditor — not just the open finding or the closed ticket. A well-documented compensating control is defensible. An undocumented patching refusal is not.
Virtual patching
Virtual patching is the use of a network-layer control — typically an industrial next-generation firewall or an intrusion prevention system with OT protocol awareness — to block known exploitation of a vulnerability without modifying the vulnerable system itself.
A virtual patch works by inspecting traffic destined for the vulnerable system and blocking packets that match known exploit patterns for the specific CVE. The underlying vulnerability remains, but the attack path is closed at the network layer.
- Provides immediate risk reduction while the patch cycle is scheduled
- Works on systems where patching is not possible (end-of-life, no patch available)
- Does not require system downtime or vendor involvement
- Creates an audit trail — the firewall log documents that the exploitation path was actively blocked
- Does not fix the vulnerability. A zero-day or new exploitation technique may not be covered by existing signatures.
- Does not work against lateral movement within the same network segment
- Requires the firewall vendor to have released a signature for the specific CVE — coverage varies by vendor and disclosure recency
Virtual patching implementation requirements
| Requirement | Detail |
|---|---|
| OT protocol awareness | The firewall must decode industrial protocols to distinguish legitimate traffic from exploit traffic. A standard IT firewall blocking all Modbus traffic is not virtual patching — it is service disruption. |
| Passive deployment option | The firewall must be configurable in detection-only mode before enforcement is enabled, to verify it does not block legitimate OT traffic. |
| Signature currency | Vendor must provide timely signature updates for OT-specific CVEs, not just IT vulnerabilities. |
| Logging and alerting | Blocked exploitation attempts must be logged and must generate alerts. Blocked and silent is not sufficient for audit purposes. |
Building the decision framework
The decision framework is the documented process your organization uses to make and record the patch-versus-compensating-control decision for each finding. It exists so the decision is not made informally under pressure, and so the rationale is available when the auditor asks.
Every OT vulnerability finding enters a triage process before any remediation decision is made. Triage answers three questions:
- Does this vulnerability have a credible exploitation path in our environment?
- What is the operational impact of patching?
- Is a compensating control available that effectively addresses the attack path?
Triage should involve IT security, OT engineering, and operations. A finding that IT security escalates without OT engineering input will either result in a patch that breaks something, or a refusal with no documented rationale.
CVSS scores are calculated without reference to your environment. Rescore each finding against your actual exposure:
| Factor | Questions to answer |
|---|---|
| Network reachability | Can an attacker reach this system from the internet, from the IT network, or only from within the OT segment? |
| Authentication requirement | Does exploitation require authenticated access? What is the strength of your access controls? |
| Existing compensating controls | Are there controls already in place that partially mitigate this attack path? |
| Asset criticality | What is the consequence of this asset being compromised or unavailable? |
For every finding, document:
- — The vulnerability: CVE, affected system, CVSS score
- — The environmental risk score and the factors that drove it
- — The decision: patch, compensating control, or accept risk
- — If compensating control: what control, who implemented it, when, and what residual risk remains
- — If accept risk: the business justification and who signed off
- — The review date: when will this decision be revisited?
Decisions made under the framework are not permanent. Set a review date for every open finding:
- Compensating controls are reviewed when the vendor releases a patch, when network topology changes, or on a defined cycle — quarterly for high-severity findings, annually for medium
- Accepted risk findings are reviewed annually and require re-sign-off
- Any finding that appears in an active threat campaign moves to immediate triage regardless of its scheduled review date