Why patch capability is wasted spend for legacy OT, and where the real investment goes.
Bruce Schneier and Barath Raghavan wrote in April about what AI-assisted vulnerability discovery means for the future of cybersecurity. I wrote about the same shift in February, anchored on AISLE’s twelve OpenSSL zero-days. Both pieces underplay the same thing.
The right response in manufacturing is not better OT patch management. For most of the legacy estate, building that capability would be wasted spend. For greenfield, the problem isn’t the security team’s at all. It’s procurement, capital projects, and how new factories get built.
This is the follow-up for security leaders who read the first piece and asked where to actually invest.
The capability gap behind the taxonomy
Schneier’s find/verify/patch taxonomy is conceptually clean. Some vulnerabilities will be easy to find and patch (cloud-native applications). Some will be hard to find but easy to patch once known. Some will be easy to find but hard to patch (industrial control systems). Some will be easy to find but hard to verify (distributed systems with thousands of moving parts).
It’s a useful sorting exercise. It is also downstream of capabilities most manufacturers don’t have. Before you can sort a CVE into the right quadrant, you need to know which of your systems contain the affected component, who owns them, and what compensating controls already apply. Most manufacturers can’t answer those questions in hours. Many can’t answer them in weeks.
The capability ladder for OT vulnerability management has a few rungs. Software composition and asset inventory at the floor, so you know what’s running where. Triage capacity above that, the ability to assess a new CVE within hours rather than weeks. Then supplier relationships that deliver interim guidance when a patch isn’t ready. Then architectural posture, the segmentation and monitoring stack that compensates while you wait. At the roof, patch management proper, deploying and verifying patches within OT change windows.
Most manufacturing OT estates sit between ‘no floor’ and ‘floor + triage’. Most IT estates sit between ‘floor + triage’ and ‘floor + triage + supplier channels’. The disclosure-to-exploit window is now too short for capability shortfalls to stay hidden.
Patch capability is the wrong investment for legacy OT
Here is where the conventional security-team response goes wrong. Reading the AISLE paper, the natural reaction is to build out OT patch management. Faster cycles, more automation, better validation pipelines. This is wasted spend for most legacy OT.
The reason is structural. OT teams deploy only supplier-tested and validated patches, regardless of how confident the security team is. The cost of an unplanned plant stoppage from a bad patch typically exceeds the expected loss from the vulnerability the patch addresses. That is a rational calculation, not a security-immaturity problem.
So building infrastructure to deploy patches faster runs into a wall. The supplier controls the calendar. The plant operator controls the change window. The security team can shorten its own response time but cannot shorten either of those.
My experience is from forest-industry manufacturing rather than offshore, across a programme covering 40+ industrial sites.
The honest posture for legacy OT is different. Compensating controls and documented risk acceptance are the response posture, not an interim measure while patching catches up. The board signs off on that arrangement explicitly, in writing, with named owners.
This isn’t contrarian. It is how the mature heavy-industry security programmes I’ve worked with already run. Utilities, upstream energy, large-scale pharma manufacturing. Patching is opportunistic on the supplier’s calendar.
What AI-paced discovery changes is not the patch cycle. It is the compensating-control burden. If new vulnerabilities arrive faster, the segmentation, monitoring, and detection stack must absorb more uncertainty more often. Investment shifts from ‘patch faster’ to ‘compensate harder’.
The financial argument follows. Quantify expected loss from unplanned downtime caused by an untested patch (plant stoppage hours times marginal cost per hour) against expected loss from a given vulnerability class (probability of exploitation times impact). The maths in most heavy industry favours not patching. FAIR or equivalent makes this defensible to a board, and more importantly defensible to a regulator after an incident. The CRA’s notification timelines reinforce the documentation case rather than weakening it. ‘We had a documented compensating posture for this vulnerability class’ reads very differently from ‘we couldn’t patch fast enough’.
Can the technology remove the constraint?
Before settling on that posture, it’s worth testing whether the constraint is about to lift on its own. Live patching, applying security fixes to running code without a restart, is the technology that would do it. It has moved. It has moved in a direction that doesn’t reach the plant floor.
Microsoft made hotpatching for Windows Server 2025 generally available on Azure Arc-connected machines in July 2025 at $1.50 per core per month, then dropped the charge entirely in May 2026. Free is better than paid. But Microsoft’s own documentation sets out three limits that matter more than the price ever did.
The machine has to be connected to Azure Arc. That is an outbound cloud management-plane connection from the server, which is the specific thing OT network segmentation exists to prevent.
The reboot doesn’t disappear, it gets rarer. Baselines refresh every three months, and each planned baseline includes “all the updates in a comparable Latest Cumulative Update for that month and require you to restart your machine”. Four restarts a year, with eight hotpatch releases in between.
And there is no automatic rollback. Microsoft: “If you experience an issue during or after an update, you must uninstall the latest update and install the last functional baseline update. This process requires that you restart the VM.” Hotpatching removes the restart from the path where everything works and leaves it on the path where something breaks. The plant operator’s calculation was always about the failure path. It is unchanged.
The scope is narrower than the name suggests, too. Hotpatch covers Windows security updates. Nonsecurity updates, .NET, drivers and firmware all still require a restart, and drivers and firmware are a large share of what an OT supplier actually ships you.
Linux has a longer history and the same shape. kpatch and kGraft both arrived in 2014 and converged into a common in-kernel live-patching layer; Oracle’s Ksplice and Canonical’s Livepatch are the commercial offerings. All of them are kernel-only and all are paid add-ons. Canonical states plainly that “Livepatch does not patch userspace libraries like OpenSSL or glibc”, that patches to openssl and gnutls “require restarting all dependent processes”, and that for libc6 “even small security patches require restarting all linked processes, or more practically, a reboot”.
That is the point where this closes the loop with the February piece. The library at the centre of the AISLE findings is precisely the class of library live patching doesn’t cover.
BSD has no mainstream live-patching path at all. OpenBSD’s syspatch applies binary patches, and kernel updates still need a reboot. Worth noting, because the Mythos disclosures included a 27-year-old OpenBSD bug. Faster discovery, unchanged remediation, same platform.
Then the thing that decides it for OT regardless. None of this addresses certification. Rockwell, Siemens, Schneider and AVEVA certify their products against specific operating system and patch levels. Live patching a certified stack without supplier validation puts you outside the support agreement whether the machine reboots or not. Where GxP or 21 CFR Part 11 apply, the change triggers re-validation. Where NERC CIP applies, it triggers a change-management process. Continuous-process plants may get one or two windows a year and the queue for them is not set by security.
So the one rung that is moving only moves where things were already fast. Cloud-connected Windows fleets get a real improvement. The plant floor gets a technology it cannot connect, for an operating system its supplier hasn’t certified, covering the class of update that wasn’t the problem.
The depreciation gap
Behind all of this is a financial asymmetry. IT runs on a 3-5 year hardware refresh cycle. OT runs on whatever the asset depreciates over, which in heavy industry is typically 15-30 years and often longer. Same vulnerability, same affected library, two completely different financial pictures.
In IT, security debt drains through the refresh cycle. A system you can’t patch today will probably be retired in two or three years anyway. Vulnerability management lives within a bounded horizon.
In OT, neither cycle helps. The PLC bought in 2003 will not be retired because there is no business case to retire it. It still does what it was specified to do. The plant operator resists replacement because commissioning a new line costs millions and brings unplanned downtime. Compensating controls become a permanent operating cost, not a transitional one. There is no hardware refresh quietly fixing things in the background.
That permanence is the part most treatments miss. In IT the exposure behaves like a backlog, and backlogs drain. In OT it is a standing liability with no mechanism that retires it. It isn’t a worse version of the IT problem. It’s a different problem wearing the same vocabulary.
The procurement decision compounds this. OT capital projects are typically awarded on cheapest-cost-up-front, with security tier rarely a deciding factor. That choice locks in the security debt for the full asset life. A bad specification in 2026 produces compensating-control liability through 2050. Procurement teams rarely model this because their incentive is project budget at handover, not lifecycle TCO. Security teams rarely have the standing to challenge it.
The IT/OT exposure gap is not just about patch cycle speed. It is about the depreciation horizon over which the gap accumulates, and the procurement bias that locks each new asset into that horizon.
Three estates, three postures
The right way to think about manufacturing OT is not as a single estate. It is three estates in different states of patchability, requiring three distinct postures.
Legacy estate, much of it 15-30 years old. Compensating controls plus documented risk acceptance. Patching is opportunistic on the supplier’s clock. Investment goes into segmentation maturity, OT-protocol detection, supplier patch intelligence, formal risk-register hygiene, and a credible replacement roadmap that improves patchability over the asset-replacement cycle.
Mid-life estate, last 5-15 years. Same posture with selective patch capability where suppliers actively support it. Most current OT security investment effort lives here, often with the most operational complexity. The honest question for this tier is which assets actually have functional supplier patch support and which don’t. The latter are legacy in disguise.
Greenfield, now and forward. Capable VM and patch management should be the expectation. This is where the IT/OT split can narrow rather than widen.
The mistake in most manufacturing security strategies is treating these as one thing. They aren’t. The investment profile, the maturity ambition, and the success measures are different for each tier.
The greenfield problem isn’t a security problem
Here is the harder truth. Greenfield OT only achieves capable VM and patch management if security is a veto-bearing participant in capital projects and procurement. Most enterprises don’t structure it that way.
Capital project teams own the factory build. Engineering, automation, and operations report through different chains than security. Security typically gets a tick-box at best, often only at commissioning when the equipment is already specified. EPC contractors run procurement under their own preferred-supplier frameworks. The end customer often doesn’t see the full bill of materials until handover. Factory and site acceptance tests verify functional behaviour, throughput, and uptime. They rarely test patch-deployment readiness.
This gets misdiagnosed as a procurement failure, and it isn’t one. I made that argument at length in supplier lock-in is a governance problem, not a security problem, responding to Tom-Roger Stensberg’s case that suppliers block OT security in oil and gas. He is describing the symptom. By the time the operator takes over the plant, the terms of access are already set, often two or three contract layers down. Restrictions on system access, diagnostics and configuration visibility were never negotiated by the operator’s security team. They were inherited from a build project where cybersecurity wasn’t on the requirements list. Not a procurement error. An engineering inheritance.
The commercial mechanism is what makes it durable. For many system integrators in process industry, aftermarket support — spare parts, service agreements, remote monitoring, software maintenance — runs to as much as 80% of revenue. When that is the business model, it shows up in the design choices. Proprietary protocols, limited diagnostic tooling, configuration interfaces only the supplier’s own engineers can reach. Those aren’t incidental features. They are a supplier dependency engineered in from day one, and the integrator is acting rationally inside its own incentive structure. None of it requires bad faith. It requires only that the system owner accepted the commercial terms without asking what they cost in security.
That is also why the levers below are contractual rather than a matter of supplier goodwill. Accepting a trade-off deliberately is governance. Inheriting one without knowing it was made is not.
The procurement governance hooks that actually move greenfield are not interesting individually but missing collectively in most enterprises:
- Security design review as a hold point at FEED stage, not commissioning
- Lifecycle TCO modelling that includes compensating-control cost over the depreciation horizon, not just project budget at handover
- Pre-qualified OT supplier list with security tier ratings, including SBOM availability, patch validation SLAs, and vulnerability notification commitments
- Contractual clauses in EPC and OEM master agreements covering SBOM at handover, patch validation cycle commitments, and CRA-aligned vulnerability disclosure
- Factory and site acceptance tests extended with security criteria such as default credentials removed, segmentation verified, monitoring telemetry flowing, and patch dry-run completed
- Cross-functional governance forum between CISO, COO, Project Director, and CPO with a shared OT security maturity scorecard
None of this is a security project. It is a procurement and engineering programme that security has to influence into existence. That work is structurally hard. The financial case is uncertain. The threat horizon is shorter than the asset horizon. Operations and CapEx leaders carry more weight than the CISO in most heavy industry.
The consequence of not doing it compounds. Today’s greenfield is tomorrow’s legacy. Every factory built without VM-capable specification adds another 20 years of ‘we can’t patch this’ estate. AI-paced discovery exposes that build choice with a much shorter feedback loop than before.
The integration sister problem
Even when greenfield OT is procured well, there is a separate problem most companies underfund. Integrating OT vulnerability data, asset inventory, and detection telemetry with the enterprise SIEM, CMDB, and central vulnerability management platform takes sustained engineering investment.
Tools like Claroty, Nozomi, and Dragos make it technically feasible. Adoption requires structural buy-in across IT and OT security functions that often run in parallel rather than integrated. Without that integration you end up with capable greenfield sites that are black boxes to central security, which defeats much of the procurement work upstream.
The integration question is a leadership question, not a tools question. Who is accountable for closing the OT-to-IT visibility gap? In most enterprises, nobody. That is the gap.
Recalibrating the risk inputs
Quantitative frameworks like FAIR built on historical vulnerability discovery rates are using inputs that no longer reflect reality. Threat event frequency for vulnerabilities in mature, well-audited code has moved. Any board report, insurance discussion, or risk register that hasn’t accounted for that is reasoning from outdated numbers.
Where to start
Three checks that test whether any of this applies to you. None of them need a budget line.
Run software composition discovery against one OT site and time how long it takes to answer “where is OpenSSL running here”. If the answer is weeks, the floor of the capability ladder is missing, and nothing above it is load-bearing.
Document one tier-1 risk acceptance with a named owner and an expiry date. If nobody will put their name to it, the compensating-control posture isn’t a posture. It’s a gap with better vocabulary.
Ask for a security hold point at FEED stage on the next CapEx gate review. If that request has nowhere to go organisationally, you have found the greenfield problem, and it’s a structural answer rather than a security one.
Closing
AI-paced vulnerability discovery is real and not new. Schneier’s observation about shifting baselines applies. The capability has been visibly coming for years. What is genuinely new is the pressure it puts on operational reality. The disclosure-to-exploit window is too short for capability gaps to hide.
For legacy OT, that pressure isn’t fixable through faster patching. It is managed through documented compensation, funded as ongoing operating cost rather than a transitional fix that never arrives. For greenfield, it is fixable through procurement, but only if security has the gate-review authority to influence it and only if total cost of ownership beats cheapest-cost-up-front in the decision. The shops that come through the next decade well are those that closed the procurement loop now and built three distinct postures for three distinct estates. The shops that don’t will keep building tomorrow’s legacy with today’s risk acceptance, and the IT-OT exposure gap will keep widening regardless of how good the security team gets at firefighting.
Related reading
- Is your manufacturing company’s vulnerability management ready for what comes next?, the first piece, on the AISLE OpenSSL findings and what accelerated discovery does to the gap between known and fixed.
- CRA for manufacturing companies in Europe, on what the Cyber Resilience Act requires and when it starts to apply.
- Supplier lock-in is a governance problem, not a security problem, on why the access restrictions in process industry are a governance inheritance rather than a procurement failure, and how the aftermarket business model keeps them in place.
I advise industry and energy companies on security governance and risk management. More about my work.