By RODEO INFOSEC CORP · October 22, 2026 · ~7 min read
Operational technology is not just IT that happens to sit in a plant. OT and industrial control systems (ICS) run physical processes — turbines, pumps, breakers, valves, assembly lines — and the programmable logic controllers (PLCs), RTUs, and SCADA systems that drive them were engineered for determinism and uptime measured in years, not for the churn of a modern enterprise network. When security tooling built for IT is dropped onto that environment, the result is not just friction. It can be an outage, or worse.
Defending these networks is entirely possible, but it starts from a different first principle: do no harm to the process.
Why IT security tooling is dangerous in OT
The instincts that serve you well in IT are actively hazardous on a control network:
- Active scanning can crash devices. An aggressive vulnerability scan or port sweep that a server shrugs off can knock a fragile legacy PLC offline. On a control network, a crashed controller is not an inconvenience — it is a stopped or unsafe process.
- Agents often cannot be installed. Much of the installed base is old, embedded, and vendor-locked. There is no endpoint agent to deploy, and loading one may void support or certification.
- Patching windows barely exist. Devices run for a decade or more, and taking a process down to patch is a major, scheduled event. “Just update it” is usually not available.
- The protocols are fragile and trusting. Modbus, DNP3, EtherNet/IP, PROFINET, and OPC were largely designed without authentication or encryption, assuming a physically isolated network. They do not tolerate unexpected traffic well.
The common thread: anything that injects traffic or load into the control network is a risk to the physical process. Safety and availability come first — the familiar IT priority order is inverted.
The priority inversion, and the Purdue model
In IT, the usual order is confidentiality, then integrity, then availability. In OT it flips: availability and, above all, safety lead. A confidential breach is bad; a control system that behaves unexpectedly can hurt someone. Standards like IEC 62443 and NIST SP 800-82 are built around exactly this reordering.
It also helps to think in terms of the Purdue model, which layers an industrial environment from Level 0 (the physical sensors and actuators) and Level 1 (controllers and PLCs) up through Level 2 (supervisory control, SCADA, HMIs), Level 3 (site operations), a Level 3.5 DMZ, and Levels 4–5 (enterprise IT). The closer monitoring sits to Levels 0–2, the more conservative it has to be, because that is where bytes become physical motion.
What “safety-pinned” means
Safety-pinned is the design rule that security monitoring and any automation are hard-bounded so they can never affect the process. Concretely:
- Passive and read-only by default. Visibility comes from observing traffic — a span port or network tap — not from probing devices. The monitoring footprint on the control network is zero added traffic.
- Automation inside a fixed envelope. Any automated action is constrained to an explicitly approved set; the system cannot take an action on the control network that falls outside that envelope, no matter what it concludes.
- No autonomous action at the dangerous layers. Near Levels 0–2, response is proposal-only: the system recommends, a human decides. Nothing blocks, resets, or reconfigures a controller on its own.
The pin is not a setting you can nudge up during an incident. It is a boundary the system is built not to cross.
Monitoring without disruption
Within those limits there is a great deal you can see. Passive, protocol-aware monitoring parses OT protocols to build an asset inventory without ever polling a device, baselines normal process and communication behavior, and flags the things that actually matter in ICS: unexpected engineering-workstation connections, unauthorized logic changes, new or rogue devices, and command sequences that deviate from the established pattern. None of it requires touching a PLC. It is the OT-appropriate version of the detection engineering covered in the note on generating Sigma, Suricata, and YARA detections — tuned to industrial protocols and process behavior.
Human-gated response, always
On a control network, an automatic block is itself a potential cause of an outage — the cure can be worse than the disease. That is why response in OT has to stay human-gated: the system surfaces a high-confidence finding and a recommended action, and a qualified operator who understands the process decides whether and when to act. This is the same graduated, approval-gated autonomy RODEO applies everywhere, simply held at its most conservative setting where the stakes are physical. And because many of these environments are isolated by design, the monitoring and analysis have to run with no outbound connectivity at all — the constraint covered in the note on running security AI offline.
How R-O-D-E-O approaches it
RODEO treats OT as native, not an afterthought. Its ICS/SCADA capability runs passively and protocol-aware, and deployments into operational technology are safety-pinned: automation is bounded so it can never act outside an approved envelope, and response near the process stays proposal-only, with a human in the loop and every action logged and mapped to a control. The models run on local weights so the whole thing works inside an air-gapped plant, and the platform ships in editions sized to the environment — including profiles built for SCADA and OT. The whitepaper details how the OT deployment model and its safety constraints fit the rest of the architecture.
Defending industrial systems is not about bringing IT security to the plant floor. It is about earning visibility and response while guaranteeing, by design, that the tool protecting the process can never be the thing that disrupts it.