Organisations get started with OT Threat Detection by defining the behaviours, assets, and events that indicate compromise in their environment. Use asset inventory and network baselines to tune detections for unusual commands, unauthorised remote access, new paths between zones, and process anomalies. Responses must be coordinated with operations so alerts do not cause unsafe actions.
What to define before OT detection rules go live
Getting started is less about buying alerts and more about deciding what “bad” looks like in your plant, substation, or control network. The first working set should be built from the assets, zones, remote access paths, and process states that matter most, because OT detection has to reflect operational reality, not generic IT assumptions.
That means you need a detection scope that is tied to equipment criticality, protocol behaviour, and the commands or traffic patterns that should almost never change without a planned work order. A useful starting point is to anchor that scope in an OT asset inventory and a network baseline, then define the small number of behaviours you can reliably watch without disrupting operations. For visibility and baseline design, OT Asset Visibility Guide is a natural starting point.
The practical question is not whether you can detect everything, but whether you can detect the few things that indicate compromise early enough to matter. In OT, that usually includes unusual command sequences, new communications between zones, unexpected engineering workstation activity, and remote access that does not fit the normal maintenance pattern.
How to turn baselines into useful detections
Once the environment is mapped, start with detections that compare current behaviour to normal operational patterns. Baselines should reflect time of day, process stage, maintenance windows, vendor support workflows, and normal protocol use, because OT systems often look quiet and repetitive until something changes. The point is to spot meaningful drift, not to flag every unusual packet.
Good starter detections often focus on a few high-value conditions: a new remote session into an OT zone, commands sent from an unexpected host, scans or enumeration where no such activity belongs, or process changes that do not align with scheduled operations. This is why many teams pair visibility work with a broader view of common OT attack paths and exposures. A concise reference for those patterns is Top 10 OT Security Risks, which helps translate architecture weaknesses into detection priorities.
Baselining should also distinguish between passive observation and active response. In OT, a detection that is technically accurate but operationally noisy can still be a failure if it causes unnecessary intervention. The first iteration should therefore favour high-confidence alerts that can be triaged safely, then expand as operators trust the signal.
How to operationalise detection without disrupting the plant
ot threat detection only works if security and operations agree on what happens when an alert fires. That usually means a shared playbook for triage, escalation, and containment, plus clear rules for when an alert is informational, when it requires operator validation, and when it can trigger a technical response. The response path must fit the process environment, not force a generic IT containment action onto a control system.
For teams choosing tooling or designing a phased rollout, the most useful guide is one that focuses on safe discovery, protocol coverage, and OT use cases rather than generic NDR features. OT Security Platform Buyer’s Guide is relevant because the initial goal is to pick controls that support safe visibility, tuning, and operationally acceptable response.
A sensible rollout sequence is: inventory the assets, map the zones and conduits, identify the small set of suspicious behaviours you can observe safely, tune alerts against known maintenance and process activity, then rehearse operator-approved response steps. The fastest way to create mistrust is to alert on activity that looks unusual in IT terms but is normal in a live control environment.
Risk and Threat Considerations
OT detections fail when they are too generic, too noisy, or disconnected from the process context they are meant to protect. That creates two risks at once: real compromise can blend into normal operations, and an overzealous alert can push operators toward a response that disrupts production or safety.
Failure mechanism: Attackers and unauthorized users often exploit weak remote access, flat internal paths, or poor asset visibility to move quietly between zones. If baselines are not tuned to OT behaviour, the environment may either miss that movement entirely or react to harmless operational change instead of the compromise.
Impact: The result can be delayed detection of intrusion, loss of confidence in the alerting program, or unsafe containment actions that interfere with industrial processes. In OT, a missed or mistimed response can become an availability or safety issue, not just a security gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | OT detections rely on reviewing anomalous events and operator-confirmed activity. |
| SI-4 — System Monitoring | Continuous monitoring is central to spotting OT anomalies and compromise indicators. | |
| AC-17 — Remote Access | Unauthorized or unexpected remote access is a core OT detection concern. | |
| Recommendation — Review OT alerting and event data for unusual commands, remote access, and zone-crossing activity. Monitor OT assets and network traffic for deviations from the established baseline. Restrict and monitor remote access paths into OT zones. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | OT detection starts with asset visibility, segmentation, and network baselines. |
| CIS-13 — Network Monitoring and Defense | The subject is fundamentally about monitoring OT behaviour for compromise indicators. | |
| Recommendation — Map OT assets and network flows so detections can distinguish normal from suspicious activity. Deploy monitoring that flags unusual commands, new paths, and unauthorized remote sessions. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | OT threat detection is a direct application of network and service monitoring for adverse events. |
| ID.AM-01 — Physical devices and systems within the organization are inventoried | Asset inventory is the starting point for defining OT baselines and detection scope. | |
| PR.PS-01 — Configuration management is used to maintain and improve security | Safe baseline-driven detection depends on knowing intended configuration and change. | |
| Recommendation — Establish monitoring that can identify unusual OT traffic and access patterns. Inventory OT assets before tuning detections to expected behaviour. Use configuration baselines to separate expected OT change from suspicious deviation. | ||
Practitioner Guidance
What to prioritise: Start with the assets, zones, and remote access paths that have the highest operational consequence, then define detections around behaviours that are both observable and meaningful in that environment. Avoid broad rule sets that cannot be validated against plant activity.
What to verify: Before trusting an alert, confirm that the rule is anchored to a normal baseline, that operators recognise the activity class, and that the response does not interrupt a live process. If a detection cannot be explained in operational terms, it is not ready for production use.
Practitioner takeaway: OT threat detection becomes effective when the alert model is built around process-aware baselines and operator-safe response, not when it tries to imitate enterprise SOC detection patterns.