How can security teams detect blocking of operational technology messages?

What blocking looks like in OT traffic

Blocking in an operational technology environment is usually visible as more than a simple outage. It may show up as a missing poll response, a command that never reaches a controller, a repeated reset of a session, or a protocol exchange that stops midstream while adjacent traffic continues normally. The key is to look for selective failure, not just total loss of connectivity.

That matters because OT communications often carry both control and visibility. If only one protocol, device pair, or command type disappears, the process can still look partly healthy while alarms, setpoint changes, or telemetry are silently degraded.

When the traffic pattern itself is the signal, baseline comparison is essential. A strong baseline includes which controllers talk to which sensors, how often messages should occur, which sessions are persistent, and what normal retransmission or timeout behaviour looks like for each protocol.

How to monitor for selective message loss

Use network and protocol telemetry to watch for dropped, delayed, or reset traffic between controllers, sensors, and supervisory systems. Compare current message flow with historical baselines, then flag sudden loss of a specific session or command channel rather than broad packet loss alone. OT Security Guide is useful for placing that traffic monitoring in the context of ICS and SCADA architectures, segmentation, and industrial protocols. NIST SP 800-82 Rev 3 — OT Security Guide supports the same approach with OT baselines, architectures, and threat-aware monitoring.

Protocol-aware monitoring is better than generic up-or-down checks because blocking may be partial. A controller may still be reachable at the network layer while specific function codes, object groups, or supervisory commands are denied, delayed, or dropped. That is why packet captures, flow records, historian gaps, and alarm path monitoring all matter together.

Where possible, validate message delivery from both ends of the path. If a PLC believes it sent a response but the SCADA server never receives it, or if a supervisory command is accepted by the network but not acted on by the device, you have a stronger indication of selective blocking than a single sensor alert could provide.

Why blocked OT messages matter operationally

Blocked OT messages can hide process state, suppress alarms, and delay operator action. Even brief disruption can have outsized impact because OT control loops and alarm handling depend on predictable timing and continuity. A communication failure that looks minor in IT terms may materially change the safety or stability of the controlled process.

Selective blocking is especially important because it can affect only the most operationally sensitive exchanges. That includes write commands, alarm acknowledgements, setpoint updates, and status telemetry. If defenders only monitor for full outages, they can miss the more dangerous case where the process still runs but the human or supervisory view is incomplete.

Risk and Threat Considerations

Selective blocking is risky because it can create denial of control, denial of view, or delayed alarm delivery without breaking the entire network. In OT, that can let a fault, misuse, or malicious interference persist long enough to affect availability, safety, or recovery.

Failure mechanism: An attacker, misconfiguration, or failing intermediary drops or resets only the messages that matter most, while leaving enough connectivity intact to delay detection.

Impact: Operators may lose visibility into process state, miss alarms, or assume commands were delivered when they were not, increasing the chance of unsafe or incorrect response.

Practitioner Guidance

What to verify: Confirm which OT protocols, ports, sessions, and command paths are business-critical, then test whether your monitoring can distinguish total loss from selective blocking of individual exchanges. Baselines should include expected timing, retries, and session persistence for each control path.

Decision rule: If only one device pair, protocol function, or alarm channel is affected, treat it as a higher-priority incident than a broad connectivity issue because selective interference is harder to see and more operationally dangerous.

What practitioners underestimate: Temporary blocking can be enough to break trust in telemetry and operator response even when the underlying network appears healthy. The most useful alerts are the ones that prove a specific command or alarm path stopped behaving as expected, not just that traffic volume changed.

Practitioner takeaway: The best detection is protocol- and process-aware, because in OT the most important failure is often not total outage but quiet loss of the exact message flow that keeps control and alarms trustworthy.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?