IEC 60870-5-104 is a telecontrol protocol used to send supervisory control and status data over IP networks between control centres and field systems. It is common in power and utility environments. Security teams should restrict who can reach it, monitor command and status traffic, and ensure exposed gateways do not allow unauthorised control actions.
How IEC 60870-5-104 Carries Telecontrol Over IP
IEC 60870-5-104 is designed to move supervisory control between a control centre and remote field systems using standard IP transport. In practice, that means telemetry, status changes, and control commands are packaged for network delivery rather than carried on a dedicated serial link. The protocol is often used where operators need reliable remote visibility and command capability across utility networks.
The key operational idea is separation of roles: one side supervises and issues commands, while the other side reports process state and executes approved actions. Because the protocol can cross routed IP networks, the security model is not “safe by default.” It depends on the surrounding network architecture, gateway placement, and strict control of who can initiate or receive sessions.
In OT environments, IEC 60870-5-104 is often one of several industrial protocols that must coexist with segmentation, industrial DMZ design, and disciplined remote access. A useful reference point is the OT Security Guide, because the protocol’s security posture is usually determined more by network zoning and exposure control than by the protocol alone.
What Actually Happens on the Wire
IEC 60870-5-104 uses IP networking to exchange application data between endpoints that already understand the protocol. At a high level, one endpoint can send measured values, alarms, and status updates, while the other can issue commands or setpoints. That makes it suitable for utility operations where latency, interoperability, and operational continuity matter.
The protocol’s usefulness comes from its ability to preserve SCADA-style control semantics while running over mainstream network infrastructure. The trade-off is that the same routability that makes it easy to integrate also makes it easier to expose unintentionally. If the protocol is reachable from untrusted segments, an attacker may be able to observe traffic, replay patterns, or attempt command injection through misconfigured gateways or weak access paths.
For that reason, teams should treat protocol reachability as part of the control plane, not just a connectivity detail. If a field gateway, jump host, or relay node can forward traffic without strong restriction, the protocol can become an operational control path rather than a narrow telemetry channel.
Why Exposure Control Matters More Than the Protocol Name
IEC 60870-5-104 is commonly deployed in environments where availability is critical and change tolerance is low. That makes segmentation, monitoring, and command-path restriction essential. The protocol itself does not remove the need to verify who can talk to it, where the sessions terminate, or whether a gateway is translating or forwarding traffic in a way that widens the blast radius.
Security teams should focus on the reachable surface: remote access routes, engineering workstations, protocol bridges, and any assets that can originate control messages. A control network that looks isolated on paper can still be exposed through flat routing, vendor access paths, or improperly scoped firewall rules.
Because the protocol carries operational commands, monitoring should distinguish routine status traffic from actions that change process state. That means alerting on new peers, unexpected command direction, unusual timing, and traffic that crosses trust boundaries without an established operational reason.
Risk and Threat Considerations
When IEC 60870-5-104 is exposed outside its intended OT boundary, the main risk is unauthorised control or manipulation of process state. The protocol is attractive to attackers because it can provide direct operational impact, especially where remote access, weak segmentation, or permissive gateways collapse the trust boundary around control traffic.
Failure mechanism: A reachable endpoint, bridge, or gateway accepts or forwards commands from an untrusted network, allowing an attacker to inject, alter, or replay supervisory actions.
Impact: Operators can lose confidence in telemetry and command integrity, and in a utility setting that can translate into unsafe process changes, service disruption, or failed response during an incident.
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, CIS Controls v8 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 security depends on restricting command and status flows across trust boundaries. |
| SC-7 — Boundary Protection | The protocol's exposure risk is driven by gateway placement and network boundary design. | |
| Recommendation — Enforce approved information flows between control centres, gateways, and field systems. Place IEC 60870-5-104 traffic behind controlled boundaries and tightly scoped network paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Monitoring command and status traffic is central to spotting abnormal or unauthorised protocol use. |
| Recommendation — Monitor protocol traffic and alert on new peers, unusual commands, and boundary-crossing sessions. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Restricting who can reach the protocol is an access-control problem at the operational boundary. |
| DE.CM-01 — Anomalies and Events | Unexpected command or status patterns are the key detection signal for misuse of the protocol. | |
| Recommendation — Limit protocol access to authorised operators, systems, and management paths only. Baseline normal IEC 60870-5-104 traffic and investigate deviations from expected command patterns. | ||
Practitioner Guidance
What to verify: Confirm which assets can originate or terminate IEC 60870-5-104 sessions, then validate that every path is intentionally scoped to an operational use case. If you cannot name the business owner for a route, firewall rule, or gateway function, treat that path as suspect until proven otherwise.
What to prioritise: Focus first on exposed gateways, inter-zone rules, and any remote access mechanism that can reach the protocol from outside the OT trust zone. In many environments, reducing reachable endpoints does more to improve security than tuning the protocol stack itself.
Practitioner takeaway: Treat IEC 60870-5-104 as a control-path protocol whose security depends on containment, observability, and tightly governed reachability, not on protocol mechanics alone.