The problems in OT security are well documented, and they are structural. Industrial environments run equipment with lifespans measured in decades, not refresh cycles. Controllers and HMIs frequently sit on operating systems that stopped receiving patches years ago, and where patches do exist, applying them means negotiating maintenance windows against production targets. Industry analysis consistently attributes the majority of OT compromises, around 60% by some estimates, to unpatched, previously disclosed vulnerabilities rather than novel techniques.

Underneath the patching problem sits a visibility problem. Very few industrial organisations can produce a complete, current inventory of what is connected to their OT networks. Devices are installed by contractors and never recorded; engineering workstations acquire dual network connections for convenience; cellular modems appear on remote sites because someone needed access and the corporate process was slow. Every one of these is an unmanaged asset, and unmanaged assets do not get patched, monitored or included in risk assessments. You cannot defend what you do not know exists.

The third structural problem is the boundary itself. Assessments across the industrial sector repeatedly find that the segmentation organisations believe they have between IT and OT does not survive contact with an architecture review. Recent industry figures put poorly segmented environments at around four in five of those examined, with a large majority of tabletop exercises revealing degraded or absent detection on the OT side. Dwell times reflect this: where monitoring is absent, attackers routinely spend weeks inside operational networks before anyone notices, and in many penetration tests defenders prove unable to detect adversary activity conducted entirely with legitimate administrative tools.

Set against this is a threat landscape that has professionalised. Threat intelligence firms tracking the industrial sector now count well over a hundred ransomware groups actively targeting industrial organisations, a sharp year-on-year increase, and, more significantly, have begun designating adversaries that operate inside OT networks with the capability to interact directly with industrial control systems, rather than merely probing the boundary. A division of labour is emerging: access brokers compromise internet-facing systems and sell the foothold; other groups quietly exfiltrate operational data and alarm configurations; the most capable groups use both to prepare disruption. State-aligned, criminal and hacktivist actors are all represented, and they are increasingly targeting the contractors, engineering firms and managed service providers that hold access to many industrial sites at once.

None of this requires the adversary to be sophisticated. Much of it only requires the defender to be absent.

What Failure Looks Like: The US Water Sector

Between late July 2026 and the days that followed, water and wastewater utilities in at least seven US states reported cyber incidents to the FBI, prompting a joint FBI and EPA public advisory. The technique was not advanced. Attackers located internet-facing programmable logic controllers, specifically Rockwell Automation MicroLogix 1100 and 1400 series devices, accessed them remotely, and changed their IP addresses and passwords. Operators lost the ability to monitor and control their own equipment. Reported operational effects included loss of pressure and flooding; the advisory notes that pressure loss in a water system can allow untreated groundwater to seep into distribution pipes. In Minnesota, more than thirty municipal water facilities were targeted in a coordinated action over a single weekend, with some communities placed on boil-water notices and utilities forced into sustained manual operation.

These were not zero-days. They were controllers reachable from the public internet, protected by weak or default credentials, at organisations where nobody was watching the devices or the traffic reaching them. The federal recommendations, disconnect PLCs from the internet, put remote access behind an authenticated gateway, use strong unique credentials, are the kind of controls most security programmes solved on the IT side fifteen years ago. They persist in OT because OT sits outside the programme.

What Failure Looks Like When the Adversary Is Patient: The Polish CHP Plant

If the water attacks illustrate opportunism, the compromise of a Polish combined heat and power plant, disclosed by CERT Polska in August 2026 following a three-month investigation of a December 2025 incident, illustrates what a capable, deliberate adversary does with the same category of weaknesses. The plant supplies district heat to roughly 50,000 residents. The attackers shut down its steam turbine and its process-water treatment system.

The attack path repays close reading, because every link in it exists in some form in most industrial estates. Initial access came not at the plant but at a wind farm, an entirely separate facility, through a firewall appliance whose VPN was exposed to the internet and permitted accounts without multi-factor authentication. From there the attackers reached the management interface of a cellular router that sat, for administrative convenience, on a network segment behind the compromised firewall. They used SSH tunnelling through that router to reach a private cellular APN operated by the regional grid operator, a network whose configuration allowed any connected device to communicate with any other. Scanning the APN, they found a controller at the CHP plant exposing its web administration interface with default credentials still in place, and tunnelled through it into the plant's OT network.

What followed was measured. Reconnaissance ran for a week in mid-December, including a port scan that began at the SCADA system's address and, on Christmas Day, connections over the S7 protocol to three Siemens PLCs, almost certainly rehearsal. Four days later, in an operation the investigators assess was substantially automated, the attackers switched the plant's Siemens controllers into STOP mode and password-protected them, halting the turbine and the water treatment process. They factory-reset serial device servers and switches, reassigned equipment to unreachable addresses, then destroyed their own path in: corrupting the controller they had pivoted through, resetting the cellular router and the original firewall, and taking most of the logs with them.

Three details deserve a CISO's attention. First, no malware was involved at any stage; every destructive action used a supported device function, invoked over the protocols the plant legitimately runs. Endpoint detection had nothing to detect. Second, several of the compromised components were technically compliant: the wind farm met the data-transmission requirements it had been given, but those requirements governed how process data travelled, not how the devices carrying it were administered. Compliance with a narrow specification provided the route in. Third, and most importantly, the plant did not initially recognise the event as an attack. Maintenance was underway, so the shutdown was logged as probable contractor error and reported for information only. Eleven days of reconnaissance, unauthorised connections to production PLCs, and a port scan aimed directly at the SCADA system generated no alarm, because nothing was monitoring the network on which they occurred.

