Most OT teams don’t have a detection problem at the perimeter.

They have a confidence problem inside the layers where operations actually change state.

Purdue Levels 1–2 are where the most process-critical signals live:

• Controller logic changes
• Engineering workstation activity
• HMI and supervisory actions
• Field device interactions
• Setpoint adjustments
• Mode changes
• Process variable anomalies

Yet many OT security programs still measure maturity by how much traffic they can see north of the cell/area zone.

That visibility matters, but it does not answer the harder questions:

Did the PLC logic change?
Was that change authorized?
Did an engineering workstation push a new configuration?
Did a field device behave outside expected process boundaries?
Did the operator action match the operational context?

If you cannot validate what is happening at Levels 1–2, you may detect intrusion activity while missing the operational consequence.

That is the blind spot.

The goal is not to flood operations with more alerts. The goal is to build confidence in the signals that matter most to safety, uptime, and process integrity.

For OT CISOs, the detection strategy needs to move closer to the control layer without disrupting it.

That means:

• Understanding normal controller and engineering workflows
• Monitoring changes to logic, configurations, and setpoints
• Correlating cyber events with process behavior
• Separating legitimate operational activity from risky activity
• Designing detection with operations, not around operations

In OT, the question is not only “Did someone get in?”

It is “Did anything change in the process, and can we prove why?”