OT Patch Management for PLCs Explained: Why You Can't Patch Like IT in 2026

Diagram of a four-branch OT patch management decision tree for PLCs, showing whether a discovered vulnerability gets scheduled for the next maintenance window, escalated to the vendor's certified patch cycle, addressed with a virtual patch, or handled with a permanent compensating control for end-of-life equipment.

You can't patch a PLC the way you patch a laptop because taking a safety-critical controller offline outside a scheduled maintenance window is itself an availability and safety risk — not just an inconvenience. Add proprietary industrial protocols and equipment that stays in service far longer than typical IT hardware, and a patch that IT could push in a day can realistically take a plant weeks or months to schedule. When the timeline genuinely can't be compressed, the documented answer isn't to leave the asset exposed — it's a compensating control, usually virtual patching, applied until the real patch can go in safely.

Quick Facts

Question Answer
Why can't you just patch a PLC on IT's schedule? Because taking a safety-critical controller offline mid-shift is itself an availability/safety risk — patches have to wait for a scheduled maintenance window
How many ICS vulnerabilities were disclosed in 2025? 2,155 CVEs across 508 ICS advisories — the first year advisories topped 500 (Forescout)
What do you do when a patch can't be applied in time? Deploy a compensating control — usually virtual patching (protocol-aware IPS/firewall rules) — until the real patch can be scheduled
What standard governs OT patch management? IEC TR 62443-2-3:2015, "Patch management in the IACS environment" — a Technical Report (guidance), not a normative, certifiable requirement
How fast do attackers move after a CVE goes public? SecurityWeek's Cyber Insights 2026 ICS coverage describes the disclosure-to-exploitation window as collapsing, driven partly by AI-assisted exploit tooling — reported gaps vary by tracking methodology, from hours for actively weaponized zero-days to multi-week medians in broader vulnerability datasets, but a quarterly maintenance window can still leave an asset exposed for months

Why OT Patch Cycles Aren't Like IT's

The gap between IT and OT patch management isn't a cultural problem — it's structural. An IT patch SLA might require a critical fix within days because rebooting a server during a low-traffic window is routine and reversible. A PLC controlling a physical process doesn't get that luxury: taking it offline mid-shift can itself trigger a safety event or a production stoppage, so the patch has to wait for a planned maintenance window, which might be weekly, quarterly, or tied to an annual shutdown depending on the plant.

Equipment lifespan compounds the problem. OT equipment routinely stays in service far longer than typical IT hardware. Rockwell Automation's own guidance on machinery safety control systems uses 20 years as a default assumption for useful lifetime, while the broader installed base of general-purpose OT/ICS equipment is commonly reported in the 15-30-year range, with some legacy installations still running 30+ years past commissioning depending on the equipment class (Rockwell Automation, "Useful Lifetime of a Machinery Safety Control System"; ManufacturingTomorrow). A PLC installed in the 2000s may still be running a control-system OS and firmware version that the original vendor no longer actively patches, on a proprietary protocol (Modbus, DNP3, OPC, EtherNet/IP) that generic IT patch-management tooling was never built to inspect or update (ManufacturingTomorrow).

Put together: IT can treat "patch fast" as a solved workflow problem. OT has to treat every patch decision as a scheduling and risk-tradeoff problem, asset by asset — which is exactly why a decision framework, not a blanket SLA, is the practical way to run an OT patch program.

IT Patch Management vs. OT Patch Management

