Key takeaways
- Yes, split across two parts of the IEC 62351 security series — the same series that secures IEC 61850 and other TC 57 protocols.
- Yes — this is one of the better-documented cases of a specific OT protocol being the actual attack mechanism, not just a theoretical risk.
- Segment IEC-104 traffic away from business networks and the internet.
IEC 60870-5-104 moves telecontrol traffic — the commands and status data between a control center and substation equipment — in cleartext over TCP/IP with no authentication built into the base protocol, a gap academic research has documented for over a decade. It is also, confirmed directly by ESET's and Mandiant's independent malware analyses, the only protocol Industroyer2 spoke to attack a Ukrainian energy provider's substation equipment in 2022, and Hitachi Energy RTU500 advisories through 2026 show implementation bugs in IEC-104 stacks are still being found and patched today.
What is IEC 60870-5-104, and where does it run?
IEC 60870-5-104 is an IEC Technical Committee 57 standard, formally titled "Telecontrol equipment and systems – Part 5-104: Transmission protocols – Network access for IEC 60870-5-101 using standard transport profiles." It takes the older serial protocol IEC 60870-5-101 and carries it over TCP/IP instead, registered with IANA on TCP/UDP port 2404 as "IEC 60870-5-104 process control over IP." Industry practice widely treats it as the international and European counterpart to DNP3 — the protocol that fills the same role (control-center-to-substation telecontrol and monitoring) in North America. Where DNP3 findings dominate CISA's advisories for U.S. utilities, IEC-104 findings dominate the equivalent advisories for internationally deployed grid gear, most consistently in recent years against Hitachi Energy's RTU500 remote terminal unit line.
Does IEC-104 have any built-in security?
No. A 2014 IEEE PES paper studying intrusion detection for the protocol states directly: "the IEC 60870-5-104 protocol transmits messages in clear text without any authentication mechanism." Later survey research attributes the protocol's core vulnerability class to exactly this gap, citing documented man-in-the-middle demonstrations enabled by "the lack of data integrity and authentication measures." NIST SP 800-82 Revision 3's general description of OT protocols captures the same pattern without naming IEC-104 specifically: "Many OT protocols have no authentication at any level. Without authentication, there is the potential to replay, modify, or spoof data or devices." In practice, on its standard port 2404, IEC-104 traffic is plain unencrypted TCP — readable and, absent any compensating control, injectable by anything with access to the same network segment.
Is there a secure version, and what does it protect?
Yes, split across two parts of the IEC 62351 security series — the same series that secures IEC 61850 and other TC 57 protocols.
| Standard | What it adds | Layer |
|---|---|---|
| IEC 62351-3 (Ed. 2.0, 2023) | TLS 1.2/1.3 profile for TCP/IP-based protocols, including IEC-104 | Transport (confidentiality + integrity), typically a separate TLS port from the standard 2404 |
| IEC 62351-5 (Ed. 1.0, 2023, promoted from a prior Technical Specification) | Application-layer authentication for IEC 60870-5 protocols: a challenge-response HMAC over critical ASDUs, in a two-pass challenge/reply mode or a faster one-pass "aggressive mode" | Application (command/message authenticity) |
Vendor documentation shows these combined in deployed products — Siemens' published Grid Security Profile is one documented example, layering TLS transport security under 62351-5 application authentication for its IEC-104-speaking SICAM and SIPROTEC products. But independent academic security evaluations have also found a real limitation in 62351-5's own design: its replay-protection window (commonly implemented around 10 minutes) can allow an attacker to modify non-timestamp fields of a captured, still-valid (timestamp, HMAC) message pair without invalidating the authentication check, or replay the pair outright within that window. Whether a specific RTU or control-center product has either standard enabled — and configured without that weakness being exploitable — has to be confirmed against that product's documentation, not assumed from the base standard's existence.
Has IEC-104 actually been used in a real attack?
Yes — this is one of the better-documented cases of a specific OT protocol being the actual attack mechanism, not just a theoretical risk. ESET's 2022 analysis of Industroyer2, the malware deployed against a Ukrainian energy provider, is explicit: "Industroyer2 only implements the IEC-104 (aka IEC 60870-5-104) protocol to communicate with industrial equipment. This includes protection relays, used in electrical substations." Mandiant's independent analysis of the same malware (which it tracks as INDUSTROYER.V2) describes the mechanism: the malware "crafts configurable IEC-104 Application Service Data Unit (ASDU) messages... to change the state of a remote station's Information Object Addresses (IOAs) to ON or OFF" — sending protocol-legitimate commands to toggle breaker states, something IEC-104's lack of authentication does nothing to block once an attacker has network access. Netresec's packet-level analysis of captured Industroyer2 traffic confirms the specific ASDU type IDs used (46 for double command, 45 for single command) against targeted breaker addresses, with the capture files published for independent verification. The original 2016 Industroyer malware against the Ukrainian grid is widely reported, via ESET and Dragos research, to have carried a similar IEC-104 module among several protocol-specific payload modules; this guide could not independently re-verify that primary document's text in this research pass, so treat it as well-corroborated secondary reporting pending a direct re-check.
What has CISA found in IEC-104 products recently?
Every CISA ICS advisory naming IEC-104 from 2023 through 2026 that this guide could verify affects Hitachi Energy's RTU500 product line (with one additional advisory against the open-source MZ Automation lib60870 stack), and every one is a denial-of-service class finding — none grant remote code execution or authentication bypass:
| Advisory | Finding |
|---|---|
| ICSA-26-211-11 (MZ Automation lib60870) | Out-of-bounds read parsing a crafted I-frame |
| ICSA-26-155-04 (Hitachi Energy RTU500) | "IEC 60870-5-104 used in bidirectional mode is vulnerable for a NULL pointer dereferencing" |
| ICSA-26-062-03 (Hitachi Energy RTU500) | Denial of service on an invalid U-format frame in 104 bidirectional mode |
| ICSA-25-093-01 (Hitachi Energy RTU500) | Remote restart of the control-module unit via a specific attack sequence |
| ICSA-25-128-02 (Hitachi Energy RTU500) | Link-layer blocking from a malformed APDU length field |
| ICSA-24-354-01 (Hitachi Energy RTU500) | Buffer overflow in SCI/HCI IEC-104 components, forcing a reboot |
| ICSA-23-220-02 (Hitachi Energy RTU500) | Stack-based buffer overflow in the 62351-5 "advanced security" feature itself, remotely exploitable at low complexity |
That last entry is worth noting on its own: a buffer overflow inside the very feature meant to add IEC-104 authentication is a reminder that enabling 62351-5 adds its own implementation attack surface — it does not make the deployment immune to vulnerabilities, only changes what kind of flaw to look for.
What should an asset owner running IEC-104 equipment check first?
Inventory every RTU, protection relay and control-center gateway speaking IEC-104, with exact firmware versions — every advisory above affects specific version ranges, and the DoS findings against Hitachi Energy RTU500 recur across years, meaning an unpatched unit stays exposed across multiple disclosure cycles. Confirm whether IEC 62351-3 (TLS) and 62351-5 (authentication) are actually configured, not just supported in the product's documentation — and if 62351-5 is enabled, confirm the firmware version is current, since the authentication feature itself has had a critical remotely exploitable vulnerability (ICSA-23-220-02). Segment IEC-104 traffic away from business networks and the internetThe protocol was designed for a trusted telecontrol network, not public exposure, and its cleartext default means anything that can reach the segment can read or inject traffic. Treat Industroyer2 as a concrete worked example, not a hypothetical, when prioritizing segmentation and monitoring: a real-world attacker used nothing more exotic than legitimately-formatted IEC-104 ASDU commands to open breakers, which is exactly what network segmentation and anomaly detection on unexpected command sequences are meant to catch. Re-check configuration after every firmware update, since a patch addressing one CVE is not a substitute for confirming TLS and authentication settings, and network segmentation, are still intact afterward.
A passive capture from an IEC-104 network segment's mirror port is a practical way to build the inventory in step 1 and confirm whether traffic is encrypted, authenticated, or running cleartext on port 2404, without connecting anything to a live protection circuit: SoftWSP's OT Snapshot identifies devices and the protocols they speak from that capture, maps them against published CISA ICS advisories, and flags patterns such as unauthenticated IEC-104 traffic reaching an unexpected segment — with an engineer reviewing every finding and the AI-assisted report citing the specific traffic each finding is based on — see OT Snapshot.
This guide draws on IEC's own webstore catalogue and scope text for IEC 60870-5-104, IEC 62351-3 and IEC 62351-5, a peer-reviewed IEEE PES paper fetched directly, NIST SP 800-82 Revision 3, seven CISA ICS advisories (six against Hitachi Energy RTU500, one against MZ Automation lib60870), and independent malware analyses from ESET, Mandiant and Netresec confirming Industroyer2's use of IEC-104. The full paywalled text of IEC's own 60870-5-104 and 62351-3/-5 standards was not purchased or independently re-verified for this guide; treat granular protocol-mechanism claims as general description, to be confirmed against the primary IEC text before a compliance or implementation decision. This guide is general information, not a substitute for a current CISA ICS advisory search for your exact hardware and firmware version.
Sources
- IEC: IEC 60870-5-104:2006 (Ed. 2.1 consolidated with AMD1:2016) — Telecontrol equipment and systems, Part 5-104
- IANA Service Name and Transport Protocol Port Number Registry — "iec-104", TCP/UDP port 2404
- Yang, Y. et al., "Stateful Intrusion Detection for IEC 60870-5-104 SCADA Security," IEEE PES General Meeting 2014
- NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security (September 2023)
- IEC: IEC 62351-3:2023, Part 3 — Communication network and system security – Profiles including TCP/IP
- IEC: IEC 62351-5:2023, Part 5 — Security for IEC 60870-5 and derivatives
- ESET: "Industroyer2: Industroyer reloaded" (12 April 2022)
- Mandiant / Google Cloud: "INDUSTROYER.V2: Old Malware New Tricks" (2022)
- CISA ICS Advisory ICSA-26-155-04: Hitachi Energy RTU500 (IEC 60870-5-104 bidirectional mode NULL pointer dereference)
Frequently asked questions
What is IEC 60870-5-104, and where is it used?
IEC 60870-5-104 — officially "Telecontrol equipment and systems – Part 5-104: Transmission protocols – Network access for IEC 60870-5-101 using standard transport profiles" — is an IEC Technical Committee 57 standard that extends the earlier serial protocol IEC 60870-5-101 over TCP/IP, registered by IANA on TCP/UDP port 2404 as "IEC 60870-5-104 process control over IP." It is widely described in industry practice as the European, international and Chinese counterpart to DNP3, which dominates North American grid telecontrol instead; both protocols serve the same role, moving monitoring and control data between a control center and substations, remote terminal units (RTUs) and protection relays across a geographically spread-out power or water system. Where DNP3 shows up constantly in CISA ICS advisories for North American utilities, IEC-104 shows up the same way for European and internationally deployed grid equipment — most visibly, in recent years, in Hitachi Energy's RTU500 product line.
Does IEC 60870-5-104 have any built-in authentication or encryption?
No. Academic security research is explicit on this point: a 2014 IEEE PES paper on stateful intrusion detection for the protocol states plainly that "the IEC 60870-5-104 protocol transmits messages in clear text without any authentication mechanism," and independent survey literature since then attributes the protocol's main vulnerabilities to "the lack of data integrity, availability and authentication mechanisms in the protocol's specification" — citing documented man-in-the-middle research as a direct consequence. NIST SP 800-82 Revision 3 does not name IEC 60870-5-104 specifically in the sections this guide could verify, but its general description of OT protocols applies directly: "Many OT protocols have no authentication at any level. Without authentication, there is the potential to replay, modify, or spoof data or devices." On the wire, IEC-104 running on its standard port 2404 is unencrypted TCP traffic that any device on the same network segment can read or, in the absence of transport security, inject into.
Is there a secure version of IEC 60870-5-104, and what does it actually protect?
Yes, as two separate add-on standards from the same IEC 62351 series that secures other TC 57 protocols. IEC 62351-3 ("Communication network and system security – Profiles including TCP/IP," current Edition 2.0 published 2023-06-06) defines a TLS 1.2/1.3 profile that wraps IEC-104's TCP/IP traffic in transport-layer encryption and integrity protection, typically run on a separate port (commonly cited as 19998) from the standard unencrypted port 2404. IEC 62351-5 ("Security for IEC 60870-5 and derivatives," promoted from a Technical Specification to a full International Standard, Edition 1.0, published 2023-01-13) adds application-layer authentication specific to IEC 60870-5 protocols: a challenge-response HMAC mechanism applied to critical Application Service Data Units (ASDUs), available in a stricter two-pass challenge/reply mode or a faster one-pass "aggressive mode." Vendor documentation (Siemens' published Grid Security Profile is one example) shows real products combining both — TLS for transport confidentiality plus 62351-5 authentication for command integrity — but independent academic security evaluations have also documented a real weakness in 62351-5's replay-protection window (commonly implemented around 10 minutes), which can allow modification of non-timestamp fields in a captured, still-valid (timestamp, HMAC) pair without invalidating the authentication check. Whether a given RTU or control-center product has either standard enabled, and configured correctly, has to be verified against that specific product, not assumed from the standard's existence.
Has IEC-104 actually been used in a real grid attack?
Yes, documented directly by multiple independent security research teams analyzing the same malware. ESET's 2022 analysis of Industroyer2, the malware used against a Ukrainian energy provider, states plainly: "Industroyer2 only implements the IEC-104 (aka IEC 60870-5-104) protocol to communicate with industrial equipment. This includes protection relays, used in electrical substations." Mandiant's independent analysis of the same malware (tracked as INDUSTROYER.V2) confirms the mechanism in more technical detail: the malware "crafts configurable IEC-104 Application Service Data Unit (ASDU) messages... to change the state of a remote station's Information Object Addresses (IOAs) to ON or OFF" — in effect, sending legitimate-looking IEC-104 commands to open or close circuit breakers, something the protocol's lack of authentication does nothing to stop if an attacker can reach the network segment. Netresec's packet-level analysis of captured Industroyer2 traffic identifies the exact ASDU type IDs used (46 for double command, 45 for single command) against specific breaker information object addresses. The original 2016 Industroyer malware against the Ukrainian grid is independently reported (via ESET and Dragos research) to have included a similar IEC-104 payload module among several protocol-specific modules — this guide could not independently re-verify that primary document's text in this pass, so it is cited as well-corroborated secondary reporting rather than a directly re-checked primary quote.
In this cluster
