Why Patching is Not a Panacea in OT Security
Hillstrong Group Security ·
Debunking the Dangerous Illusion of Patch-Centric Protection
Author’s LinkedIn: Roger Hill
The notion that patching is the foundation of all good cybersecurity hygiene has become almost doctrine. It’s a logical and practical approach in the IT world: patches are regularly issued, environments are flexible, and downtime can be managed with limited disruption. But the industrial world doesn’t operate with the same assumptions. When this doctrine is lifted and dropped into operational technology (OT) environments without translation, it sets security programs up to fail. Not because patches are inherently evil but because their role in OT is fundamentally different.
I’ve seen this pattern repeatedly over the years—CISOs and CIOs with enterprise IT backgrounds walk into manufacturing and critical infrastructure environments and assume that patching is a first-order defense strategy. And it’s understandable. It’s what they know. But that assumption quickly collides with reality: fragile legacy systems, certification requirements, tightly coupled production lines, and unforgiving uptime expectations. All of this demands a recalibrated mindset around risk—and the blunt instrument of patching no longer makes sense as the default answer.
The Difference Between Can’t and Won’t
When a system isn’t patched in IT, it’s often seen as negligence or poor hygiene. In OT, unpatched systems are usually the result of informed, risk-based decisions. You don’t patch a SCADA system controlling a multi-million-dollar extrusion line without understanding what a reboot could do. You don’t update PLC firmware mid-shift without accounting for how it affects a plant’s output targets or how it might violate FDA validation.
I’ve sat across from plant operations teams that have been blamed for being “obstructionists” when they push back on patching requests. In truth, they’re often the most risk-aware people in the room—they’re just evaluating risk through physical safety, production loss, and regulatory exposure.
This is why we must stop treating patching as a virtue in and of itself. It is a tool—one of many—and sometimes, it’s wrong.
Why the Patch-Centric Model Breaks in OT
Let’s start with cadence. Patching in IT environments can happen monthly, weekly, or even daily. Vulnerability management systems and patch orchestration tools are designed to work in continuous cycles. OT environments—especially manufacturing and energy—don’t operate on those same clocks.
Patch windows in OT can range from quarterly to annually. In some cases, especially with embedded devices or legacy control systems, patching may not even be technically possible without replacing the device altogether. Even when patches are available, applying them often requires shutting down operations, validating that the update won’t disrupt custom application code, and, in some cases, re-certifying the system altogether.
This makes patching in OT not just a security issue—it’s a business risk decision. That’s a different paradigm. Security leaders must understand that the “availability” in the CIA triad is not just about uptime but revenue continuity, worker safety, and operational trust.
And now we’re facing another wrinkle. In early 2025, the Common Vulnerabilities and Exposures (CVE) program—run by MITRE and used as the backbone for tracking known vulnerabilities—nearly lost federal funding. CISA had to step in to prevent a disruption to the program. The implications of that moment weren’t just bureaucratic. They were a stark reminder: if your entire vulnerability management program hinges on third-party databases or a single stream of patching intelligence, you are building on sand. Even institutional support for foundational cybersecurity programs is not guaranteed.
This reinforces what those of us in the OT trenches already knew. Patching is only one mechanism, and not the most dependable one. The risk decisions we make must outlast funding cycles and agency politics.
If Not Patching, Then What?
This is the real question. We need a credible alternative if we know that patching can’t be the dominant strategy. The answer is layered: a combination of mitigation, segmentation, detection, and risk-informed prioritization.
Some of the most resilient OT environments I’ve assessed didn’t have the highest patch compliance. Still, they had robust network segmentation, tight control over engineering workstations, clear asset visibility, and disciplined change control processes. These made it very hard for a vulnerability to turn into an exploit.
Mitigation strategies include:
- Deploying industrial firewalls and unidirectional gateways to isolate high-risk assets
- Leveraging read-only patching registries for validation before broad deployment
- Creating clear operational playbooks for compensating controls when patching isn’t viable
None of these are revolutionary ideas. But doing the basics well—and consistently—in OT is far more valuable than chasing a theoretical patch compliance number.
Real-World Example: Choosing Safety Over Compliance
A few years ago, I worked with a pharmaceutical manufacturer who discovered a critical vulnerability in a component of their environmental control system. The vendor issued a patch within days. Their IT security team flagged it as a top priority and pushed hard for immediate deployment. But the site operations team pushed back.
Why? Because the control system had undergone FDA validation. Applying the patch would require not just downtime but a full completion of the clean room environment—a process that would take weeks, cost hundreds of thousands in compliance testing, and delay production runs of a high-margin oncology drug.
Instead of patching, the site implemented firewall rules to block potentially exploitable ports, restricted remote access, and increased monitoring. They reviewed and logged every interaction with the device and restricted physical access to engineering laptops.
Security purists might balk, but the decision balanced risk, business value, and compliance requirements—and it worked.
This isn’t an exception. It’s the norm for mature OT environments.
The Metrics Trap
One of the most damaging things I see is organizations trying to force IT-centric metrics into OT. Patch compliance is a perfect example. When CISOs are told to report the “percentage of patched assets,” they often realize how poor that signal is in an OT context. The number tells you very little about the actual risk.
A factory that has patched 90% of its assets but hasn’t mapped its network or doesn’t know which Engineering Workstations (EWS) are Internet-facing might look good on paper but is operating blind. Meanwhile, a plant with only 40% patch compliance but strong segmentation and access controls is likely in a far better security posture.
Security metrics in OT need to evolve. We should be asking questions like:
- What percentage of OT assets have defined risk mitigation plans?
- How many unpatched vulnerabilities are mitigated through compensating controls?
- What’s the time to containment when a new OT exploit is identified?
These are more actionable—and more aligned with operational realities.
Toward a Risk-Based, Context-Aware Future
Patching has a role. But in OT, it must be part of a broader ecosystem of risk reduction, not the North Star.
If we want to secure industrial environments, we need to meet them where they are. That means building programs that prioritize the business context, respect the constraints of safety and uptime, and measure success not in theoretical compliance but in actual defensibility.
The future of OT vulnerability management isn’t about how fast we patch. It’s about how well we protect what matters in the way that works best for the business.
Next week, we’ll explore how to adapt CVSS scoring for OT environments and why a score of 9.8 might not be the emergency you’ve been led to believe.