Aspect IT Patch Management OT Patch Management
Typical patch SLA Days for critical vulnerabilities Tied to the next scheduled maintenance window — weeks to a full quarter, sometimes longer
Equipment lifespan Usually replaced every 3-5 years Commonly 15-30 years in service (Rockwell Automation's 20-year default assumption for safety control systems is a widely used baseline); some legacy installations run 30+ years
Protocols/tooling Standardized OS and network stack, mature patch-management platforms Proprietary industrial protocols that generic IT patch tools handle poorly or not at all
Downtime tolerance A scheduled reboot is routine and low-risk Unplanned downtime can itself be a safety or production-loss incident
Vendor authorization Rarely a blocking factor Applying a patch outside vendor-certified procedures can raise warranty or support-agreement concerns — Rockwell Automation, for example, advises against installing Microsoft updates until it has qualified them, and its standard terms of sale exclude coverage for alteration or modification by parties other than Rockwell

The 2026 Vulnerability Numbers Driving the Urgency

The case for having a real patch decision process, rather than an informal "get to it eventually" approach, comes from how fast the ICS vulnerability landscape has grown. Forescout's "ICS Cybersecurity in 2026" report counted 2,155 CVEs across 508 ICS advisories in 2025 — the first year advisory volume topped 500 — with average advisory severity (CVSS) climbing above 8.0 in 2024-2025, up from an average of 6.44 back in 2010 (Forescout; corroborated by Infosecurity Magazine).

The attacker side of the equation is moving faster too. SecurityWeek's "Cyber Insights 2026" coverage of industrial control systems describes the disclosure-to-exploitation window as actively collapsing, with AI-assisted exploit tooling compressing the gap between a CVE going public and a working exploit circulating (SecurityWeek, Cyber Insights 2026). There's no single agreed-upon industry number for exactly how long that gap is — different vulnerability-tracking methodologies report anything from a matter of hours for the fastest-weaponized zero-days to multi-week medians across broader datasets — but every recent tracking source points in the same direction: shrinking, not growing. Put next to a plant that only gets one maintenance window per quarter, the math is uncomfortable: an asset can sit exposed to a public exploit for months after a patch already exists, simply because the next safe opportunity to apply it hasn't arrived yet. That gap is exactly why a compensating-control answer has to exist for the interim period, not just a patch-or-nothing decision.

The OT Patch Decision Tree

There isn't one universal answer to "what do you do when a CVE drops against your PLC fleet" — the right move depends on whether a patch exists, whether it can be safely scheduled, and whether the vendor allows independent patching at all. This is the practical decision framework that maps onto IEC TR 62443-2-3's patch-lifecycle concepts:

Situation Recommended action
1. Patch exists and can be safely applied in the next maintenance window Schedule it — test in an isolated/sandbox environment first before pushing to production
2. Patch exists, but vendor certification or warranty terms block independent application Escalate to the vendor's own certified patch cycle; track the asset as an open risk item until the vendor-issued patch lands
3. Patch exists, but the asset is safety-critical or high-uptime with no acceptable window in the near term Deploy a compensating control (virtual patching or tighter segmentation) as the primary control now; apply the actual patch at the next planned outage
4. No patch exists at all — end-of-life platform, vendor has discontinued support The compensating control is the permanent answer, not a stopgap; flag the asset for replacement planning

Branch 1 lines up with the general guidance in NIST SP 800-82 Rev. 3, "Guide to Operational Technology (OT) Security" — test updates in a non-production/sandbox environment, schedule deployment into a maintenance window, and have a rollback plan ready before pushing to production. This guidance runs throughout the publication's risk-management and configuration-management discussion rather than living in one single numbered "patch management" section, so it's cited here as the document's general practice, not a specific clause (NIST SP 800-82 Rev. 3). Branches 3 and 4 are where most of the actual OT patch-management work happens in practice, because a meaningful share of the installed base never reaches branch 1 on any realistic timeline.

Virtual Patching: The Compensating Control That Actually Works

Virtual patching is the standard answer for branches 3 and 4 above — it's the mechanism, not just a concept, for what "compensating control" means in an OT context. Instead of modifying the vulnerable device itself, virtual patching puts a protocol-aware intrusion prevention system or firewall rule in front of it that recognizes and blocks the specific exploit pattern for that CVE at the network layer, for protocols like Modbus, DNP3, OPC, and EtherNet/IP (Fortinet, virtual patching glossary). The device keeps running unmodified; the exploit path gets closed off from the network instead.

This is also where OT patch management stops being a standalone topic and becomes a network-design topic. A virtual patch is only as good as the segmentation it sits inside — if the vulnerable PLC lives on a flat network with unrestricted access from every other zone, one IPS rule in front of it doesn't do much. The zones-and-conduits spoke in this cluster covers exactly how that segmentation gets designed — a filtering conduit placed at a zone boundary is the practical location where a virtual patch actually gets enforced, so the two pieces are meant to be read together rather than as separate concerns.

IEC TR 62443-2-3: What It Actually Says (and Doesn't)

The formal reference point for OT patch management is IEC TR 62443-2-3:2015, titled "Patch management in the IACS environment" (ISA catalog listing). The "TR" in the name matters: it's a Technical Report, not a normative requirements part like IEC 62443-3-2 or 3-3. That distinction affects how "compliance" language should be used here — an organization can build a patch-management program that follows this document's guidance, but it isn't a certifiable requirement in the same sense as the normative parts of the 62443 series. Practically, it functions as a structured reference for how to run a patch program (vendor patch qualification, testing, deployment scheduling, and tracking unpatched exposure) rather than a checklist an auditor certifies against.

Tracking Patch Status Alongside Your Asset Inventory

None of the decision-tree branches above are usable without knowing what's actually running on the network in the first place — which PLC models, which firmware versions, which vendor support status. That's the same asset-visibility problem the OT asset management spoke in this cluster walks through in detail. In practice, patch status (patched / awaiting vendor cycle / compensating control in place / flagged for replacement) is a field that belongs directly in that same asset inventory, next to criticality — not tracked in a separate spreadsheet that drifts out of sync with what's actually deployed.

Vendor Warranty and Certification Friction

One recurring practitioner concern is that applying a security patch — especially to a third-party OS component embedded in OT equipment — without the original vendor's authorization can void the equipment's warranty or violate a service agreement. This isn't just secondhand practitioner lore: Rockwell Automation's own Microsoft Patch Qualifications guidance advises customers not to apply or install Microsoft updates until Rockwell has "fully qualified" them against its software, and Rockwell's standard Terms and Conditions of Sale exclude warranty coverage for products affected by "alteration or modification by other than Seller" (Rockwell Automation, Microsoft Patch Qualifications; Rockwell Automation, Terms and Conditions of Sale). That's a named-vendor policy pattern, not a universal contractual guarantee across every OT vendor and every equipment class — exact terms vary by manufacturer and service agreement — but it confirms the underlying mechanism practitioners describe is real rather than folklore. Whatever the exact contractual mechanics on a given piece of equipment, the practical effect is the same either way: it's a real reason branch 2 of the decision tree above exists as a separate path from branch 1, and it's one more argument for having a compensating control ready rather than waiting on a vendor's own patch-release timeline.

When Patching Alone Wasn't Enough

The manufacturing ransomware case studies documented in this cluster include incidents where an exploited, unpatched vulnerability was part of the attack chain — and where, in hindsight, a compensating control at the network layer would have closed the gap even without the patch being applied yet. This decision framework is the piece that was missing from that picture: a way to decide, before an incident happens, whether an unpatched asset needs a compensating control now or can safely wait for the next maintenance window.

FAQ

Q: Why can't OT teams just patch a PLC the way IT patches a server?
A: Because taking a safety-critical PLC offline outside a planned maintenance window is itself an availability and safety risk, not just downtime. Add proprietary protocols that generic IT patch tools don't handle well and equipment that stays in service far longer than typical IT hardware, and a patch IT could deploy in a day can take an OT environment weeks or months to schedule safely.

Q: What is virtual patching, and how does it work when a real patch can't be applied?
A: Virtual patching puts a protocol-aware intrusion prevention system or firewall rule in front of the vulnerable device that blocks the specific exploit pattern for a given CVE at the network layer — for protocols like Modbus, DNP3, OPC, and EtherNet/IP — without modifying the device itself. It's the standard compensating control used until the actual patch can be safely scheduled or, for end-of-life equipment, as a permanent substitute for a patch that will never exist.

Q: What is IEC 62443-2-3, and is it a mandatory requirement or guidance?
A: IEC TR 62443-2-3:2015, "Patch management in the IACS environment," is a Technical Report — guidance on how to structure a patch-management program, not a normative, certifiable requirement like the IEC 62443-3-2 or -3-3 parts. An organization can build its program around it, but it isn't something an auditor certifies against in the same way.

Q: Can applying a security patch void a PLC vendor's warranty or support agreement?
A: Yes, on some equipment — this isn't just practitioner folklore. Rockwell Automation, for example, advises against installing Microsoft updates until it has qualified them, and its standard terms of sale exclude warranty coverage for "alteration or modification by other than Seller." Exact terms vary by vendor and service agreement, but the underlying risk is real and is one of the main reasons an unpatchable-by-policy asset gets routed to a compensating control instead of an independent patch.

Q: How often should an OT patch management program reassess unpatched or end-of-life assets?
A: There's no single universal cadence, but the practical pattern is to reassess unpatched and EOL assets on the same cycle as the broader asset inventory and risk review — commonly quarterly or at each maintenance-window planning cycle — since a compensating control that was adequate for a given CVE and network layout can stop being adequate as new vulnerabilities are disclosed against the same asset class.

Sources

Author Bio

The Whitepaper Skeptic has direct experience with OT cybersecurity in industrial and smart-factory environments, including customer-facing security architecture reviews where an unpatched PLC or HMI finding routinely turned into exactly this triage question — schedule the patch, escalate to the vendor, or stand up a compensating control at the network boundary — using the same zone/conduit segmentation covered in the sibling spoke below.

Related Posts

Comments

Post a Comment

Popular posts from this blog

OT Security Vendor Comparison 2026: Dragos vs. Claroty vs. Nozomi Networks for Industrial Environments

Image
Dragos, Claroty, and Nozomi Networks were all named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms — so "which one is best" isn't the right question, because Gartner didn't rank a single winner among them. The real decision driver is environment fit: Dragos leans strongest on ICS-specific threat intelligence and managed detection for concentrated, high-criticality sites; Claroty covers the broadest scope across OT, IoT, building systems, and medical devices; and Nozomi Networks offers the most flexible deployment options for large, multi-site, geographically distributed operations. This guide builds a vendor-neutral decision matrix around those differences instead of repeating any vendor's self-reported ranking. Quick Facts Question Answer Are all three Gartner Leaders? Yes — Dragos, Claroty, and Nozomi Networks were three of only four vendors named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms, out o...
Read more

HBM Burn-In Testing Explained: Why Known-Good-Die Screening Now Happens Before Stacking (2026)

Image
HBM burn-in and known-good-die (KGD) testing means every individual memory die is electrically stressed and screened at the wafer level — before it's thinned, singulated, or stacked — instead of waiting to find defects only after a finished HBM stack fails final test. The reason this matters is economic, not just technical: a single bad die inside an 8-to-16-high HBM stack can force the entire stack to be scrapped, and HBM now accounts for roughly half the total cost of an AI accelerator package. That's why HBM makers and test-equipment vendors have visibly shifted testing "left" — earlier in the manufacturing flow — rather than relying on final test alone to catch problems. By The Whitepaper Skeptic — yield-economics work on an advanced-packaging project, plus HBM test-equipment tracking Quick Facts Question Answer What does "known-good-die" (KGD) mean? A die individually tested and verified to mee...
Read more

CoWoS and Hybrid Bonding Explained: TSMC's Advanced Packaging Behind AI Chips

Image
CoWoS (Chip-on-Wafer-on-Substrate) is TSMC's 2.5D advanced packaging platform — it places a large logic die, like an AI accelerator or GPU, next to multiple HBM memory stacks on a shared interposer, all inside one package. Hybrid bonding is a different thing entirely: a bump-less, direct copper-to-copper die-to-die (or die-to-wafer) bonding technique used for 3D stacking. They are not competing options, even though a lot of existing coverage frames "CoWoS vs hybrid bonding" as an either/or choice — CoWoS is a packaging platform, hybrid bonding is a bonding technique, and TSMC increasingly combines both inside the same package, most visibly in Nvidia's newest AI accelerator platforms. Quick Facts Question Answer What is CoWoS? TSMC's 2.5D packaging platform that places a large logic die and HBM stacks side-by-side on a shared interposer What is hybrid bonding? A bump-less, direct copper-to-copper die-to-die/die-to-waf...
Read more