Why OT Incident Response Can't Follow the IT Playbook
At 8:00 on the morning of February 5, 2021, an operator at a water treatment plant in Oldsmar, Florida watched his mouse cursor move on its own. It drifted across the screen, opened the control software, and raised the setpoint for sodium hydroxide — the caustic chemical that treats the water — to more than a hundred times its normal level. Plant staff noticed the value had changed and dragged it back before anyone was harmed.
That is how the attack ended: not because a detection system fired, not because a security team isolated a compromised host, but because a human being happened to be looking at the right screen at the right moment.
In an IT environment, the response to a breach follows a well-worn script. Isolate the affected systems. Preserve a forensic image of their disks and memory. Reimage them. Restore from backups. Correlate the logs, establish a timeline, and contain the damage. The script works because it rests on two assumptions IT has earned: you can take the systems offline, and the systems keep a record of what happened.
Operational technology shares neither assumption — and that is the single biggest reason OT incident response is so hard.
Why the IT playbook assumes what OT can’t provide
The first assumption fails for a reason any control engineer understands in their bones: you cannot isolate a controller that is keeping a process alive. A turbine, a chemical reactor, a water treatment train — these don’t pause for an investigation. Taking a PLC offline to image it can be the very disruption the incident was meant to cause. Containment in OT is frequently not “pull the plug” but “keep running while you figure out what changed.”
The second assumption fails more quietly. The devices that matter most in an OT intrusion — controllers, field devices, drives, remote terminal units — generate almost nothing in the way of security logs. A server records failed logins, process starts, file accesses, and audit trails by default. A PLC records whatever the engineer explicitly chose to log, and often that is nothing at all. The richest forensic artifact in an OT environment is frequently not a log file. It is the operator’s memory, the HMI trend history, and whatever the engineering workstation happened to have recorded.
What OT incident response is actually working with
When an OT incident is declared, the questions are always the same: What was changed? When? By whom, using which credentials, from where? In IT, answering those questions is a matter of correlation. In OT, it is a matter of reconstruction from thin air.
Consider the artifacts an attacker actually leaves behind in a control environment. A Modbus write to a coil. A DNP3 select-and-operate sequence. An S7 logic download to a controller. A configuration change pushed through a vendor’s remote-access channel. None of these produces a security event on the device itself. The write is recorded — if it is recorded at all — only in the protocol traffic, on the wire, for the fraction of a second it takes to cross the network.
If nothing was listening to the wire, the answer to “what happened?” is genuinely, “we may never know.”
Two incidents that show the difference
Oldsmar, Florida — February 2021
The attacker reached the plant’s SCADA system through TeamViewer, the remote-access software the facility used for operator access. Once inside, they changed the sodium hydroxide setpoint to a dangerous level. There was no exploit, no malware, and no signature to match — just a legitimate remote-access session doing something it should not have done. The intrusion was caught because plant staff noticed the changed value. Had no one been watching, the altered setpoint would have flowed into the treatment process. The incident is remembered as a near-miss; it is better understood as a demonstration of how little forensic material a remote-access intrusion leaves behind.
Colonial Pipeline — May 2021
In May 2021, a ransomware group compromised the business network of Colonial Pipeline, which carries roughly half the refined fuel consumed on the U.S. East Coast. The ransomware did not reach the operational technology directly. But Colonial faced a hard choice: it could not be certain what the attacker could see or reach, so the company shut down pipeline operations preemptively while it investigated. The result was a days-long shutdown of a 5,500-mile pipeline and fuel shortages across the Southeast. The lesson is not about ransomware on controllers. It is about confidence: when an incident strikes, the cost of not knowing what is compromised can exceed the cost of the compromise itself.
The evidence that wasn’t there
The gap between these two incidents is the one OT teams live with every day. Mandiant’s M-Trends 2026 report put the global median dwell time at 14 days in 2025 — meaning an intrusion is typically present for two weeks before it is found. In OT, that window is often longer, because the systems are quieter and the logging is thinner.
A leading OT threat intelligence vendor’s 2026 year-in-review reported that 30% of the incident-response engagements it worked in 2025 began not with a detection alert, but with someone in operations noticing that something “seemed wrong.” In many of those cases, the telemetry needed to establish what actually happened had never been collected.
That last clause is the whole problem in miniature. Detection and investigation are usually treated as separate disciplines. In OT they are the same investment: the record that would have alarmed is the same record the investigation needs.
Why can’t you just restore an OT system from backup?
Because the backup answers a different question than the investigation is asking. A backup restores a state. An investigation needs a sequence — who changed what, in which order, over what period. Restoring a controller to last month’s logic brings the process back, but it destroys the very evidence that would explain how it was modified. In OT, the instinct to restore quickly and the need to investigate thoroughly pull in opposite directions, and without an independent record of the network, restore wins every time — leaving the question of how the attacker got in unanswered, and the door open for a repeat.
Why don’t controllers generate the logs an investigation needs?
Because they were never designed to. A controller’s job is to execute a control loop deterministically, in milliseconds, for years at a time. Every feature that is not directly serving that loop — audit logging, storage, event correlation — costs compute, memory, and vendor qualification effort. Signatures and endpoint-style logging assume the presence of an operating system with rich telemetry. Controllers don’t run that operating system, and retrofitting them would mean touching devices that, by design, are meant to be left alone. This is not a flaw in the engineering; it is a structural fact about the environment.
What does a passive network record change about the investigation?
Everything, because it changes the question from “what do we think happened?” to “what did we observe?” A passive monitor sits on the wire and records the protocol traffic that flows during normal operation — the Modbus polls, the DNP3 reads, the S7 downloads, the firmware transfers. Because it records everything rather than a filtered set of events, it preserves the sequence an investigation needs: which device talked to which, with which function code, at which time, in what order. When an incident is declared weeks after the fact, the evidence is not the operator’s memory. It is the traffic log, complete and uneditable.
Does a behavioral baseline replace incident response, or inform it?
It informs it — and it changes when the response can begin. A baseline is a model of this network’s normal, learned passively over time. The same model that flags a suspicious first-time connection also gives the investigator a reference point: what was this device supposed to be doing, and how did its behavior depart from it? That turns a forensics exercise into a comparison. Instead of asking “is this traffic malicious?” — a question signatures can only answer for attacks already seen — the investigator asks “does this match what this device has always done?” The first question has a limited answer set. The second has a reference.
The investigation in the first hour is decided months earlier
The hardest moment in OT incident response is the first hour — before you know the scope, before you can safely contain anything, before you understand whether the attacker is still in the network. What you have in that hour is determined entirely by what you recorded in the months before it. If the only record is the operator’s memory and a handful of HMI trends, the investigation stalls. If the network was being observed passively, with a learned baseline to compare against, the investigation starts from evidence rather than guesswork.
This is the difference between responding to an incident and reconstructing one. The former is fast, calm, and bounded. The latter is slow, uncertain, and expensive — and it is the default for every operator that has not recorded the normal behavior of its network.
This is the problem Maigadi was built to address.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.
When an incident happens, the question “what changed?” should not depend on who happened to be watching a screen. A passively learned baseline is both the alarm that fires in the moment and the record that answers the question afterward — one investment, serving the two moments that matter most.
Maigadi Networks provides passive, signature-less network detection and response for OT/ICS environments. We help operators see when a trusted device starts doing something it has never done before — before that behavior becomes an incident.