The Practical Programme: Getting OT Under Your SOC

Every stage of the aforementioned attacks produced network behaviour that competent OT monitoring surfaces as a matter of routine: a new device appearing on a segment, a first-ever SSH session to a piece of network equipment, scanning activity, unfamiliar sources speaking industrial protocols to controllers, configuration and logic changes on PLCs. The technology to generate these alerts is mature and available at a range of price points; several capable platforms exist well below the premium tier, and for smaller estates there are credible open-source and community options. The scarce ingredient is not detection technology. It is an operating model that gets those alerts in front of trained analysts, tuned to the environment, twenty-four hours a day.

That is what your Security Operations Centre already is. The work is connecting it properly, and it breaks into stages.

Stage One: Establish Visibility

Deploy passive network monitoring at the natural aggregation points of the OT estate, SPAN or mirror ports on the switches between control zones, and at the IT/OT boundary. Passive collection matters here for reasons that don't apply in IT: you cannot install agents on a fifteen-year-old controller, and active scanning has a documented history of crashing fragile industrial devices. Within weeks, passive monitoring gives you the two things most programmes lack: a live, continuously maintained asset inventory, and a baseline of what normal communication looks like. Use the inventory ruthlessly. Every internet-exposed device it reveals is a finding to remediate now; the water-sector incidents were, at root, an exposure problem. Every device with default credentials, every unexpected remote-access path, cellular modems and vendor VPNs especially, goes on the same list. In the Polish plant case, both the exposed VPN and the default-credential controller would have appeared in a first-pass inventory.

Stage Two: Route OT Alerts Into the SIEM Your Analysts Already Use

The monitoring platform will emit a manageable set of alert categories: new assets, configuration and logic changes on controllers, remote access sessions, protocol anomalies, and known vulnerabilities matched against discovered devices. Feed them into the existing SOC pipeline rather than a separate engineering dashboard, and enrich them with the context an analyst needs: what the device is, what process it belongs to, who its engineering owner is, and what the current maintenance schedule says. An unauthorised connection to a PLC is not conceptually harder to triage than an unauthorised RDP session to a domain controller; it is only unfamiliar. A modest investment in analyst training on industrial protocols and a shared vocabulary with the engineering team closes most of that gap.

Stage Three: Tune With the Engineers in the Room

This is the stage organisations skip, and it is where the entire return on the investment lives. OT alerting starts noisy because legitimate engineering activity, logic downloads, firmware updates, contractor sessions, looks identical to attack activity until the system is taught the difference. Sit SOC analysts and plant engineers together for a defined tuning period: map planned change windows into the SIEM so expected activity is annotated rather than alarming; whitelist the known engineering workstations that are supposed to talk to controllers; rank alerts by the criticality of the process behind the device rather than by generic severity. Note the failure mode this guards against, because the Polish plant demonstrated both halves of it: an untuned system drowns analysts until they stop looking, while no system at all leaves operators attributing a real attack to contractor error. Tuning is what makes the feed trustworthy in both directions.

Stage Four: Agree the Response Model Before the First Real Alert

Detection without a pre-agreed response plan creates a new risk: a well-meaning analyst isolating a network segment that a live process depends on. Write the joint playbook now. Define who holds authority to disconnect what, which systems can be safely isolated and which must never be, how the SOC reaches plant engineering out of hours, and what "contain" means for each critical process. Exercise it, and exercise the scenario the industry keeps failing, which is not the perimeter breach but the trusted third party: the day a contractor's access, an upstream provider, or a shared network like a private APN turns out to be the route in.

Stage Five: Measure It Like the Rest of the Programme

Time from a new device appearing to it being identified and classified. Percentage of OT assets covered by monitoring. Mean time to acknowledge an OT alert out of hours. Number of internet-exposed OT devices, trending to zero. These are metrics a board can understand, and they convert OT security from an article of faith into a managed capability.

Staffing It Honestly: Where Managed Detection and Response Fits

There is one constraint that deserves a candid treatment, because it determines whether the model above works in practice. OT alerts do not respect business hours. The Polish attackers conducted their reconnaissance over the Christmas period and began their destructive sequence at half past five in the morning, and analysts who can confidently interpret industrial protocol behaviour remain genuinely scarce and expensive to hire. If your SOC is a small team already stretched across the IT estate, asking it to absorb continuous OT coverage and develop ICS expertise from a standing start is a plan that looks sound on a slide and fails on the first bank-holiday weekend.

This is the point at which extending your programme through a managed detection and response partner for OT becomes less a procurement decision and more a coverage decision. The tuned OT alert pipeline you have built is exactly the feed an MDR service is designed to consume: it supplies the continuous monitoring, the analysts who have seen controller reconnaissance and configuration tampering before, and the escalation discipline to engage your engineers within minutes rather than after the shift change. The economics generally favour it as well. You are buying a share of a mature, always-on capability rather than funding the recruitment, training and retention of one from zero, and it leaves your internal team focused on the parts only they can do: the tuning, the engineering relationships, and the response decisions that require knowledge of your processes.

The organisations appearing in incident reports this year are not, for the most part, the ones that declined to fund a seven-figure OT security transformation. They are the ones where the signals were available and nobody was positioned to see them. The monitoring technology is affordable. The SOC already exists. The practical work of a modern OT security programme is joining the two, tuning the result until it can be trusted, and making sure someone capable is watching it at half past five in the morning, because, increasingly, someone on the other side already is.