IEC 104 Before the Wire: Understanding Its Architecture, Framing, and Security Boundaries

IEC 60870-5-104, usually called IEC 104, is a communications protocol for supervisory control and data acquisition, or SCADA. It adapts the IEC 60870-5 telecontrol family to TCP/IP networks. Its main job is to move information between control centers and remote equipment. That makes it important wherever operators must observe and control electrical infrastructure over distance.

For example, a substation can report a breaker’s status or a measured voltage to a control center. The center can then send a command to change equipment state. IEC 104 supplies the application-level structure for these exchanges, while TCP/IP transports the data across the network.

The article presents IEC 104 as a map for understanding SCADA traffic before inspecting raw packets. It also highlights communication state and security boundaries. IEC 104 remains useful because it fits modern routed networks, but its safety depends on the surrounding network and system protections.

IEC 104 carries two broad information classes: telemetry from field equipment and commands from control centers. Telemetry commonly includes measured values, equipment status, counters, and event notifications. Commands commonly request switching operations, regulate setpoints, or acknowledge and control remote devices. The article states this overall purpose, while these examples reflect standard IEC 104 use in power automation.

A substation might send a breaker’s open or closed state, a transformer’s voltage, and an energy counter. An operator could send a command to open that breaker or change a permitted setpoint. The protocol packages such information in application service data units, or ASDUs, with information types, addresses, values, and causes of transmission.

This separation helps control centers distinguish observation from action. It also supports event-driven reporting, not only repeated polling. Because IEC 104 rides over packet-switched networks, accurate addressing, timing, sequence handling, and system safeguards remain essential for dependable operation.

IEC 104 uses TCP/IP as its network foundation instead of requiring a dedicated telecontrol circuit. A control center and a field device, such as a remote terminal unit or substation gateway, establish a TCP connection. IEC 104 then places telecontrol messages inside application protocol data units carried by that connection.

For example, a control center may connect to a substation over an operational Ethernet or routed utility network. The substation sends a measured value, and the center returns a control command. TCP handles transport tasks such as ordered, reliable delivery. IEC 104 handles application framing, message types, sequence numbers, and power-system information.

This design lets existing packet-switched infrastructure carry operational traffic across local or wide-area networks. However, TCP does not understand whether a command is safe, correct, or authorized. Therefore, routing, firewalls, segmentation, monitoring, and endpoint controls must protect the path around IEC 104.

IEC 104 uses three main frame types. I-frames carry application information, such as measurements, status changes, and commands. S-frames acknowledge received I-frames using receive sequence numbers. U-frames manage the link itself, including starting, stopping, and testing communication. This division keeps data transfer and connection control distinct.

Suppose a field station reports a new breaker status. It sends that application data in an I-frame. The receiving system can later acknowledge received I-frames with an S-frame. If the connection must begin, end, or be checked, the peers exchange U-frames such as STARTDT, STOPDT, or TESTFR messages. Sequence values help detect missing or out-of-order information.

The three types are a compact map of IEC 104 behavior on the wire. I-frames carry meaning, S-frames confirm progress, and U-frames control availability. Understanding them makes packet analysis easier and helps operators diagnose stalled links, missing acknowledgments, or failed startup.

IEC 104 maintains state rather than treating every message as an isolated packet. After the TCP connection exists, the peers use U-frames to start data transfer with STARTDT, stop it with STOPDT, and test link availability with TESTFR. Each request has a corresponding confirmation, so both sides can agree on the connection’s operating state.

During normal transfer, I-frames contain application data and sequence numbers. The receiver acknowledges progress through S-frames or acknowledgments carried with later I-frames. Send and receive counters let each peer track what arrived and identify gaps. Timers also detect silence or delayed responses, allowing a system to close or recover a stale association.

These mechanisms matter because a live TCP socket does not prove that both control systems are ready for operations. IEC 104’s state model distinguishes connected, data-transfer-ready, stopped, and tested conditions. The article emphasizes understanding this state before examining raw packets, especially when diagnosing real SCADA links.

An IEC 104 application protocol data unit, or APDU, can be up to 253 octets, including its protocol control information. The fixed APCI portion uses six octets, leaving up to 249 octets for the ASDU payload. This bounded size makes message parsing and device buffering predictable. It also prevents one application unit from growing without limit.

A small status update may fit comfortably in one APDU. A group of measurements or events must fit within the remaining ASDU space, or the application must send multiple frames. Each additional frame adds headers, sequence handling, and processing. Larger frames can improve efficiency for grouped data, while smaller ones may reduce waiting time for urgent events.

The limit matters especially on shared or bandwidth-constrained operational networks. It influences latency, memory planning, traffic bursts, and monitoring tools that reconstruct messages. TCP may segment data during transport, but IEC 104’s APDU boundary still defines the application message that receiving equipment must parse.

IEC 104 was designed primarily for reliable SCADA communication, not modern security. By itself, it generally provides no encryption, strong peer authentication, or message-level authorization. A device that can reach an exposed IEC 104 service may be able to observe traffic or attempt commands. The article’s warning about security boundaries is therefore central.

Networks and systems around the protocol must supply layered defenses. Utilities can use firewalls, network segmentation, allowlists, VPNs or protected gateways, monitoring, patching, and strict account controls. IEC 62351 security measures and secure architectures can add authentication, integrity, and confidentiality where supported. Endpoint devices should also validate commands and limit their effects.

The current reality is that IEC 104 often operates across modern IP infrastructure while retaining legacy assumptions. Security teams should protect the route, endpoints, and operational process rather than expecting the protocol alone to do so. Forward-looking deployments should combine protocol-aware monitoring with authenticated, encrypted channels and carefully tested access controls.