What are the key OT Baseline best practices?

What belongs in an OT baseline?

An effective OT baseline is a reference state for safe, normal operations. It should capture the devices in each segment, the approved firmware and configurations, the expected network flows, the accounts allowed to connect, and the process limits that define acceptable operation. A useful baseline is specific enough that drift, unauthorised connections, and unexpected changes become visible quickly.

Baselines work best when they are tied to how the environment actually runs, not to a generic checklist. For OT, that means distinguishing by asset criticality, control loop, site, and segment, because a “normal” state in one area can be unsafe in another.

How to maintain and use the baseline operationally

Baseline quality depends on discipline over time, not on the original inventory exercise. Review it after engineering change, keep versions, record the reason for each approved deviation, and make sure monitoring compares live activity against the expected state. When the baseline is used as a detection reference, it becomes part of both operational assurance and incident triage.

For OT environments with limited tolerance for disruption, the baseline also helps separate authorised maintenance from suspicious drift. That distinction matters because many anomalies are benign only when they are linked to a planned change record, maintenance window, or approved temporary exception.

Good OT baseline practice aligns closely with NIST SP 800-82 Rev 3, which treats OT security as a matter of known architecture, segmentation, and monitored control states rather than generic IT hardening. It also fits the operational focus of CISA Industrial Control Systems guidance, where asset visibility and secure operations are treated as ongoing functions, not one-time projects.

What makes OT baselines fail in practice?

Baselines fail when they are too broad, too stale, or too difficult to compare against live OT conditions. If the reference state is incomplete, teams miss drift in firmware, routings, protocol usage, or remote access paths. If the baseline is updated casually, it stops being a reliable detector of abnormal behaviour. If it is never reconciled with engineering changes, it quickly becomes a historical document rather than an operational control.

Another common failure is allowing exceptions to accumulate without expiry. In OT, temporary access, ad hoc engineering tools, and emergency connectivity often become permanent unless someone actively reviews them. That creates blind spots in segmentation, process integrity, and accountability.

Baseline governance also depends on the quality of the supporting inventory and hardening discipline. The idea is similar to using CIS Benchmarks for device and platform hardening, but adapted to OT constraints and vendor-supported configurations. Where OT baseline drift is tied to credentials, remote management, or exposed interfaces, a guide such as OT Asset Visibility Guide helps connect visibility, inventory, and monitoring into one control loop.

Risk and Threat Considerations

OT baselines are security controls because they define what “normal” looks like for systems that can affect physical process behaviour. If the baseline is weak or outdated, unauthorised connectivity, configuration drift, or rogue engineering changes can blend into routine operations and delay detection.

Failure mechanism: Attackers or insiders exploit stale inventories, unmonitored exceptions, or poorly segmented connectivity to introduce changes that look operationally plausible, especially when firmware, protocols, or remote access paths are not versioned and compared consistently.

Impact: The result can be loss of visibility, unsafe process behaviour, unplanned downtime, or a slower response to compromise because the team no longer has a trustworthy reference for what should be running.

Practitioner Guidance

What to verify: Confirm that each critical segment has a documented baseline for assets, firmware, network flows, user access, and operating limits, and that the reference is specific enough to spot change rather than merely describe the environment.

Decision rule: If a change cannot be matched to an approved work order or engineering record, treat it as drift until proven otherwise. If the change affects safety, segmentation, or control logic, escalate before normalising it.

What good looks like: The OT baseline is versioned, reviewed after each engineering change, and used by monitoring or review processes that can distinguish expected maintenance from unexpected deviation.

Practitioner takeaway: The value of an OT baseline is not completeness on paper, but whether it gives operators a trusted comparison point that makes unsafe or unauthorised change unmistakable.

Related resources from NHI Mgmt Group

• What are the key oil and gas OT security best practices?
• What are the key pharmaceutical OT security best practices?
• What are the key food and beverage OT security best practices?
• What are the key OT Patch Management best practices?