An OT network baseline is a learned model of what normal traffic on a control network looks like: which devices talk to which other devices, over which protocols, and in roughly what pattern. Once that model is established, an anomaly-detection engine can treat anything that does not fit it as suspicious, because on a well-run control network almost nothing new should ever appear. This works far better in OT than it ever could in IT for one reason: industrial traffic is deterministic and repetitive, so the baseline is stable and deviations stand out sharply. This page explains how a baseline is built, what a deviation from it means, and why the predictability of control networks makes this a uniquely reliable detection method.
OT Network Baseline in one line: An OT network baseline is a model of normal communication on a control network, capturing which devices communicate with which others, on what protocols, and in what pattern, usually learned by observing traffic during a training period. Once the baseline is set, anomaly detection flags any traffic that deviates from it, such as a new device, an unexpected connection, or an out-of-place command. It is highly reliable in OT because control traffic is deterministic and repetitive, so the baseline stays stable and genuine deviations are rare and meaningful.
A baseline usually begins with a learning period during which a passive sensor watches the network and records what it sees without judging any of it. It notes every pair of devices that communicate, the protocol each pair uses, and the direction and nature of the exchange, gradually filling in a map of normal behavior. The core of that map is often described as a connection matrix, a grid of who talks to whom, where each observed relationship becomes an allowed entry. After enough time to capture the full production cycle, including periodic tasks that only run occasionally, the matrix represents the network's normal state.
The result is effectively an allowlist of behavior rather than a list of known-bad things to block. Instead of enumerating attacks to look for, the baseline enumerates what is permitted and treats everything else as an exception. This is the inverse of the traditional signature approach and it is powerful precisely because a control network is small and stable enough to describe positively. You can realistically list every legitimate conversation on a control cell, which you could never do on an office network where users open arbitrary connections to the wider internet all day long.
A good baseline captures more than just endpoints. It can learn which protocols and even which specific commands each device normally uses, the typical timing and frequency of exchanges, and which direction commands flow, so that a controller normally commanding its I/O is understood differently from a workstation that only reads. The richer the baseline, the more specific the anomalies it can catch, but the harder it is to keep from flagging benign variation. Tuning the baseline to the right level of detail, and confirming the learning period truly covered normal operation before you trust it, is the practical craft of making anomaly detection useful rather than noisy.
Once the baseline is trusted and the sensor switches from learning to enforcement, its job is to compare live traffic against the model and raise an alert on anything that does not fit. A device that never appeared during learning suddenly communicating is a deviation. An existing device reaching a destination it never spoke to before is a deviation. A protocol showing up on a link that only ever carried a different one, or an engineering-class command arriving from a source that only ever read data, are deviations. Each of these is, in a control network, genuinely unusual and worth an operator's attention.
The value of this approach is that it catches novel activity without needing to know in advance what an attack looks like. A brand-new piece of malware, a legitimate tool used illegitimately, or an insider connecting a laptop to an engineering port all produce traffic that was not in the baseline, and all trip the same detection even though none matches a known signature. That is the central promise of baseline anomaly detection: it flags the fact of abnormality rather than the identity of a specific threat, which is exactly what you want against attacks nobody has catalogued yet.
The obvious risk is false positives from legitimate change. A commissioned new device, a firmware update that alters traffic, or a maintenance activity can all deviate from a baseline that predates them, and if every such change triggers an alarm the operator soon learns to ignore the system. Managing this means maintaining the baseline as the plant legitimately evolves, updating it deliberately when authorized changes are made, and distinguishing a one-time approved change from a persistent unexplained one. A baseline is a living model of a network that is supposed to be stable, and keeping it accurate is what keeps its alerts credible.
The reason baseline anomaly detection is so much more effective in OT than in IT comes down to how predictable the traffic is. A control network runs the same program continuously: a PLC scans its I/O on a fixed cycle, a SCADA master polls its RTUs on a schedule, and reports flow at set intervals. Day to day the same devices exchange the same kinds of messages in the same pattern, so normal is a narrow, well-defined target and anything outside it is conspicuous. This determinism is not incidental. It is a design property of control systems that must behave repeatably to run a physical process safely.
IT networks are the opposite. Users browse arbitrary websites, install software, join video calls, and connect to services that change constantly, so normal is a wide, shifting cloud with no stable edges. A baseline of who-talks-to-whom on an office network is obsolete almost as fast as you build it, and the rate of legitimate novelty is so high that anomaly alerts drown in noise. This is why signature-based detection has historically dominated IT security, because the negative approach of listing known threats scales better than trying to describe an ever-changing normal.
OT flips that logic, and modern monitoring exploits it. Because the network is deterministic, a learned baseline stays valid for a long time, deviations are rare, and each one is meaningful enough to justify attention. This is also why the technique carries so well into remote and cloud-based monitoring. A cloud SCADA or security platform such as Merobix can learn a baseline for each remote site's steady polling pattern and immediately notice when a distant, normally quiet RTU starts talking to something new, which on a deterministic control link is a strong and specific signal. The very predictability that makes control networks safe to operate is what makes their deviations so easy to trust as evidence of trouble.
Long enough to observe a full cycle of normal operation, including tasks that only run occasionally. On a network that repeats the same activity minute to minute, the common conversations appear quickly, but periodic events like a nightly batch, a weekly report, or a monthly maintenance routine only show up on their own schedule. A learning period that ends before those occasional but legitimate activities occur will flag them as anomalies later, so the baseline should span at least one complete operational cycle before you trust it for enforcement.
It will if the baseline is never updated, because any legitimate change that adds new traffic deviates from a model that predates it. The answer is to treat the baseline as a living document and update it deliberately whenever an authorized change is made, such as commissioning a device or applying a firmware update. Well-run anomaly detection distinguishes a one-time approved change, which you incorporate into the baseline, from a persistent unexplained deviation, which stays flagged until someone accounts for it.
Because OT traffic is deterministic and IT traffic is not. A control network runs the same program continuously, with the same devices exchanging the same messages on a fixed cycle, so normal is a narrow, stable target and anything outside it stands out. An office network is full of users browsing, installing software, and connecting to ever-changing services, so normal is a wide and shifting cloud where a baseline goes stale immediately. The predictability that lets a control system run a physical process safely is exactly what makes its deviations easy to detect.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.