The Enemy Inside the Fence: Why OT's Biggest Blind Spot Wears a Hard Hat
The Enemy Inside the Fence: Why OT’s Biggest Blind Spot Wears a Hard Hat
In early 2000, the coastal town of Maroochy Shire, Queensland, had a sewage problem. Over the course of two months, raw effluent spilled into parks, creeks, and the grounds of a local hotel. Not once or twice — forty-six separate incidents. The operator at the water treatment plant couldn’t explain it. Pumps were activating on their own. Alarms were firing and then silencing. Someone, somewhere, was opening valves that had no business being open.
The culprit wasn’t malware. There was no phishing email, no zero-day exploit, no advanced persistent threat actor breaching a perimeter. It was a disgruntled former contractor — a man named Vitek Boden who had worked for the company that installed the SCADA radio-control system. After being rejected for a permanent council job, Boden took his knowledge of the system, a stolen two-way radio, and a laptop, and drove around the region transmitting commands that opened sewage valves remotely. He was caught not by an intrusion detection system or a SIEM alert — but by a traffic stop. A police officer pulled him over and found the radio equipment in his car.
If Boden had been a little more careful about where he parked, he might have gone months longer without detection. And the reason is sobering: every command he sent was legitimate. He was using the same radio protocol, the same SCADA commands, the same device IDs that the real operators used. From the control system’s perspective, nothing looked wrong. The person at the keyboard — or in this case, the radio — had all the right credentials.
Maroochy Shire is now twenty-six years old, but its lesson has aged remarkably well. The insider threat — the operator, the contractor, the engineer with legitimate access and illegitimate intent — remains one of the hardest problems in OT security. Not because we lack technology. Because we keep building defenses against the wrong adversary.
Three Kinds of Insider, One Detection Gap
When security teams hear “insider threat,” the image that usually comes to mind is a disgruntled employee bent on sabotage. That’s one category, and it’s real. But it’s not the most common one, and it’s certainly not the only one.
Malicious insiders — the Boden category — are people with current or recently valid access who use it to cause harm. They know the systems. They know which commands do what. They may even know how the monitoring tools work and how to avoid them. A 2025 case at a US power facility involved a former employee who attempted to alter load distribution settings remotely after his credentials hadn’t been revoked. The attack failed, but only because another operator noticed the change in the HMI and manually reversed it — human vigilance, not automated detection.
Accidental insiders are a larger group. These are the engineers and operators who make mistakes — a misconfigured PLC, a firmware update applied to the wrong device, a test script run on the production network instead of the lab. There’s no malicious intent, but the operational impact can be identical. A 2024 incident at a European chemical plant traced a three-hour production halt to an engineer who uploaded a configuration file to the wrong controller. The HMI showed normal readings. The plant appeared to be running. Downstream sensors only caught the problem when product quality failed inspection.
Compromised insiders are the bridge between the IT and OT threat landscapes. An operator’s corporate workstation gets phished. Their VPN credentials are stolen. Their remote-access session is hijacked. From the OT network’s perspective, the commands arrive from a trusted engineering workstation at the expected time of day with valid authentication. There is no signature for that. There is no CVE to patch.
The common thread across all three categories: the attacker — whether malicious, careless, or hijacked — operates inside the trust boundary. They use legitimate protocols, valid credentials, and authorised commands. And that’s exactly what makes them invisible to any detection approach that asks “is this command allowed?”
Why Credentials Don’t Solve This
OT environments are designed for safety and availability first, not authentication granularity. A SCADA operator’s credentials don’t just grant read access — they grant the ability to open a valve, stop a turbine, or reprogram a safety controller. Role-based access control in OT is often coarse: “Operator,” “Engineer,” “Administrator.” Within those roles, the system trusts that the person at the console is authorised to do whatever the role allows.
This creates a fundamental asymmetry. An IT security team can contain an insider threat by revoking Active Directory access, disabling a VPN account, or quarantining a workstation. An OT security team faces a different problem: the “insider” may need to retain some access to keep the plant running, even while they’re under investigation. You can’t lock out the shift supervisor without stopping a production line. And in many facilities, shared operator accounts — one login used by an entire shift — make it impossible to attribute actions to specific individuals anyway.
This is why insider threats in OT are not primarily an authentication problem. They are a behavioural problem. The question isn’t “does this person have permission to send this command?” The question is “does this command, at this time, from this device, in this sequence, look like normal operation?”
The Signature Trap
There’s a deeper problem. Most security tools — in both IT and OT — are built on the assumption that attacks have signatures. A known malware hash. A specific exploit pattern. An IP address on a threat intelligence feed. These work reasonably well for external threats, where you can study the adversary’s tools and build detection rules against them.
An insider doesn’t use malware. They use the HMI. They use the engineering workstation software that’s already installed. They use PuTTY, or RDP, or the vendor’s own configuration tool. They live off the land — and the land in an OT environment is the exact same software that keeps the plant running.
The Australian government commissioned one of the first formal post-mortems of the Maroochy Shire incident, and its findings were striking in their simplicity: the attack worked because the SCADA system had no way to distinguish between a legitimate operator command and an illegitimate one. The radio protocol treated all senders equally. Twenty-six years later, many OT networks still operate on the same premise — if you can reach the controller, you can command it.
What Detection Actually Needs to Look Like
If you can’t rely on credentials, and you can’t rely on signatures, what’s left? Behaviour. Specifically, the behaviour of the network — not the users, not the endpoints, but the traffic patterns that connect every device, controller, and workstation across the Purdue model.
A passive network detection and response (NDR) platform that learns what “normal” looks like for a specific OT environment can surface anomalies that credential-based and signature-based tools miss. Three examples make the point:
First, command sequence anomalies. In a water treatment plant, a particular pump activation is always preceded by a level-sensor check and followed by a flow-rate confirmation. If the pump-activation command arrives without the sensor check — or appears in a sequence that doesn’t match any historical pattern — that’s worth investigating. It doesn’t matter that the command itself is valid Modbus. The context is wrong.
Second, device-to-device relationship anomalies. An engineering workstation on Level 2 of the Purdue model may legitimately communicate with PLCs on Level 1 — but only a specific set of PLCs, on specific ports, at specific times. If that same workstation suddenly reaches out to a safety instrumented system it has never touched before, the protocol is valid, the credentials are valid, and the action may be catastrophic. Only the network baseline catches it.
Third, temporal anomalies. Boden carried out his attacks during working hours, blending into normal SCADA traffic. But a night-shift command to reconfigure a PLC that has only ever been reconfigured on Tuesdays at 10 a.m. — that’s a signal. Not because the command is forbidden, but because the pattern doesn’t match.
These aren’t hypothetical. They’re the detection primitives that separate a tool that asks “is this allowed?” from a tool that asks “does this make sense?”
From Detection to Deterrence
There’s a second-order effect worth mentioning. When operators and engineers know that a passive NDR system is learning the network’s normal behaviour — and will surface deviations — it changes the insider calculus. The malicious insider who knows their commands are being compared against a historical baseline, not just a permissions table, faces a much harder problem. They can’t just stay inside their authorised scope. They have to make their malicious commands look sufficiently normal — and that constraint alone limits the damage they can do.
This isn’t surveillance. It’s systems thinking. The network already produces the telemetry. The question is whether anyone is listening.
Maigadi Networks builds the OT/ICS network detection and 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.