"The SCADA server is working - don't touch it" is how industrial systems end up running five-year-old software with published, exploitable vulnerabilities. But the IT answer - patch everything monthly, reboot at will - is equally wrong in a plant where a reboot can mean lost production or a safety review. Real SCADA vulnerability management is a triage discipline: know what you have, decide which CVEs actually matter in your architecture, apply compensating controls where you cannot patch yet, and use maintenance windows, redundancy, and vendor-managed platforms to patch without stopping the process. This guide gives you that workflow, plus the questions to ask any SCADA vendor about their own patch cadence.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
IT vulnerability management is a volume game: scan everything, patch on a monthly cycle, reboot overnight, done. Three OT realities break that model:
This is why NIST SP 800-82 Rev. 3 - the reference playbook for OT security - frames OT patching as a risk-managed process with testing, scheduling, and documented alternatives, not a compliance treadmill, and why NIST SP 800-40 Rev. 4 reframes enterprise patching as preventive maintenance driven by risk rather than a race to zero. For the broader cultural divide, see OT vs IT security differences.
Every vulnerability program starts with an asset inventory, and most OT organizations discover theirs is fiction the first time they check. You need, per asset: make, model, firmware/software version, network location (zone), who owns it, and what it does to the process. Sources that work in practice:
Keep the inventory alive: a stale inventory quietly rots into uselessness within a year. Make "update the asset record" a mandatory step in your management-of-change process.
Subscribe to CISA's ICS advisories and your vendors' security bulletins, and hundreds of advisories a year will land in your inbox. The mistake is ranking them by CVSS score alone. A 9.8-critical CVE on a device that is unreachable from any network an attacker can occupy may be a calendar item; a 6.5-medium on your internet-facing historian API is an emergency. Triage each advisory with four questions:
Record the decision for every advisory - even when the decision is "not affected" or "accepted until October turnaround." Auditors, insurers, and your own future incident reviews all want the same artifact: evidence that each known vulnerability got a decision, an owner, and a date.
For each vulnerability that survives triage, you have five legitimate responses. The skill is matching response to context:
| Response | When to Use | Downtime | Residual Risk |
|---|---|---|---|
| Patch immediately (emergency) | KEV-listed or actively exploited, and the asset is reachable from IT or internet | Yes - planned emergency window | Low once applied |
| Patch at next window | Real but not urgent; asset behind solid segmentation | Rides existing maintenance window | Bounded by compensating controls until then |
| Compensating controls | Patch exists but window is distant, or patching needs revalidation | Usually none | Reduced, not eliminated - document it |
| Virtual patch (IPS/DPI shield) | No patch available, or asset is end-of-life | None after deployment | Protects only known exploit patterns at inspection points |
| Accept and monitor | Negligible exploitability in your architecture | None | Documented, reviewed on a schedule - never silent |
Compensating controls reduce a vulnerability's exploitability without touching the vulnerable system - which is why they are the workhorse of OT programs. The usual moves: tighten conduit firewall rules so the vulnerable service is unreachable from any attacker-occupiable network, disable the vulnerable feature, restrict which accounts and workstations can reach the asset, move it to a smaller zone, and point focused monitoring at the paths an exploit would take. The ISA/IEC 62443 standards and NIST SP 800-82 both treat documented compensating controls as legitimate - the operative word being documented: vulnerability, control, residual risk, and remediation date, written down.
Virtual patching puts an intrusion-prevention system or industrial firewall with deep packet inspection in front of the vulnerable asset, blocking traffic that matches known exploit signatures for the CVE. It is genuinely useful for the unpatchable tail of your fleet - end-of-life PLCs, OS versions your application vendor will not certify past. Its limits are structural: it stops only known patterns, only on traffic crossing the inspection point. Pair it with segmentation, and keep the asset on the replacement roadmap.
When you do patch, four techniques keep production running:
Here is the honest accounting for cloud SCADA. The supervisory layer - application servers, databases, web stack - becomes the vendor's continuous responsibility. Done well, that removes your worst chronic exposure: the aging, internet-adjacent Windows server nobody dares to reboot. You keep responsibility for everything inside the fence: PLCs, RTUs, local HMIs, network gear, engineering workstations. The trade is favorable precisely when the vendor's own practice is strong - which makes vendor patch discipline a primary buying criterion, not a footnote. What good looks like:
These pipeline properties are the buyer's defense against supply-chain risk too - the subject of our software supply chain security guide. The architecture side matters as much as cadence: a platform whose gateway is outbound-only, per the model in our secure SCADA for OT networks guide, has structurally less attack surface to patch in a hurry. Merobix documents both sides on its security page.
PLC and device firmware deserves its own, slower loop: review OEM advisories quarterly, prioritize devices reachable from routable networks, bundle firmware updates into turnarounds, and always capture a verified program backup before touching a controller. Most controller advisories are mitigated in the interim by the same compensating controls above - which is one more argument for getting segmentation right first. Our PLC hardening checklist covers the device layer in full.
Key takeaway: OT vulnerability management is not "patch everything" - it is decide everything. Every advisory that touches your inventory gets a decision, an owner, and a date: patch now, patch at the window, compensate, shield, or formally accept. Exposure and exploitability set priority, not raw CVSS. And when you buy cloud SCADA, you are buying the vendor's patch discipline as your own - demand continuous releases, build visibility, signed updates, and a blocking release pipeline. See how Merobix answers those questions in a guided demo.
Four techniques, usually combined: schedule patches into existing maintenance windows and turnarounds so security rides along with planned downtime; use redundant server pairs so you patch the standby, fail over, then patch the former primary; stage patches in a test or simulation environment first so the production window is short and predictable; and apply compensating controls - segmentation, access restrictions, monitoring - to hold risk down until the window arrives. Cloud SCADA changes the equation for the supervisory layer, because the vendor patches the platform continuously without customer downtime, leaving you to manage only the OT-side assets.
No. IT-style patch the fleet monthly SLAs assume reboots are cheap, which is false in a plant. OT patching should be risk-ranked instead: exposure and exploitability decide urgency, not CVSS score alone. A critical CVE on an internet-reachable system deserves emergency action; the same CVE on a controller isolated behind a firewalled conduit with no route from IT may reasonably wait for the next maintenance window behind compensating controls. NIST SP 800-82 explicitly endorses this risk-based approach for industrial systems. What is not defensible is having no process at all - every known vulnerability should have a decision, an owner, and a date recorded.
Compensating controls reduce the exploitability of a vulnerability you cannot yet patch, instead of removing the flaw itself. Common examples: tightening firewall rules so the vulnerable service is unreachable from any network an attacker can occupy, disabling the vulnerable feature or service, restricting which accounts can reach the system, adding monitoring and alerting focused on the vulnerable path, and placing the asset in a smaller, more isolated network zone. Frameworks such as IEC 62443 and NIST SP 800-82 treat documented compensating controls as a legitimate response - auditors expect to see the vulnerability, the control, the residual risk, and the eventual remediation date written down.
Virtual patching places a network security device - typically an intrusion-prevention system or an industrial firewall with deep packet inspection - in front of a vulnerable asset, configured to block traffic patterns that match known exploit attempts against that CVE. The asset itself stays unpatched, but the exploit cannot reach it. It is valuable in OT because many devices cannot be patched promptly, or ever: end-of-life PLCs, vendor-locked HMI servers, systems awaiting a revalidation window. Treat it as a bridge, not a destination - it protects only against known signatures, only on traffic that crosses the inspection point.
Continuously - a healthy cloud vendor ships small, tested updates on a weekly-or-faster rhythm rather than quarterly big-bang releases, and applies critical dependency fixes on an emergency track measured in days, not months. What buyers should verify: a documented vulnerability-handling and disclosure process, dependency and static-analysis scanning in the release pipeline, visibility into exactly what build is running, and gateway updates that are signed and verified before installation. Merobix operates on this model - the platform is vendor-patched with build and Git-SHA visibility of deployed services, gateway artifacts are signed with update verification, and its release-assurance program is adding blocking dependency, static-analysis, and secret checks so a release cannot ship unless every check is green.
Continuous vendor-managed patching, signed gateway updates, build-level visibility of every deployed service, and an outbound-only architecture with less surface to patch in the first place.