Every OT security pitch deck now has an AI slide. Some of it is real: industrial processes are repetitive enough that machine learning can genuinely spot a drifting sensor, an off-profile flow pattern, or a login sequence that looks nothing like the operator it claims to be. And some of it is a marketing layer over a rules engine. This guide gives operations managers and OT engineers an honest map - what anomaly detection actually is, where ML earns its keep, where it collapses into false-positive fatigue, why deterministic controls still catch most real intrusions, and the exact questions that separate vendors with capability from vendors with a slide.
Part of the SCADA Security Hub - 60+ guides on SCADA security, compliance & certifications.
The phrase covers at least four very different things, and the first job of a buyer is to find out which one is actually in the product:
None of these categories is bad. What is bad is category confusion: a vendor demonstrating a rules engine and pricing it like a research lab, or a buyer skipping the deterministic foundations because "the AI will catch it." The rest of this guide is about putting each layer in its place.
All anomaly detection follows one loop: define normal, observe reality, flag the difference. The differences between products are in how "normal" is defined and how the inevitable ambiguity is handled.
OT is, on paper, the friendliest possible environment for this. A compressor station or a treatment train does approximately the same thing every day; its network speaks a handful of protocols between a fixed cast of devices; its operators log in from known places at known hours. Compared to a corporate IT network - thousands of users doing genuinely novel things daily - the industrial baseline is narrow, which is why OT network-monitoring vendors have built an entire product category on passively learning it.
The catch is the other half of the loop: a deviation is not an intrusion. Normal in an industrial system changes constantly for legitimate reasons - a maintenance bypass, a seasonal load swing, a well coming off plateau, a product changeover, a new PLC added on Tuesday. Every one of those looks anomalous to a model trained on last quarter. What you do with that ambiguity - tuning, suppression, human triage - determines whether the tool becomes part of operations or part of the ignored-alarm pile.
Used honestly, machine learning is good at exactly the things rules are bad at - subtle, multivariate, slow-moving deviations that no one thought to write a threshold for:
The failure modes are just as specific, and vendors rarely volunteer them:
Here is the uncomfortable truth under the hype: most real intrusions announce themselves in ways that need no model at all. Failed-login storms. Access-denied events piling up as an account probes for privileges it does not have. Requests attempting to cross a tenant boundary. A viewer-role account attempting a setpoint write. Telemetry arriving with a broken signature or a replayed sequence number. Every one of these is a binary fact, detectable with a rule, explainable in one sentence, and actionable immediately.
| Attribute | Rule-Based Detection | Statistical Baselining | Machine Learning |
|---|---|---|---|
| Catches | Known-bad patterns: auth failures, privilege probes, bounds violations, signature failures | Out-of-band values and rates against historical norms | Subtle multivariate deviations no one wrote a rule for |
| False-positive profile | Very low - fires on facts | Moderate - needs tuning for seasonality | Highest - sensitive to concept drift and operational change |
| Data required | None - works from day one | Weeks of history | Months of history; retraining after process changes |
| Explainability | Complete - the rule is the explanation | Good - deviation from a stated band | Often poor without deliberate design |
| Blind spot | Novel patterns nobody anticipated | Multivariate and slow-moving anomalies | Attacks that stay inside learned normal; poisoned baselines |
| Right role | Foundation - non-negotiable | Second layer - cheap and effective | Third layer - additive, after the first two work |
The order matters. A platform with weak authentication and unsigned telemetry does not need an anomaly model; it needs authentication and signed telemetry - the baseline hygiene captured in CISA's Cross-Sector Cybersecurity Performance Goals. Buy the layers in the order they fail-safe: deterministic controls, then statistical guardrails, then - if your operation and team can absorb the triage load - learned models on top.
Every detection layer, from the dumbest threshold to the fanciest model, shares one assumption: the data it watches is real. If telemetry can be forged or replayed on the wire, an attacker does not need to evade your analytics - they feed the analytics a normal-looking lie while the process does something else. Stuxnet's operators - the subject of CISA's primary Stuxnet advisory - understood this two decades ago; they replayed normal readings to the operators while centrifuges tore themselves apart.
That is why data integrity is the unglamorous prerequisite for every AI ambition. Merobix devices generate their own Ed25519 (RFC 8032) signing identities and wrap telemetry in signed envelopes carrying sequence numbers, timestamps, sample IDs, and payload digests, with replay detection on ingest - so a reading that reaches the platform provably came from that device, once, in order. Anomaly detection over authenticated data hunts real anomalies; anomaly detection over spoofable data hunts its own tail. The full mechanics are in our telemetry integrity guide.
Merobix is deliberately deterministic-first. The platform runs runtime threat monitoring built on facts rather than scores: it detects cross-tenant access denials, privilege probes, repeated authentication failures, and suspicious control activity, and pairs that with brute-force detection and persistent account lockout on the identity layer. Just as importantly, it treats alert delivery as part of detection - security notifications flow through a durable outbox with retry and dead-letter handling to email, SMS, webhooks, or your SIEM, because a detection that dies in a failed HTTP POST never happened. Health surfaces track API dependencies and telemetry freshness, so "quiet" and "broken" are distinguishable. And on the roadmap, Merobix is building continuous independent validation - including replay and forgery testing and cross-tenant testing - to keep pressure-testing those detections rather than trusting them. The architecture is documented on the security page, and the SIEM integration patterns are covered in our threat detection and SIEM guide.
Eight questions, in the order that ends meetings fastest:
The honest framing: AI in OT security is a third layer, not a first principle. Deterministic controls and rule-based detection catch most real intrusions, work on day one, and never need retraining; statistical baselines cheaply catch the next tier; learned models add reach at the cost of triage load - and all three are only as good as the integrity of the data beneath them and the delivery path above them. Buy foundations first. See how Merobix builds those layers on the security architecture page, or probe the detection stack yourself in a live demo.
Partially. Machine learning is genuinely useful for spotting deviations in well-instrumented, repetitive processes - a sensor drifting, a flow profile that no longer matches its history, a login pattern that looks nothing like the operator's normal behavior. But most real intrusions are caught by deterministic controls and rule-based detection: failed-login storms, privilege probes, commands from accounts that should not command, telemetry that fails signature or replay checks. AI is a useful additional layer on top of those foundations, not a replacement for them, and any vendor pitching it as a replacement is selling hype.
Anomaly detection means building a baseline of normal behavior - process values, network traffic, protocol usage, or user activity - and flagging deviations from it. Implementations range from simple thresholds and rate limits, through statistical methods like moving averages and control bands, to machine-learning models that learn multi-variable patterns. In OT it is attractive because industrial processes are more repetitive than IT networks, which makes normal easier to define; the perennial challenge is that legitimate operational change - maintenance, season, product changeover - also deviates from baseline and generates false positives.
No. The controls that stop most real-world OT incidents are deterministic: multi-factor authentication, role-based access, network segmentation with no inbound exposure, signed and replay-protected telemetry, setpoint bounds checking, immutable audit trails, and rule-based detection of known-bad patterns like repeated auth failures or cross-tenant access attempts. These work on day one, produce explainable alerts, and require no training data. Add ML-based analytics after those foundations exist - as an extra detection layer - not before, and not instead.
Because industrial normal keeps changing for legitimate reasons. Seasonal load swings, product changeovers, maintenance outages, well decline, new equipment, and operator workarounds all shift the baseline a model learned, and the model flags the shift as anomalous. This is concept drift, and it is worse in OT than IT because retraining windows are long and labeled attack data is scarce. Persistent false positives lead to alert fatigue - operators mute or ignore the tool - at which point the detection layer exists on paper and not in practice. Ask vendors for false-positive rates from environments like yours, not lab benchmarks.
Make them get specific. Ask what is actually rule-based versus statistical versus machine-learned, what data the models train on and whether your data trains anyone else's models, what the observed false-positive rate is in comparable deployments, how long the system needs to learn a baseline, what happens when a model flags an event - who is notified, through what guaranteed delivery path - and whether an operator can see why an alert fired. A vendor with real capability answers concretely; a vendor with a marketing layer changes the subject to the demo.
Runtime threat monitoring, signed telemetry, and guaranteed alert delivery - the deterministic foundation every analytics layer depends on. See it working on real data.