Every OT security product sold today claims behavioral AI. The phrase has been repeated into meaninglessness, which is unfortunate, because the underlying idea is one of the few things that genuinely works differently in industrial networks than in enterprise IT.
The useful question is not whether a product uses machine learning. It is narrower and more answerable: which specific behaviors are being modeled, what happens when the model is wrong, and what an engineer sees at three in the morning when it fires. Those three questions separate a detection capability from a dashboard.
Why Industrial Networks Are the Environment Where This Works
Behavioral detection has a long history of disappointing people in enterprise IT, and for a defensible reason. A laptop belonging to a salesperson has no stable normal. It visits new domains daily, installs software, joins unfamiliar networks, and its owner changes roles. The baseline is so wide that anything inside it is uninformative and the tail is thick with benign novelty. That is where alert fatigue comes from.
An industrial controller is the opposite kind of object. A PLC executing a scan cycle does the same thing several hundred times per second, for years. It talks to a small and static set of peers: a handful of HMIs, a historian, an engineering workstation, sometimes a redundant partner. It speaks one or two protocols and uses a narrow subset of the available function codes, because the control logic written in 2014 has not changed. Its request sizes cluster tightly. Its poll interval has jitter measured in milliseconds.
This is not a statistical convenience. It is a consequence of the physics and the engineering discipline underneath. A pump either runs or does not. A valve position changes at a rate the actuator permits. Control logic is deliberately deterministic because non determinism in a safety instrumented system is a hazard. The result is a device population whose normal behavior is genuinely learnable with modest data and modest model complexity, which is exactly the condition under which anomaly detection stops being a research problem and starts being an engineering one.
The corollary matters just as much: when an industrial device does something outside its envelope, that deviation carries real information. In IT, novelty is the background. In OT, novelty is the signal.
What Is Actually Being Modeled
"Behavioral profile" is where most vendor descriptions become vague. In practice there are four distinct layers, and they detect different things.
The communication graph. Who talks to whom, in which direction, over which ports. This is the coarsest layer and the most valuable early, because it catches the structural violations: a device in the process cell reaching the enterprise network, a new host issuing writes to a controller, an HMI initiating a session it has only ever received.
Protocol semantics. Not that Modbus traffic occurred, but which function codes appeared, against which register ranges, and in which direction. A historian polling holding registers with function code 3 all year, then issuing a single write with function code 6, is a different event from a bandwidth spike. This layer requires decoding the protocol, not counting the packets.
Timing and cadence. Poll intervals, session durations, response latency distributions, the daily and weekly rhythm of a batch process. Timing is the layer attackers find hardest to imitate, because it emerges from how code actually executes rather than from what a packet declares.
Process values. Setpoints, commanded positions, and measured values, with their rates of change and their physical relationships to each other. This layer is where the network view meets the physics, and it is what distinguishes an unusual packet from a dangerous one.
A product that models only the first layer will call itself behavioral and will still miss the attacks that stay inside an existing communication path.
What the Record Actually Supports
Grounding this in real incidents is more honest than a hypothetical.
Triton, also called Trisis, discovered at a Saudi petrochemical facility in 2017, targeted Schneider Electric Triconex safety instrumented systems. The attackers reached an engineering workstation and used it to write to safety controllers over the vendor's proprietary protocol. Nothing about that required unknown malware signatures to be detectable. It required someone to notice that a host was speaking a safety controller protocol it had no history of speaking, and that a safety system entered program mode outside any maintenance window. The plant found out because the controllers tripped into a safe state, which is to say the safety system detected it, not the security program.
Industroyer in 2016 and Industroyer2 in 2022 both spoke legitimate grid protocols correctly: IEC 60870-5-104, IEC 61850, OPC DA. Signature matching on protocol validity would have found nothing wrong, because nothing was malformed. What was anomalous was the source, the sequence, and the timing of correctly formed commands.
The Oldsmar water treatment incident in 2021 is the clearest case for the process value layer. A remote session changed a sodium hydroxide setpoint by a factor of more than one hundred. Every packet was valid, the credentials were real, and the operator noticed only because he happened to be watching his screen. A model of the setpoint's normal range would have flagged it in seconds.
Colonial Pipeline in 2021 is the counterexample worth stating plainly. The ransomware executed on the IT side, and the OT shutdown was a precautionary business decision. Behavioral monitoring of controllers would not have prevented it. Any vendor who claims otherwise is selling backwards.
The pattern across Triton, Industroyer, and Oldsmar is that the malicious traffic was protocol correct and often credential valid. It was anomalous only relative to what those specific devices normally did. That is the entire argument for behavioral detection, and it is also why a model that has learned the wrong baseline is worse than no model at all.
The Failure Modes That Never Appear in a Demo
Baseline poisoning. If learning starts while an intrusion is already present, the intrusion becomes normal. Dwell times in industrial environments are frequently measured in months. Any deployment that trains silently and then declares itself ready has quietly assumed the network was clean on day one.
Concept drift that is legitimate. Plants change. A new production line, a seasonal recipe, a controller replaced under warranty, a maintenance window that shifts. A model that treats every legitimate change as an attack trains its operators to ignore it, and a model that adapts too eagerly will absorb a slow attack as normal. Where that threshold sits should be an explicit, documented choice, not an emergent property.
Scores without reasons. A confidence value of 0.87 is not a finding. An OT engineer cannot act on it, cannot dismiss it, and cannot escalate it to operations, because stopping a process has a cost measured in real money and the engineer will be asked to justify it.
Coverage assumed rather than verified. A model can only profile devices whose traffic it actually sees. Serial links behind protocol converters, traffic that never crosses a monitored uplink, and cells connected by unmanaged switches are invisible, and a clean dashboard will not say so.
What an Alert Has to Contain to Be Usable
An alert that survives contact with a control room states which device, what specifically differed from its established behavior, over what history that behavior was established, and what a legitimate explanation would look like.
"Engineering workstation ENG-04 opened a session to safety controller SIS-02 using a program download function. In 14 months of observation, ENG-04 has never communicated with SIS-02, and no host has issued a program download to SIS-02 outside a scheduled window. If this is planned work, expect a matching change ticket."
That is actionable. It names the deviation, quantifies the history, and tells the reader how to rule it out. It also happens to be exactly the standard IEC 62443 pushes asset owners toward: documented normal behavior per zone and conduit, and evidence when it is violated.
Questions worth asking any vendor: How long is the learning period, and what happens if a compromise is already present during it. Which of the four layers do you model, specifically. Show me an alert as an engineer would receive it, not a dashboard tile. How do you handle a planned process change. And which of my devices are you not profiling, and why.
The Practical Position
Behavioral detection in OT is not magic and it is not marketing. It is the reasonable response to an environment where device behavior is unusually stable, where attacks are protocol correct and credential valid, and where signatures for the relevant threats will not exist until after someone else has been hit.
What makes it work is unglamorous: seeing the traffic, decoding the protocols rather than counting bytes, modeling the specific layers that carry the attack, and producing findings a control engineer can act on without a data science degree. Passive collection from SPAN or mirror ports with full packet inspection is what supplies that depth, with flow telemetry such as sFlow or NetFlow useful as a complementary signal for coverage and volume. Nothing here requires touching a controller, and nothing here requires waiting for a vendor patch.
The test is simple. Ask what your current tooling would have shown during Oldsmar, and whether the answer is a detection or a phone call after the fact.