Patch Management and Malware Protection in IACS
Risk-based patching and malware protection that respects industrial availability and safety constraints.
Learning objectives
- Explain why OT patching is a risk decision rather than a speed contest.
- Build a traceable patch decision process.
- Assign responsibilities across asset owner, integrator and product supplier.
- Select compensating controls when an update cannot be deployed.
Introduction
This module addresses vulnerability treatment without overlooking operational constraints.
Planned video lesson
Video lesson coming soon. The written module can be completed without the video.
Planned recording: 9-11 minutes making a patch decision for the Riverside engineering workstation, including a delayed-patch compensating-control case.
Transcript will be added with the video.
Main lesson
Patching controls two different risks
Installing an update may reduce exposure to a vulnerability, but it can also introduce:
- Loss of vendor support.
- Application or driver incompatibility.
- Changed communications.
- Unplanned restart.
- Loss of validated configuration.
- Performance or timing problems.
- Failure of redundancy or recovery.
Not installing it may leave a known path to compromise. A sound process compares both risks against the actual asset, exposure and consequence.
IEC TR 62443-2-3 provides guidance for patch management in IACS environments. The principle is a controlled lifecycle, not “patch everything immediately” or “never patch OT”.
A practical patch workflow
| Step | Decision or evidence |
|---|---|
| 1. Receive | Authoritative advisory, update and affected versions |
| 2. Identify | Installed asset, firmware, software, dependencies and owner |
| 3. Assess applicability | Is the vulnerable feature present, enabled and reachable? |
| 4. Assess consequence | What can exploitation cause, and what can update failure cause? |
| 5. Obtain supplier position | Tested combinations, prerequisites, known issues and support statement |
| 6. Select treatment | Deploy, mitigate, isolate, monitor, replace or accept risk |
| 7. Prepare | Backup, restoration proof, test environment, outage, rollback and communications |
| 8. Test | Functional, performance, communications, security and recovery checks |
| 9. Deploy | Approved change with configuration control |
| 10. Validate | Confirm process operation, security function and version |
| 11. Record and monitor | Close evidence, exceptions and post-deployment observations |
Prioritise with OT context
A vulnerability score is an input, not the decision. Consider:
- Exploit preconditions.
- Network and physical exposure.
- Privileges required.
- Whether the affected feature is enabled.
- Existing boundary and endpoint controls.
- Process consequence.
- Availability of a tested update.
- Ability to detect exploitation.
- Recovery time and replacement options.
A lower-scored vulnerability on an exposed remote gateway may deserve action before a higher-scored issue on an isolated, unused service.
Compensating controls
When patching is delayed or impossible, options include:
- Disable the vulnerable service or feature.
- Restrict peers, ports and functions.
- Remove internet or enterprise reachability.
- Strengthen identity and remote-access controls.
- Add application allowlisting.
- Monitor for specific exploit behaviour.
- Increase backup and restoration assurance.
- Replace the asset or create a funded obsolescence plan.
Compensating controls need an owner, verification and expiry or review date. “Vendor does not support patching” is a constraint, not a completed treatment plan.
Malware protection is broader than antivirus
OT malware controls may combine:
- Application allowlisting.
- Supported endpoint protection.
- Controlled removable media.
- Managed engineering laptops.
- Secure software repositories and integrity checks.
- Restricted email, web and person-to-person messaging.
- Network segmentation and egress control.
- Least privilege.
- Tested backups and golden images.
- Passive detection.
Endpoint agents must be tested for compatibility, resource use and support. An unsupported security agent can create as much operational risk as the threat it is intended to reduce.
Responsibilities
- Product supplier: publish advisories, affected versions, update guidance, dependencies and a secure delivery method.
- System integrator / maintainer: assess integrated compatibility, test, deploy under change control and update the configuration baseline.
- Asset owner: own risk priority, outage decision, residual risk, operational acceptance and long-term asset strategy.
Planned original figure — M12-F01
Create a patch decision flow from advisory and asset match through risk assessment, vendor validation, test, deployment, rollback and residual-risk review.
Planned asset: /static/training/ot-cyber-security/module-12/figure-01.svg
Engineering example
Riverside application
Riverside cannot patch blindly or ignore vulnerabilities. Each decision must balance exposure, process consequence, update risk and compensating controls.
Practical activity
Apply what you learned
Assume a high-severity advisory affects a service on the engineering workstation. The vendor update needs a reboot and has not yet been validated with the PLC software.
Write a decision record covering:
- Applicability and current exposure.
- Process consequence.
- Short-term controls.
- Vendor evidence required.
- Test and rollback method.
- Outage approval.
- Deadline and residual-risk owner.
Record your reasoning and project notes here. Your response stays in this browser and is not submitted to the website.
Loading saved response…
0 / 10,000Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.
Knowledge check
Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.
Key takeaways
Remember these points
Patch priority depends on installed exposure and process consequence as well as vulnerability severity.
A compensating control needs an owner, verification method and expiry or review date.
The asset owner’s authorised risk owner accepts residual operational risk.
Relevant standards and guidance
This module uses original explanatory language. Consult the applicable editions and project requirements rather than treating this lesson as normative text.
- IEC TR 62443-2-3
- NIST SP 800-82 Rev. 3
Further reading
- IEC TR 62443-2-3:2015 — Patch management in the IACS environment
- NCSC — Vulnerability management guidance
- CISA — Industrial Control Systems advisories
- CISA — Known Exploited Vulnerabilities Catalog
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
Last reviewed
15 July 2026.
Complete the knowledge check above and answer every question correctly to unlock module completion.
Progress is stored only in this browser and is not a certificate or formal training record.