NewsCSO OnlineSME

    When the patch tsunami meets the maintenance window

    In April 2026, the balance between finding software flaws and fixing them broke. Frontier AI models released by Anthropic and OpenAI can now autonomously identify exploitable vulnerabilities in production software — work that used to take experienced human researchers roughly sixty days now takes about four hours, as Melissa Hathaway documents in a recent Cyber Defense Review perspective . According to the same paper, at least 40 of the largest software and hardware vendors already have access to these models, and Anthropic’s Mythos reportedly surfaced critical flaws in 99 percent of widely used operating systems and browsers. Hathaway’s conclusion is blunt: four decades of “field it fast and fix it later” technical debt is now coming due, and the industry should expect a tidal wave of patches over the next twelve to twenty-four months rather than the next decade. She is right — and yet the debate she has triggered is being conducted almost entirely in IT terms: disclosure deadlines, patch cadences, liability for laggard vendors. Every one of those patches, however, eventually arrives somewhere physical: a substation, a bottling line, a water treatment plant, a hospital wing. July’s PLC intrusion at Minnesota water utilities , was a preview of what arrival looks like. And there the tsunami meets a structure the disclosure debate keeps forgetting exists: the maintenance window. Discovery at machine speed, remediation at plant speed Finding a vulnerability and fixing it were never the same workflow. AI has collapsed the first and left the second untouched. In enterprise IT, the remediation convention Hathaway cites — seven days for actively exploited critical flaws, thirty for high severity — is ambitious but achievable: reboot the server, roll back if it breaks, apologize to nobody. In operational technology, that convention is structurally impossible. Availability and safety outrank confidentiality; a continuous process does not pause because a CVE arrived; and the next scheduled window may be a quarterly turnaround, or an annual shutdown planned eighteen months ago. The gap is not cultural. It is physical, economic and contractual. Meanwhile, the attacker side enjoys the same acceleration as the defender side. The models that find a flaw can develop a working attack path within hours of disclosure, and the capability is not confined to one bloc: Hathaway notes that the Chinese 360 Digital Security Group’s AI discovery agent has already uncovered close to a thousand previously unknown vulnerabilities. There is no geographic sanctuary and no sectoral one — and OT networks, with their long-lived and rarely patched assets, are precisely where unpatched time accumulates. Discovery now runs at machine speed. Remediation in OT still runs at plant speed. Everything that follows is about managing the widening gap between the two. Why OT cannot simply patch faster It helps to be precise about why the standard advice fails, because none of the reasons is negligence. A patch that reboots a controller can trip a running process; on or near a safety instrumented system, an unqualified change is itself a hazard, not a mitigation. Most industrial components may only be updated with firmware and patches the OEM has validated against the specific product line — applying an unapproved update can void warranties, support contracts and certifications. That qualification takes weeks to months, and the clock only starts once the vendor has processed the upstream fix. Then operations have to find a window: many plants cannot stop outside planned turnarounds without seven-figure losses or genuine safety implications. And beneath all of that sits the legacy layer. Hathaway explicitly names manufacturing and healthcare as sectors running unsupported products, and in the plants I audit the picture is familiar: the engineering workstation on an operating system that left support years ago, the PLC generation with no update mechanism at all. For these assets, “patch faster” is not advice. Replacement is a capital program with a multi-year horizon — her Y2K analogy is exactly the right one. In IT, a patch is a fix. In OT, a patch is a project. Triage like an operator, not like a scanner The first casualty of the coming volume will be the CVSS-sorted worklist. When AI-assisted disclosure pushes hundreds of relevant advisories into an installed base per quarter, “critical first” stops being a sort key, because too much is critical. The wider industry is arriving at the same conclusion: Rapid7 warned in August that disclosure volume and exploitation speed have broken the traditional patch cycle and are forcing defenders toward exposure-based prioritization. The triage logic I walk operators through builds on three questions instead. Is there exploitation evidence — a KEV listing, a rising EPSS score, an OEM advisory referencing active abuse? Is the asset actually exposed — reachable from the IT network or the internet, or buried three zones deep behind enforced conduits? And what is the consequence — what does this component do to the process, and to safety, if it misbehaves? IEC 62443 already provides the vocabulary for acting on those answers: zones and conduits to define exposure, plus compensating countermeasures where patching is not feasible on the required timeline — segmentation, allow-listing, virtual patching at the network boundary, removal of unnecessary reachability and tightened monitoring for exploitation attempts against the specific flaw (TR 62443-2-3 covers patch management in industrial environments in detail). Official doctrine now points the same way: in late July, an ASD-led coalition with CISA, the FBI, NCSC-UK and CCCS published CI Fortify , joint guidance on isolating vital OT systems and running them disconnected for extended periods — containment promoted from workaround to designed-in capability. The honest, auditable position for a large share of the OT estate is therefore not “patched within SLA.” It is: we do not patch this asset on this timeline; we contain it — here is the compensating control, here is the monitoring and here is the retirement date. Under NIS2, where management carries personal accountability for risk measures, a documented containment decision defends considerably better than a silently missed patch SLA. Plan the surge like an outage Hathaway urges governments to map patch volumes against national exposure and to prepare surge capacity. Operators should run the same exercise one level down, and four moves matter most. First, interrogate your OEMs and system integrators now: how do they ingest AI-discovered findings, what patch volume and cadence do they expect for your installed base, and what are their qualification timelines? The joint CSA, SANS and OWASP guidance published in April on building “Mythos-ready” security programs is a usable checklist for exactly that conversation. Europe adds leverage here: on September 11, the Cyber Resilience Act’s first hard obligation takes effect — manufacturers must report actively exploited vulnerabilities through ENISA’s new Single Reporting Platform, with an early warning within 24 hours and a fuller notification within 72, and the duty covers products already on the market, not only new ones. That means earlier upstream signals: ask your vendors, in writing, how those advisories and the accompanying SBOM data will reach you as an operator. Second, pre-negotiate emergency windows with operations before you need them, including written criteria for when a vulnerability justifies unplanned downtime — a decision framework like any other safety call, agreed in daylight rather than improvised at 2 a.m. Third, exercise the scenario that is actually coming: not one incident, but a week in which several high-severity advisories land across different vendors simultaneously. Hathaway recommends such exercises at national level; they are even more useful at plant level, where the constraint is a finite pool of automation engineers. Fourth, give every unpatchable asset a retirement date and a budget line. Compensating controls are a bridge, not a destination, and an inventory that quietly accumulates permanent exceptions is technical debt wearing a compliance costume. The policy questions — disclosure deadlines, government equities, vendor liability — will be settled in Washington and Brussels. Operators will live with the output either way. Discovery has permanently accelerated; the disclosure pipeline is industrializing, with AI labs themselves now committing to fixed coordinated-disclosure timelines; the only variable still under an operator’s control is the readiness of the remediation machine. In OT, that machine is built from change management, not scripts. The window between a flaw’s disclosure and its exploitation used to be someone else’s problem — the vendor’s, the researcher’s, the policymaker’s. As of this year, it is an operations problem. Treat it like one.

    More on maintenance

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4217080/when-the-patch-tsunami-meets-the-maintenance-window.html

    ID