What is patch management?
Patch management is the structured process by which an organisation inventories, assesses, tests, deploys and verifies software, operating system, firmware and security updates, so that known vulnerabilities are remediated on time without disrupting operations. In IT environments (servers, workstations, applications) patching is a monthly routine. In OT environments with PLCs, SCADA, HMIs and DCS systems it is harder: availability and safety come first, vendors must approve patches before use, and many systems can no longer be updated at all. Patch management is therefore one part of broader vulnerability management: if you cannot patch, you have to control the risk in another way.
🎯 Why is patch management important?
- Closing known gaps - attackers exploit vulnerabilities that already have a CVE and a patch far more often than zero-days
- Stopping Malware and ransomware - WannaCry (May 2017) exploited an SMBv1 flaw for which Microsoft had released patch MS17-010 two months earlier, and halted plants at Renault and Nissan among others
- Stability and reliability - patches also fix bugs and memory leaks
- Compliance - NIS2, ISO 27001 (control A.8.8, management of technical vulnerabilities), IEC 62443 and the BIO all require demonstrable vulnerability handling
- Fewer incidents and less downtime - preventive maintenance costs less than recovery after an incident and supports incident response
🔄 How does patching differ between IT and OT?
| Aspect | IT | OT |
|---|---|---|
| Priority | Confidentiality and speed | Availability and functional safety |
| Cadence | Monthly (Patch Tuesday), critical patches within days | Planned maintenance window or shutdown, sometimes once or a few times a year |
| Approval | Own IT department | System vendor must qualify the patch |
| Reboot | Usually acceptable outside office hours | Can stop production or a continuous process |
| System lifetime | 3–5 years | 15–25 years or longer |
| Testing | Pilot group, automated rollout | Test system or digital twin, manual rollout per node |
| Firmware | Limited (BIOS, network equipment) | Large share: PLCs, I/O modules, switches, SIS |
The core difference: in IT an unpatched system is often the biggest risk, while in OT a poorly tested patch can itself cause a production or safety incident.
🧱 What does the patching process look like?
- Inventory of assets - an up-to-date asset inventory with firmware and software versions; an SBOM shows which components a product contains
- Vulnerability intake - vendor advisories (for example Siemens ProductCERT, which publishes on the second Tuesday of each month), the CISA KEV catalogue, NCSC advisories and vulnerability scans
- Risk assessment and prioritisation - combine severity (CVSS), likelihood of exploitation (EPSS, KEV) and exposure of the system
- Vendor approval - check whether the OEM or system vendor has qualified the patch for your version of the operating system
- Testing - first on a test system, spare system or redundant node
- Planning through change management - change request, maintenance window, rollback plan and a current backup
- Deployment to production - phased, with process operators informed
- Verification - confirm the patch is active and the process runs normally; follow logging and alarms
- Documentation and reporting - record patch status and exceptions for configuration management and audits
📊 How do you prioritise patches by risk?
CVSS measures the technical severity of a vulnerability, not the risk to your organisation. Good prioritisation combines several signals:
| Signal | What it tells you | Typical value or threshold |
|---|---|---|
| CVSS (v3.1 / v4.0) | Technical severity | Critical 9.0–10.0; high 7.0–8.9; medium 4.0–6.9 |
| EPSS (FIRST) | Probability of exploitation in the next 30 days | Probability between 0 and 1; version 4 since March 2025 |
| CISA KEV | Proven active exploitation | Listed in the catalogue: always takes precedence |
| Exposure | Reachable from the internet, office network or only locally? | Internet-facing or DMZ systems first |
| Process impact | Consequence of failure or manipulation | Systems with an SIS or critical production rank higher |
On 10 June 2026 the US agency CISA replaced directive BOD 22-01, with its fixed KEV deadlines of two weeks for recent CVEs, with BOD 26-04. The new directive makes the deadline depend on exposure, active exploitation, automatability and technical impact, ranging from three days to “fix on system upgrade”. That matches OT practice: a critical CVE on an isolated HMI can wait for the next shutdown, while an actively exploited vulnerability in a remote access gateway needs immediate attention.
🔐 Which obstacles make patching in OT difficult?
| Obstacle | Explanation |
|---|---|
| Legacy systems | HMIs, engineering stations and historians often run unsupported Windows versions (XP, 7 and, since October 2025, most Windows 10 editions) |
| Vendor certification | The system vendor tests Microsoft and other patches for compatibility; an unapproved patch can void support or warranty |
| Production continuity | A reboot often means a process interruption; patching waits for a planned shutdown |
| Firmware on controllers | PLCs run proprietary firmware; an update often requires stopping the controller and retesting the application |
| Safety and validation | Changes to an SIS fall under IEC 61511; in pharmaceuticals revalidation under GMP applies |
| Offline systems | No internet connection; patches travel via a controlled route or scanned media |
🛡️ What do you do when you cannot patch?
When a patch is unavailable, not yet approved or can only be installed at the next shutdown, you apply compensating controls following the principle of defence in depth:
- Network segmentation - place the system in a separate zone with strict firewall rules and a conduit upwards
- Application whitelisting - only allow known software to run; this works well on static OT systems
- Hardening - disable unused services and protocols, such as SMBv1
- Restricted access - remote access only through a jump server with MFA
- Monitoring - an OT IDS detects exploitation attempts against unpatched systems
- Replacement - plan the migration of systems that no longer receive updates
IEC 62443-2-1:2024 recognises this explicitly: within its component security element the standard requires both patch management and mitigation for components that are no longer supported. Record every exception in a risk register with an owner and a review date.
📜 Which standards and laws set patch management requirements?
| Framework | What it requires |
|---|---|
| IEC TR 62443-2-3:2015 | Technical report on patch management in IACS, with roles for asset owner and vendor and an exchange format for patch information |
| IEC 62443-2-1:2024 | Security programme for asset owners, including patch management and mitigation for unsupported components |
| IEC 62443-2-4 | Requirements for system integrators and service providers, including delivering and testing patches |
| NIS2 / Dutch Cybersecurity Act | Article 21 requires security in maintenance and vulnerability handling; the Dutch law (Cyberbeveiligingswet) has applied since 15 August 2026 |
| Cyber Resilience Act | Manufacturers provide free security updates throughout a support period of, as a rule, at least five years; reporting obligations since 11 September 2026, fully applicable from 11 December 2027 |
| ISO 27001:2022 | Control A.8.8: identify and address technical vulnerabilities in a timely manner |
| NIST SP 800-40 Rev. 4 | Treats patching as preventive maintenance planned jointly by leadership and technical teams |
The CRA partly shifts responsibility to the manufacturer: every security update must remain available for at least ten years (or the rest of the support period if longer), and the end date of the support period must be stated at the time of purchase, so you can compare products on it.
🏭 How do you set up patch management in an OT environment?
A workable approach for a Dutch or European production site:
- Roles - agree who does what: IT often manages the Windows servers, OT the controllers and the vendor the qualification; without coordination between IT, OT and suppliers, systems fall through the cracks
- Policy - define per zone how quickly patches are assessed (for example within 14 days) and installed (next maintenance shutdown, or immediately for KEV status combined with exposure)
- Supplier contracts - require patch qualification, an SBOM and a stated support period in purchasing and maintenance contracts, in line with supplier security
- Patch repository in the DMZ - approved patches sit on an intermediate server in the DMZ, never pulled directly from the internet
- Tools - Microsoft Configuration Manager (formerly SCCM) or WSUS (deprecated since September 2024 but still supported) for Windows; ManageEngine or Ivanti for multi-platform patch management; Qualys or Tenable for detecting missing patches; Claroty, Nozomi or Dragos for visibility of OT assets and vulnerabilities; vendor portals from Siemens and Rockwell Automation for approved patches
- KPIs - mean time to patch per priority, percentage of assets patched within the agreed deadline, number of open exceptions and share of systems without vendor support
❓ Frequently asked questions
How often should you patch OT systems?
There is no fixed frequency: OT systems are usually patched in planned maintenance windows, ranging from monthly for redundant servers to yearly or less for continuous processes. Patch management in OT therefore puts risk ahead of cadence. Actively exploited and reachable vulnerabilities take precedence, and the rest follows at the next shutdown.
What is the difference between patch management and vulnerability management?
Vulnerability management is the broader process of finding, assessing and treating all vulnerabilities. Patch management is one treatment option within it: installing an update. When patching is not possible, vulnerability management chooses compensating controls or risk acceptance instead.
Can I install a Windows patch myself on a SCADA server?
Only if the vendor of the SCADA or DCS system has approved that patch for your software version. Vendors such as Siemens and Rockwell Automation publish compatibility lists for Microsoft updates. An unqualified patch can disrupt operation and void support or warranty.
What is IEC TR 62443-2-3?
IEC TR 62443-2-3 is a 2015 technical report on patch management in industrial automation and control systems. It describes the tasks of asset owners and vendors and a standard format that vendors use to communicate patch information and compatibility. It is guidance, not a certifiable standard.
What does the Cyber Resilience Act change for patch management?
The Cyber Resilience Act requires manufacturers of products with digital elements to provide free security updates throughout the support period, which as a rule must be at least five years. Since 11 September 2026 they must also report actively exploited vulnerabilities. For asset owners, patchability therefore becomes a hard purchasing requirement.
What is Patch Tuesday?
Patch Tuesday is the second Tuesday of each month, when Microsoft releases its monthly security updates. OT vendors such as Siemens and Schneider Electric publish their security advisories on the same day, so asset owners can plan patch management around one fixed date. For OT systems, Patch Tuesday does not mean installing straight away: the system vendor’s qualification comes first.
📌 In summary
Patch management is the risk-driven process of inventorying, prioritising, testing, deploying and verifying updates to keep systems secure, stable and compliant.
In IT it is about speed and automation; in OT it is about vendor approval, maintenance windows and compensating controls where patching is not possible. With IEC 62443, NIS2 and the Cyber Resilience Act, demonstrable patch and vulnerability management is a critical building block of any cybersecurity strategy, particularly in environments with many legacy and OT systems.