Should OT teams prioritise prevention over detection?

Why prevention and detection need to be paired in OT

OT teams should not treat prevention and detection as competing priorities. In operational environments, the real question is whether the prevention layer can stop a known bad path fast enough to matter, while detection still provides visibility into what got through, what is changing, and what response is required next. If either side is weak, control becomes brittle.

Prevention matters most where an action could directly interrupt a process, alter a setpoint, or create unsafe downtime. Detection matters most where the environment is too complex, too legacy-bound, or too time-sensitive to assume every hostile action can be blocked ahead of time. In practice, mature OT security uses both, but the balance shifts toward controls that are safe to enforce at the speed the plant operates.

That is why “prevention first” only works when the rule set is operationally enforceable. A policy that is correct on paper but cannot be applied without production risk is not really prevention, it is a future incident waiting for a human to notice it.

What prevention means when production continuity is non-negotiable

In OT, prevention is not just blocking traffic or denying access. It includes segmentation, hardened remote access, allowlisting, safe configuration, strong authentication where feasible, and asset visibility that lets teams know what they are protecting. The point is not to eliminate every possibility of misuse, but to narrow the set of actions that can reach critical equipment.

For OT teams, the most valuable preventive controls are the ones that reduce blast radius without forcing constant manual intervention. OT Asset Visibility Guide is relevant here because reliable prevention depends on knowing which assets, protocols and critical paths exist before you try to protect them. Without that inventory, teams usually overblock benign traffic or underprotect the systems that matter most.

Prevention also has to account for how OT change control works. If a safeguard needs a long approval chain for every exception, operators may bypass it. If it is too coarse, it may break process communication. The better preventive control is the one that is specific enough to stop the exploit path and narrow enough to preserve the process.

Why detection still matters after prevention is tuned

Detection remains essential because OT environments are rarely static. Legacy devices, vendor remote support, mixed trust zones, and long-lived configurations create conditions where some exposure will remain. Detection is what tells teams whether the environment is drifting, whether a preventive assumption has failed, and whether an event is merely anomalous or part of an active compromise.

Good detection in OT is not just alert volume. It is the ability to distinguish expected engineering activity from suspicious access, protocol abuse, or unexpected changes in device behavior. CISA Industrial Control Systems is a useful reference because it ties OT monitoring to the realities of critical infrastructure operations, where visibility and incident handling need to be aligned with safety and reliability.

Detection also gives prevention its feedback loop. If alerts keep showing the same blocked or failed attempt, that is evidence the preventive control is working. If alerts show the same action succeeding through another path, then the preventive assumption was incomplete. In OT, detection is often the only way to validate whether a control is truly effective under live conditions.

Risk and Threat Considerations

OT risk rises when detection is treated as a substitute for prevention, or when prevention is deployed without a response path that can act quickly enough. In that situation, teams may believe they have control while an attacker, unsafe workflow, or misconfiguration is still able to move toward the process layer.

Failure mechanism: A weak preventive layer lets hostile or accidental actions reach critical assets, while slow or passive detection only notices the problem after the operational impact has already started.

Impact: The result can be unsafe process behavior, avoidable downtime, delayed containment, and a false confidence gap where security sees telemetry but the plant still remains exposed.

Practitioner Guidance

What to prioritise: Prioritise controls that can stop the most dangerous known paths without requiring a human to intervene every time. In OT, the best preventive control is the one that is both technically effective and safe to enforce during real operations.

What to verify: Verify that every preventive rule has an operational owner, a tested exception path, and a measurable effect on blast radius. If a control cannot be validated against real process traffic or realistic change scenarios, it is not ready to be trusted.

Decision rule: If a control can prevent a known exploit path with acceptable production impact, enforce it. If it cannot, keep detection strong enough to surface the path quickly and build a safer preventive option rather than relying on alerting alone.

Practitioner takeaway: OT security is not a choice between stopping attacks and seeing them, it is a decision about whether your preventive controls can act fast enough to matter while detection confirms that the environment is still behaving as expected.

Related resources from NHI Mgmt Group

• When should OT teams prioritise segmentation over more detection tooling?
• When should teams prioritise prevention over better detection in Kubernetes?
• Should financial services teams prioritise attack-path prevention over faster detection?
• When should teams prioritise contextual classification over simple field detection?