Organisations implement IEC 60870-5-104 by securing the TCP-based control channel, limiting who can initiate sessions, and placing strict network controls around remote terminal and control centre links. They should monitor command issuance, session behaviour, and unexpected connectivity, then test failover and recovery. The protocol should be wrapped in a wider access and segmentation design, not exposed directly.
Securing the IEC 60870-5-104 Control Path
IEC 60870-5-104 is an industrial telecontrol protocol that rides over TCP, so implementation starts with treating the protocol session as a high-trust control path, not just another network flow. The practical goal is to constrain who can open sessions, where commands can originate, and which links are allowed to carry telemetry and control traffic.
That usually means placing the protocol inside a segmented OT network design, enforcing allowlisted communications between control centres and remote terminal equipment, and preventing direct exposure to wider IT or internet paths. The OT Security Guide is useful here because it frames IEC 60870-5-104 as part of a broader zoning and conduit model rather than a standalone protocol problem.
Implementation also depends on strong session governance. Only explicitly authorised masters should initiate conversations, command paths should be tightly scoped, and logging should distinguish normal polling from operational commands so that unusual activity is visible quickly.
Monitoring, Failover, and Recovery Expectations
A correct deployment does not stop at access control. Organisations need monitoring that can tell the difference between expected protocol chatter, a newly opened session, and a command pattern that does not fit the operating baseline. That makes command issuance, session persistence, and unexpected connectivity the main operational signals to watch.
Recovery planning matters because this protocol often sits on systems that cannot tolerate ad hoc recovery behaviour. Test failover paths, confirm that backup communications still preserve the same trust boundaries, and verify that degraded operation does not silently widen access or bypass controls during an outage.
Where the protocol is part of a larger SCADA or remote operations environment, recovery should be checked at the network layer and the control layer together. A link that comes back cleanly but restores overbroad trust or stale control permissions has not really recovered safely.
Deployment Choices That Make the Difference
The most reliable implementations keep IEC 60870-5-104 inside a deliberate access model: narrow ingress, explicit peers, protocol-aware monitoring, and no assumption that the TCP layer is trustworthy by itself. Security teams should also verify that remote maintenance paths, engineering workstations, and backhaul links are not quietly bypassing the controls placed around the main control channel.
Operationally, the biggest mistake is treating protocol enablement as a connectivity task rather than a governance task. If the architecture allows any host that can reach the port to behave like a legitimate control peer, the protocol is deployed, but not securely implemented.
Practitioner Guidance:
What to verify: Confirm that every permitted IEC 60870-5-104 peer is explicitly documented, that session initiation is constrained to the intended control direction, and that no fallback link creates a wider trust boundary than the primary one.
What to prioritise: Prioritise segmentation and command visibility before tuning performance. In OT environments, a fast but weakly governed control path is usually worse than a slightly slower one with clear boundaries and alerting.
Decision rule: If the protocol must traverse shared infrastructure or mixed-trust networks, wrap it in segmentation and monitoring first; if that cannot be done, treat the deployment as materially higher risk until the architecture changes.
Practitioner takeaway: Secure IEC 60870-5-104 by controlling the path as tightly as the command, because the protocol’s safety depends less on the port being open and more on who can speak, from where, and under what monitored conditions.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | IEC 60870-5-104 needs network restrictions and segmented control paths. |
| IA-2 — Identification and Authentication (Organizational Users) | Only authorised operators should initiate or manage control sessions. | |
| AU-12 — Audit Record Generation | Command issuance and unusual connectivity need traceable logs. | |
| Recommendation — Enforce approved information flows for control traffic and block unintended session paths. Require authenticated operator access before allowing control-session initiation. Generate audit records for control commands, session changes, and anomalous connections. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The protocol must be protected by network segmentation and controlled links. |
| A.8.22 — Segregation of networks | IEC 60870-5-104 implementations depend on strict OT zoning and conduits. | |
| Recommendation — Apply network security controls to separate control traffic from broader networks. Segregate control-centre and field networks to limit protocol reachability. | ||