The short answer
Risk-Based Patching
Risk-based patching ranks vulnerabilities by what would happen in this plant: how reachable the vulnerable component is, whether the vulnerability is being exploited, and what its exploitation would do to the process, and it assigns each a tier with a target timeline. Internet-facing and remotely reachable components with exploited vulnerabilities are patched within days; control network servers with high consequence in the next monthly cycle; components reachable only from the engineering zone at the next planned outage; and controllers and devices on their own firmware process, often with a compensating control instead of a patch. Every vulnerability not patched on time has a compensating control and a review date, and every accepted risk is written down with the reasoning and reviewed until it is retired or resolved.
Key points
- Rank by exposure, exploitation, and consequence in this plant; the severity score is one input.
- Tiers with timelines: days for the exposed edge, the monthly cycle for servers, the planned outage for the isolated, never for some devices with controls in place.
- Servers, network equipment, and controllers follow different processes; the ranking is the same.
- A compensating control buys time and is recorded with the vulnerability it covers.
- Accept is a decision with a name, a reason, and a review date, not a default.
- The list of what has not been patched is reviewed quarterly; it is the real risk register.
Why not patch everything
An office patches everything because patching is cheap and the cost of a broken application is a helpdesk ticket. A control system patches selectively because every patch carries a chance of stopping the plant, every controller firmware update needs an outage, and some devices cannot be patched at all. The choice is not whether to patch but what to patch first and what to protect another way, and the choice has to be made on the basis of risk in the plant rather than on the score in the advisory, or the utility spends its outage windows on printers while the remote access gateway waits.
The ranking
| Factor | Question | Where the answer comes from |
|---|---|---|
| Exposure | Who can reach the vulnerable component: the internet, the office, the control network, only the engineering zone, only by physical access | The segmentation design, the firewall rules, and the inventory |
| Exploitation | Is the vulnerability in the exploited catalog, does public exploit code exist, is the vendor reporting attacks | The advisory and the exploited catalog |
| Consequence | What does exploitation do: stop a controller, take over the SCADA, read data, crash a printer; and what process depends on the component | The asset criticality and the risk assessment |
| Ease | Does exploitation require credentials, user interaction, or a specific configuration | The advisory attack vector and complexity |
Tiers
| Tier | Criteria | Target | Process |
|---|---|---|---|
| Emergency | Reachable from the internet or the office, or exploited and reachable from the control network with high consequence | Days; compensating control within hours if the patch is not qualified | The emergency path in patch management |
| Next cycle | Reachable from the control network with high or medium consequence, not exploited | The next monthly cycle | Patch management |
| Planned outage | Reachable only from the engineering zone, or requires an outage to apply | The next planned outage for that process, within a year | Firmware management for devices; patch management for servers |
| Compensating control | No qualified patch, or the device cannot be patched, or the outage is not available | Control in place within the cycle; patch or replacement scheduled | Compensating controls with a review date |
| Accept | Not reachable by anyone who could exploit it and consequence is low | Reviewed quarterly | A written decision |
By component type
- Servers and workstations
- Patched through the monthly cycle with vendor qualification, and through the emergency path for the exposed tier. The largest volume of patches and the most tolerant of them.
- Network equipment
- Firewalls facing outward are the exposed tier; internal switches and radios are patched quarterly or on advisory, with a configuration backup and a window, since a switch update drops the connected devices for minutes.
- Controllers and remote units
- Firmware updates need an outage, a backup, a test, and sometimes a program conversion; they are grouped and scheduled at planned outages, and compensating controls carry the risk between. Some advisories on controllers have no fix, and the answer is the control and the replacement plan.
- Drives, instruments, and appliances
- Rarely patched; the vulnerable interface is usually a web page or a protocol port that segmentation can restrict. Firmware updated when the device is serviced.
- Software that cannot be updated
- Isolated, allowlisted, monitored, and on a replacement plan; the accept decision is explicit and reviewed.
Review
Accepted and mitigated vulnerabilities do not stay accepted forever. The quarterly review asks whether the exposure has changed, whether the vulnerability has since been exploited, whether a patch has become available, and whether the compensating control is still in place and still working. Items whose review date has passed are re-decided. The annual risk assessment reads the whole list and asks whether the pattern says something: a vendor whose products are always in the compensating control tier is a vendor to reconsider.
Frequently asked questions
- Is it acceptable to never patch a controller?
- It is common, and it is acceptable when the controller is reachable only from the engineering zone, its exposed services are disabled, changes to it are detected, and the decision is written down and reviewed. It is not acceptable as an unexamined default. Many controllers also gain features and fixes from firmware that are worth an outage for other reasons.
- How do we decide consequence for a shared component like a switch?
- By what depends on it: a core switch carries every process, so its consequence is the highest of anything connected to it. The inventory criticality of network equipment is inherited from what it serves.
- The advisory says critical and our ranking says planned outage. Will an auditor accept that?
- If the record shows the exposure analysis, the consequence, the compensating control, and the review date, yes; that is what risk-based patching means and what the frameworks describe. What an auditor will not accept is a critical advisory with no record at all.
- How many open items is too many?
- There is no number; there is a trend. A list that grows every quarter means the cycle is not keeping up or the accept tier is being used as a place to put things. A list that turns over, with items closed by patches and replacements, is a program that is working.
Related topics
- Advisories and AlertsWhere a utility learns its equipment has a known vulnerability and what to do with the news: the government and vendor advisory feeds, the sector center, the exploited catalog, subscribing by product, a weekly triage on exposure and consequence, and records.
- Compensating ControlsWhat to do about a vulnerability that cannot be patched now or ever: restricting who can reach it, disabling the service, blocking dangerous protocol functions, allowlisting, monitoring, physical and procedural controls, matched to the attack path.
- Patch ManagementApplying updates to SCADA servers and clients without breaking the plant: vendor qualification, a monthly cycle with a test system, priority from the exposed edge inward, backups and rollback, emergency patches, and handling software that cannot be patched.
- Firmware ManagementUpdating the firmware of controllers, modules, drives, HMIs, switches, and radios without breaking the plant: why firmware lags and why it still matters, tracking versions, deciding what to update and when, and the update as a planned outage with a rollback.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
- Documenting Firmware VersionsWhy the firmware version of every controller, module, drive, switch, radio, and instrument belongs in the inventory with the date it was read: advisories are issued by version. Where to read each one, the several versions one controller has, and the cadence.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.