Every IT security team has a patch management process. Monthly patch cycles, automated deployment, rollback procedures. It works reasonably well for Windows servers and endpoint devices.
OT teams can't do any of that. The constraints are fundamentally different.
Why Standard Patch Management Fails in OT
Uptime requirements are different. A Windows server can be rebooted at 2am on a Tuesday. A PLC running a production line cannot. Many OT environments run 24/7 with planned maintenance windows measured in hours per quarter, not per month.
Vendor validation requirements. Many ICS vendors explicitly require that firmware and software updates are validated by the vendor before deployment. Applying an unvalidated patch to a Siemens S7-1500 or a Schneider Modicon can void your support agreement or, worse, cause unexpected behaviour in a process that nobody fully understands anymore.
Air-gapped or semi-isolated networks. Automated patch deployment tools assume network connectivity. Most OT networks are air-gapped or have highly restricted connectivity. Updates are applied manually, via USB, or through a strict change management process.
Legacy equipment. A significant portion of ICS deployments run software versions that are beyond end-of-life. No patches are coming. Ever. The equipment will outlive every IT system in the building.
The result is that OT patch management is inherently a risk management exercise rather than a deployment exercise. The question isn't "have we applied the patch?" — it's "do we understand the risk of not patching, and have we mitigated it appropriately?"
What a Realistic OT Patch Process Looks Like
Given these constraints, a workable ICS patch management process has five steps:
1. Identify relevant vulnerabilities.
Monitor CISA ICS-CERT advisories and vendor-specific security publications for vulnerabilities affecting your equipment. This needs to happen continuously — not just quarterly. New critical vulnerabilities are published every week.
2. Assess applicability and severity.
Not every advisory affects your specific equipment version. Check whether your deployed firmware/software version is in the affected range. Check the CVSS score and KEV status (whether it's been actively exploited in the wild).
3. Evaluate patch availability.
Is a patch actually available? Some ICS vendors take months to release patches after a vulnerability is disclosed. If no patch exists, move directly to mitigation.
4. Apply or mitigate, with documentation.
If a patch is available and testable, schedule it for the next maintenance window. If patching isn't possible (no window, no validated patch, end-of-life hardware), document a compensating control: network segmentation, disabling affected services, increased monitoring.
5. Track to closure.
Record when each advisory was identified, what decision was made, what mitigation was applied, and when the patch was eventually deployed (if ever).
The Monitoring Problem
Steps 1 and 2 are where most OT teams fall down, not because they lack the skill but because they lack the time. CISA publishes 400-600 ICS advisories per year. Your environment might use equipment from 10-20 vendors. Manually cross-referencing advisories against your asset inventory every week is a significant time investment.
The practical alternatives:
- Subscribe to everything — CISA mailing list, every vendor security newsletter. You'll receive hundreds of advisories per month, most irrelevant. Alerts will be ignored within weeks.
- Check manually — Bookmark cisa.gov, check periodically. Miss things when someone is on leave. Create audit trail gaps.
- Filter automatically — Maintain a watchlist of your specific vendors and products. Only receive alerts when something matches. Track everything.
The third approach is what OTWarden provides. You specify which vendors and products you care about, and we send you an email within 2 hours when CISA publishes something that matches. You get the advisory ID, severity, CVSS score, affected versions, and remediation steps — everything you need to complete steps 2 and 3 of your process immediately.
Documentation for Audits and Compliance
Whether you're under NERC CIP, IEC 62443, NIS2, or simply following NIST SP 800-82, you'll need to demonstrate a documented vulnerability management process. That documentation starts with evidence of monitoring — proof that you identified the advisory, and when.
An email timestamp is a start. A monthly report listing every matched advisory, with dates and severity classifications, is better. OTWarden Professional and Team plans include a monthly PDF report suitable for use as compliance evidence.
If you'd like to see what filtered ICS vulnerability alerts look like in practice, there's a 14-day free trial at otwarden.com.