IEC 60870-5-104 is targeted by spoofing, replay, command injection, and denial-of-service attacks against supervisory control traffic. Security teams should validate which masters and outstations are authorised, restrict network paths, and monitor for abnormal control commands or session patterns. Because the protocol is operationally sensitive, even brief disruption can affect monitoring and control.
What kinds of attacks show up against IEC 60870-5-104?
IEC 60870-5-104 is attractive because it carries supervisory control traffic over routable networks, so the common attack patterns are those that abuse trust in the control channel rather than the protocol’s business logic. Spoofing, replay, command injection, and denial-of-service are the main families to understand, and the practical question is whether an attacker can impersonate a trusted master, reuse valid traffic, or disrupt availability.
The protocol sits in an operational environment where message authenticity, timing, and command legitimacy matter as much as confidentiality. That means an attack can succeed with only partial access: a forged control message, a replayed session, or an overloaded link can all produce unsafe operator decisions or cause the control plane to become unreliable.
A useful way to think about the threat is that the protocol’s exposure is not only technical, it is operational. If control traffic can be observed, injected, or delayed, the attacker does not need to “break” the system in the usual application sense; they only need to alter what operators believe about field state or prevent timely commands from arriving.
Why these attacks are operationally dangerous
IEC 60870-5-104 is used for supervision and control, so the impact of successful abuse can spread quickly from the network layer into process behaviour. Spoofing can mislead an outstation or an operator workstation, replay can make stale data look current, command injection can change field state, and denial-of-service can remove visibility exactly when operators need it most.
Because the protocol often supports legacy or mixed-trust environments, the real issue is not only whether a message is syntactically valid. It is whether the sender is the right party, the message is fresh, the command is expected in context, and the network path is one you actually intended to expose. The attack surface grows whenever control traffic crosses general-purpose routing, shared links, or poorly segmented zones.
In practice, these attacks are most dangerous when they affect alarms, switching, breaker control, setpoint changes, or operator trust in telemetry. A short burst of disruption can force manual fallback, and even brief loss of fidelity can create cascading decision errors if the control room can no longer distinguish normal variation from tampering.
How to reduce exposure without assuming the protocol will protect itself
Defensive work should start with strict asset and path validation. Confirm which masters, outstations, engineering stations, and relay paths are authorised to speak IEC 60870-5-104, then limit those flows to the smallest feasible set of network segments and jump points. OT Security Guide is a useful reference for thinking about segmentation, industrial DMZ design, and protocol exposure in control environments.
Detection also needs to be protocol-aware. Monitor for unusual command frequency, unexpected source addresses, repeated session resets, duplicate frames, time-skewed control activity, and control messages that do not fit the normal operating pattern for the plant or substation. For deeper incident context across control environments, The State of NHI & AI Agent Breach Report 2026 is less about this protocol specifically and more about how attackers abuse trusted access paths once they are inside an operational environment.
If you cannot harden the protocol itself, compensate around it. Use segmentation, tightly scoped firewall rules, command allowlisting where feasible, and out-of-band monitoring so loss of the primary control path does not remove all visibility. For a broader view of control families that support this approach, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both map well to access restriction, detection, and resilience planning.
What practitioners should verify before they trust IEC 60870-5-104 traffic
First verify provenance, not just reachability. If a master or outstation can send traffic, that does not mean it should be trusted to issue every command it is technically capable of sending. Confirm that the expected endpoints, routing boundaries, and operational roles match the design, and test whether stale or duplicated traffic is rejected or at least flagged.
What to verify: the normal command baseline, the allowed control sources, the expected timing profile, and the fallback behaviour if traffic is delayed or lost. If operators cannot tell the difference between normal telemetry and an injected or replayed sequence, the environment is still too permissive.
Decision rule: if the traffic can alter process state, treat command authorization and path restriction as first-order controls, not optional hardening. If the traffic is only being observed for monitoring, detection quality and anomaly handling become the priority, because you need to spot tampering before it changes the process picture.
Practitioner takeaway: the protocol should be treated as operationally sensitive control traffic, so the real security objective is to confine who can speak, prove freshness and legitimacy of commands, and preserve visibility when the link is attacked.
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 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 | AC-4 — Information Flow Enforcement | IEC 60870-5-104 attacks are reduced by restricting which control flows may traverse trusted boundaries. |
| IA-2 — Identification and Authentication (Organizational Users) | Authorized masters and operators must be strongly identified before they can issue control traffic. | |
| AU-6 — Audit Review, Analysis, and Reporting | Spoofing, replay, and command injection are easier to spot when control logs and anomalies are reviewed. | |
| Recommendation — Enforce approved control-path restrictions for masters, outstations, and supervisory traffic. Require strong authentication for operators and control endpoints before permitting command traffic. Review supervisory control logs for replay, abnormal commands, and session-pattern anomalies. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Control traffic depends on validating which masters and outstations are authorized to act. |
| DE.CM-01 — Anomalies and Events are Detected | Protocol abuse is often visible as unusual command rates, resets, or message timing. | |
| Recommendation — Restrict command-capable access to approved masters and outstations only. Detect abnormal IEC 60870-5-104 command patterns and session behaviour. | ||