OT Baseline works by establishing what normal looks like for devices, traffic, users, and process behaviour in an operational environment. Teams compare current activity to that baseline to spot new assets, configuration drift, suspicious communications, and unexpected control changes. The baseline must be reviewed regularly because plant changes, maintenance, and seasonal operations alter normal behaviour.
What OT baseline is measuring
ot baseline is a reference picture of normal behaviour in an operational environment. It captures how devices, traffic patterns, users, and control processes usually behave so teams can compare live activity against expected conditions. That comparison is what turns ordinary monitoring into meaningful anomaly detection.
A useful baseline is not just an inventory list. It needs enough context to tell the difference between a legitimate plant action and a change that deserves attention, such as a new asset appearing, a controller talking to an unexpected destination, or a process command outside the normal operating pattern. The practical goal is to make “normal” observable, repeatable, and defendable.
How the baseline is built and maintained
Teams usually build the baseline from passive observation first, then refine it with engineering knowledge from operations, maintenance, and process owners. The strongest baselines combine network behaviour, host or controller characteristics, user activity, and process state so the model reflects the whole environment rather than one narrow signal.
Maintenance matters as much as initial discovery. OT environments change through firmware updates, seasonal operating modes, scheduled shutdowns, emergency workarounds, and production expansion. If the baseline is not reviewed and reapproved regularly, it starts treating legitimate change as noise or, worse, allows drift to become the new normal without scrutiny. For asset visibility and protocol-aware monitoring, OT Asset Visibility Guide is the most direct internal reference.
That review process should be controlled, not ad hoc. OT baselines work best when each change is tied to a business reason, an operational owner, and a known time window, so the team can separate accepted variation from unintended drift.
What it is used to detect in practice
The value of OT baseline is in finding meaningful deviations early. It can reveal new assets that were never approved, lateral communications that break segmentation assumptions, configuration changes on engineering workstations or controllers, and process changes that do not match the expected production state. It can also expose shadow remote access paths or a device that begins speaking a protocol it never used before.
Baseline comparison is especially useful because OT compromise often looks like ordinary activity at first. Attackers and unauthorized operators may blend into normal traffic, reuse valid credentials, or make small control changes that only stand out when compared with established behaviour. For operational security context and control-basis guidance, see NIST SP 800-82 Rev 3 and CISA Industrial Control Systems.
When the baseline is mature, it also helps separate maintenance from compromise. A controller reboot, a temporary bypass, or a planned recipe change may be acceptable only inside a known maintenance context, while the same action outside that context should trigger review.
Risk and Threat Considerations
OT baseline fails when the environment changes faster than the baseline is updated, or when teams trust the baseline more than they trust plant reality. In that case, genuine drift can be normalised, and real malicious or unsafe changes can hide inside approved exceptions.
Failure mechanism: An attacker, contractor error, or uncoordinated maintenance change can alter communications, permissions, or controller behaviour in a way that blends into stale baseline data. If segmentation, device inventory, or process ownership is weak, the monitoring layer may accept abnormal behaviour as expected.
Impact: Missed detection can lead to unsafe process changes, loss of view of new assets, delayed incident response, and longer dwell time for an intruder or unauthorised operator. In critical environments, that can turn a visibility gap into an availability or safety issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | OT baselines exist to detect unauthorized or unexpected OT activity. |
| DE.AE-01 — Anomalies and Events Are Analyzed | Baseline comparison is the core mechanism for identifying abnormal OT behaviour. | |
| Recommendation — Monitor OT assets, connections, and software for deviations from the established baseline. Analyze baseline deviations to determine whether OT anomalies require response. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | OT baselines depend on defining and maintaining an approved configuration baseline. |
| CM-8 — System Component Inventory | OT baseline needs accurate asset visibility to spot new or unexpected devices. | |
| SI-4 — System Monitoring | OT baseline feeds continuous monitoring for anomalous communications and changes. | |
| Recommendation — Establish and maintain approved baselines for OT assets and configurations. Maintain an accurate OT component inventory to detect unapproved additions. Use system monitoring to flag OT behaviour that diverges from the baseline. | ||
Practitioner Guidance
What to verify: Confirm that the baseline reflects at least four things at once: known assets, known communications, known user and engineer activity, and known process states. If it only covers one of those, it is too shallow to be operationally reliable.
Common mistake: Treating the first stable observation window as permanent truth. OT baselines should be versioned, reviewed after plant changes, and aligned to operating modes, because a “good” baseline in one season or production phase can be misleading in another.
What practitioners underestimate: Exception handling. A baseline is only useful if the team can explain why a deviation was approved, who approved it, and when that approval expires. Without that discipline, baseline review becomes a checkbox instead of a detection control.
Practitioner takeaway: The best OT baseline is not the most detailed one, it is the one that stays current enough to distinguish approved operational variation from drift that needs investigation.
Related resources from NHI Mgmt Group
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams build a credible manual cost baseline before automating repeatable identity or access work?
- How should security teams baseline Active Directory security in legacy environments before they start remediation work?
- Why do network segmentation and PKI work better together in OT security?