The Control Loop Is Where OT Attacks Land

Every minute of every day, a plant issues thousands of setpoint changes. A pump speeds up. A valve opens another five percent. A furnace nudges a few degrees warmer. Each one is a number written to a register inside a controller, and nobody blinks. Most of those changes are routine. A few of them are the attack.

Here’s the awkward truth at the center of OT security: the single most dangerous thing an adversary can do — tell a process to do something it shouldn’t — is also the single most ordinary thing an operator does all day. Same register, same write, same bytes. You cannot tell the two apart by staring at the device. You have to watch the loop.

On 5 February 2021, an operator at a water treatment plant in Oldsmar, Florida, watched his own cursor start moving without him. Someone on the other end of a legitimate remote-access tool — the same software the plant had installed so its support vendor could help — had taken over and was changing a setpoint. The sodium hydroxide, or lye, feed rate was driven from 100 parts per million to 11,100. The operator reversed it in time, and other safeguards meant the public was never exposed. But notice what the attack actually was: a perfectly valid HMI write, to a perfectly valid register, on a perfectly healthy controller. No malware to match. No signature to trip. No exploit to patch. Just a number pushed somewhere it should never go.

What is a control loop, and why is it the real target?

A control loop is the smallest unit of industrial automation. A sensor measures a process variable — temperature, pressure, level, flow, speed. A controller compares that reading to a setpoint and works out a correction. An actuator carries it out. The loop runs closed, in milliseconds, for years.

An adversary doesn’t need to break any of these boxes to do harm. They only need to move one of the three things that define how the loop behaves: the setpoint, the measurement, or the state the loop is in. That’s why the loop — not the device — is where OT attacks land, and where detection has to live.

The three ways an adversary manipulates a control loop

Setpoint and command manipulation

Oldsmar is the cleanest example. The attacker never touched a vulnerable PLC, never dropped a payload, never burned a zero-day. They used the plant’s own remote-access software and changed a number. At the protocol level, a setpoint write looks identical to a legitimate one — Modbus function code 06 to a register, a DNP3 write, an S7 job to a data block. The difference isn’t in the bytes. It’s in whether that device, at that time, was ever supposed to write that value to that register.

Sensor spoofing — feeding the controller a false world

Stuxnet, discovered in 2010, showed the subtler version. Rather than simply drive centrifuge speeds to failure, it recorded normal process values and replayed them to operators on a loop, so the HMI showed a healthy process while the rotors were being stressed toward breakage. The controller believed a false measurement, and the operator believed the controller. Everyone upstream of the sensor was working from a lie — and, by their own logic, behaving exactly as designed.

Sensor spoofing defeats device-centric security more cleanly than anything else, because the compromised device isn’t misbehaving at all. It’s faithfully carrying out the false inputs it’s been handed.

State manipulation — mode changes and forced outputs

The third form is the quietest. A loop runs in modes: automatic (the controller drives the actuator) and manual (an operator drives it directly). An adversary who can flip a loop from automatic to manual, force an output to a fixed value, or disable an interlock has changed the loop’s behavior without touching a single setpoint. These transitions are routine engineering: commissioning a loop, running a bump test, taking a device offline for maintenance. They’re also exactly the actions that take a safety function offline or hold a valve open.

Why device- and signature-centric detection misses all three

Signatures only catch what has been seen before. A setpoint write has been seen millions of times. A mode change, thousands. None of these manipulations looks novel, so none of them matches a signature — and none of them needs malware, so none of them trips an endpoint agent. A device-centric view asks “is this device compromised?” and too often answers “no” while the process is being driven into an unsafe state.

The same problem shows up from the other direction. A process alarm will eventually fire when the lye concentration actually rises or the turbine overspeeds — but that’s the consequence, not the cause. By the time the consequence is measurable, the manipulation has already landed. Detection that only sees the device misses the act; detection that only sees the consequence misses the chance to act.

What process-aware detection actually watches

The alternative is to make the loop itself the thing you monitor, and to learn what this loop is supposed to do. That means watching relationships, not just traffic:

• Who may write. A setpoint register that has only ever been written by one engineering workstation is a different signal than a register written by everyone. A new writer is a flag.
• What ranges are valid. A setpoint that has lived between 95 and 105 for a year is a different signal than one suddenly written to 11,100. The flag isn’t “a write happened” — it’s “a write to a value this loop has never seen.”
• How fast things change. A process variable that moves in smooth, physically bounded steps is different from one that jumps. Rate-of-change is a property of the process, not the protocol.
• Which direction cause flows. A sensor feeds a controller, which drives an actuator. A packet that reverses that flow — an actuator reporting to a sensor, a sensor issuing a write — violates the loop’s causal structure.
• What state transitions are normal. Manual-to-automatic handoffs happen during commissioning, not at 03:00 on a Sunday.

There’s a clear-eyed boundary worth naming. A passive network monitor sees what crosses the wire. The hardwired 4–20 mA loop between a sensor and its controller never crosses the wire, so no network sensor can read it directly. What a behavior-aware platform can see is how the controller responds to the world it’s been given: a sudden output change with no matching justification in its network traffic, a mode flip with no accompanying engineering session, a setpoint write from an address that has never written before. A controller that’s been fed a false world often responds in a way that doesn’t add up — and that inconsistency is detectable.

And a word on the baseline itself, because it’s the part most often misunderstood. We freeze the baseline, not the detection — the attack is still fully caught. The baseline is the reference of normal; the detection stays live against it. An adversary who tries to poison that reference by drifting slowly over weeks is still caught in the act, and the act stays explainable: which asset, which account, which protocol, which register, at what time.

How do you baseline a process that is always changing?

You don’t baseline a setpoint as a single fixed number. You baseline the envelope it lives in and the shape of how it moves. A process that ramps up each morning and winds down each night has a normal that’s periodic, not static. The baseline captures that periodicity — the range, the rate, the schedule, the writer — so a change inside the normal band isn’t an alarm, while a change outside the pattern is. The goal isn’t to freeze the process. It’s to learn it well enough that a deviation stands out.

Doesn’t the control system already alarm on setpoint changes?

The control system alarms on process limits — a level too high, a temperature too low. It doesn’t, by default, alarm on a setpoint change that’s still inside those limits but outside the loop’s learned normal, and it doesn’t alarm on who issued the change or when. Those are exactly the manipulations that land quietly: the value is wrong for this loop, at this moment, from this source, but not yet wrong enough to trip a hard limit. Process-aware detection closes that gap by watching the write itself, not just its eventual consequence.

The loop is where the attack lands — so that’s where detection has to live

Most OT security spend is organized around devices: asset inventories, vulnerability scans, patch schedules, endpoint agents. Those all matter. But an adversary’s objective is never “compromise a device.” It’s always “change what the process does.” That change — a setpoint moved, a sensor spoofed, a state flipped — is the attack. And it’s only visible to something watching the loop and the relationships inside it, rather than the boxes on either end.

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.