Yes. Detection and prevention solve different problems and should not be confused. Detection informs triage and investigation, while prevention enforces boundaries and blocks threats. OT programs need both, but they should measure prevention by whether it actually stops threats without disrupting operations.
Why OT Detection and Prevention Belong in Separate Control Layers
In OT, prevention and detection solve different problems, so using one as a substitute for the other creates blind spots. Prevention is about boundary enforcement and reducing the chance of unsafe traffic or actions reaching a control environment; detection is about seeing what still gets through, confirming whether something is happening, and supporting investigation and response when operations must stay up.
That split matters because OT environments often carry safety, availability, and process-continuity constraints that change how much enforcement you can safely apply. A control that blocks too aggressively can create operational harm, while a control that only logs activity can leave the plant exposed unless someone is actually watching and able to act on the signal.
What Prevention Actually Does in an OT Program
Prevention is the layer that narrows what is allowed to happen in the first place. In practice, that usually means segmentation, protocol-aware filtering, access restriction, change control, and tightly scoped remote access so that only expected commands, paths, and sessions can reach the right assets.
The important judgment is that prevention should be measured by boundary integrity, not by how many alerts it generates. A good preventive control stops clearly out-of-policy activity, but it also has to respect process constraints, vendor dependencies, and maintenance workflows. If the control is too broad, operators will bypass it; if it is too weak, it becomes symbolic rather than protective.
Prevention is also where architecture choices matter most. If the OT network is flat, or if remote access lands directly on critical equipment, no amount of detection later in the chain fully compensates for the exposure. Preventive design should therefore be assessed at the path level: can an untrusted source reach a sensitive controller, and can it do so without first crossing a meaningful control boundary?
What Detection Adds When Prevention Is Not Enough
Detection exists because OT defenses are never perfect and because some activities are hard to block without breaking operations. It gives operators visibility into unusual protocol use, unexpected asset behavior, lateral movement, repeated authentication failures, or changes in command patterns that may indicate misuse, misconfiguration, or compromise.
Detection should be tuned to answer operational questions, not just security questions. A useful alert supports triage by telling the team what changed, where it happened, and whether the event is isolated, recurring, or part of a broader pattern. That is why OT detection should be paired with asset inventory and baseline understanding, which is why safe visibility and monitoring are foundational to any OT asset visibility guide.
Detection also benefits from a clear understanding of defensive intent. Public guidance for OT environments from NIST SP 800-82 Rev 3, OT Security Guide emphasizes that segmentation, monitoring, and control selection need to reflect the realities of industrial environments, not just enterprise IT patterns. In parallel, CISA Industrial Control Systems resources are a practical reference point when teams need to align monitoring with current advisories and sector-specific concerns.
How to Judge the Boundary Between the Two Layers
The cleanest rule is simple: if the control is supposed to stop an action before it reaches a critical asset, it belongs in prevention; if the control is supposed to reveal, confirm, or prioritize an action that may already be in motion, it belongs in detection. The two layers should not be merged conceptually, even if the same platform provides both functions.
That separation helps avoid a common mistake in OT purchasing and design. Teams sometimes buy a platform that claims “prevention” but can only alert, or they deploy a blocking rule and assume any missed event will still be visible. A stronger design treats prevention as a hardening and boundary function, then uses detection to verify whether the boundary is actually working and whether an operator needs to intervene.
Well-built programs also use detection to validate prevention. If the block list or segmentation rule is effective, you should be able to observe attempted violations without disruption, see whether they are benign or malicious, and use that evidence to refine the preventive rule set. A good detection layer therefore tells you not only that something happened, but whether your prevention design is narrowly and safely enforced.
Risk and Threat Considerations
When organisations collapse OT detection and prevention into one undifferentiated layer, they risk both missed compromise and unsafe overblocking. Attackers benefit from that confusion because a weak boundary gives them room to move, while an overzealous boundary can tempt operators to disable or bypass controls that interfere with production.
Failure mechanism: A control that only observes cannot stop unsafe activity, while a control that only blocks cannot show whether an attacker, misconfiguration, or vendor session is already operating inside the environment. In OT, either failure mode can persist quietly because the environment is often optimized to keep running.
Impact: The result can be delayed response, broader process exposure, or operational disruption from poorly tuned blocking rules. That is why OT teams should treat prevention and detection as complementary layers, not interchangeable features.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | OT segmentation and traffic boundaries are central to separating prevention from detection. |
| SI-4 — System Monitoring | Detection in OT depends on monitoring events, anomalies, and protocol activity for triage. | |
| AU-6 — Audit Review, Analysis, and Reporting | OT detection must support review and prioritisation of alerts into actionable investigations. | |
| Recommendation — Enforce network boundaries that limit OT traffic to approved paths and protocols. Monitor OT assets and traffic for anomalies that indicate misuse or compromise. Review and analyse OT security events to distinguish benign activity from threats. | ||
| NIST CSF 2.0 | PR.AA-05 — Asset Management and Access Control | OT prevention depends on controlled access paths and known asset exposure. |
| DE.CM-01 — Security Continuous Monitoring | OT detection requires continuous monitoring of assets, networks, and processes. | |
| Recommendation — Limit OT access paths to approved users, devices, and control points. Continuously monitor OT environments for abnormal activity and control failures. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | OT prevention relies on managed segmentation and controlled network paths. |
| CIS-8 — Audit Log Management | OT detection depends on usable logs and reviewable evidence for investigation. | |
| Recommendation — Segment OT networks and restrict communications to required flows only. Collect and retain OT logs so suspicious events can be investigated quickly. | ||
Practitioner Guidance
What to prioritise: Define which OT controls are meant to block, which are meant to observe, and which are expected to do both. If a preventive control would be unsafe to make stricter, compensate with sharper detection and faster triage rather than weakening the architecture by assumption.
What to verify: Confirm that each preventive rule has a clear business and process owner, and that each detection signal has an explicit response path. The most common gap is not the sensor or the firewall, but the absence of a decision rule for what happens when the control fires.
Practitioner takeaway: OT security is strongest when prevention limits the blast radius and detection proves whether those limits are holding under real operating conditions.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on detection instead of prevention for east west traffic control?
- When should organisations rely on prevention, detection, and verification together rather than any single control for secrets management?
- Should organisations treat browser-based OT access as a security control?
- When should organisations treat OT asset inventory as a control requirement?