By RUGERO Tesla (@404Saint).
IEC 60870-5-104 (IEC 104) is the TCP/IP-based member of the IEC 60870-5 telecontrol family. It was designed to carry SCADA telemetry and control information across packet-switched networks, particularly within electrical power systems.
Before getting into raw packets, it is worth understanding how IEC 104 is structured, how its communication state is maintained, and where its security boundaries actually exist.
This is the map before we meet the protocol on the wire.
Protocol Stack
IEC 104 operates over TCP, commonly using port 2404.
Two protocol components are particularly important:
- APCI : Application Protocol Control Information
- ASDU : Application Service Data Unit
The APCI handles framing, sequencing, acknowledgments, and connection control.
The ASDU carries the actual telecontrol information.
+-------------------------------------------------------------+
| ASDU |
| Type ID | VSQ | COT | CA | IOA | Information Objects |
+-------------------------------------------------------------+
| APCI |
| 0x68 | Length | Control 1 | Control 2 | Control 3 | Ctrl 4 |
+-------------------------------------------------------------+
| TCP / IP |
+-------------------------------------------------------------+
Every APDU begins with the 0x68 start byte, followed by a length field and four control bytes. The length represents the bytes following the length field, including the four control bytes and, when present, the ASDU. That fixed structure is the starting point for understanding IEC 104 traffic.
I, S, and U Formats
IEC 104 defines three APDU formats.
I-Format:
→ I-format frames carry application information and therefore contain an ASDU.
They also carry two sequence numbers:
-
N(S): send sequence number -
N(R): receive sequence number
These allow communicating stations to maintain ordered transmission and acknowledgment state.
S-Format:
→ S-format frames are supervisory frames.
They do not carry an ASDU. Their purpose is to communicate receive acknowledgments independently of application data.
U-Format:
→ U-format frames handle connection-control functions.
Three important functions are:
STARTDT Start data transfer
STOPDT Stop data transfer
TESTFR Test the communication relationship
This creates an important distinction: A TCP connection is not the same thing as an active IEC 104 data-transfer session.
The TCP connection establishes transport connectivity. IEC 104 then manages its own application-level communication state.
Inside the ASDU
When an I-format frame carries application data, the ASDU defines what that data means.
A simplified ASDU looks like this:
+-------------------------------+
| Type Identification |
+-------------------------------+
| Variable Structure Qualifier |
+-------------------------------+
| Cause of Transmission |
+-------------------------------+
| Common Address |
+-------------------------------+
| Information Object |
| IOA + Information Elements |
+-------------------------------+
✔ Type Identification
The Type ID determines the information type being transmitted.
Examples include:
M_SP_NA_1 Single-point information
C_SC_NA_1 Single command
✔ Variable Structure Qualifier
The VSQ indicates how many information objects are present and whether their addressing follows a sequential structure.
✔ Cause of Transmission
The COT provides context for why the ASDU is being transmitted.
Depending on the message, it can indicate events such as spontaneous transmission, interrogation responses, activation, activation confirmation, or termination.
✔ Common Address and IOA
The Common Address (CA) identifies the logical station or ASDU address.
The Information Object Address (IOA) identifies the individual information object within that address space.
Common Address
|
+---- IOA 1
+---- IOA 2
+---- IOA 3
+---- IOA 4
Together, these fields provide the addressing model through which IEC 104 identifies telemetry and control points.
Where the Security Boundary Actually Sits
The base IEC 104 protocol does not itself provide the cryptographic security properties associated with modern secure application protocols.
That includes mechanisms such as:
- cryptographic peer authentication
- confidentiality
- cryptographic integrity protection
Historically, this placed significant responsibility on the surrounding network architecture.
Network Security Boundary
+---------------------------------------+
| |
| IEC 104 Environment |
| |
| Master <==== TCP/2404 ====> RTU |
| |
+---------------------------------------+
^
|
Firewall / ACL /
Segmentation
But there is an important qualification here.
IEC 104 is not limited to its unsecured base protocol.
The IEC 62351 family defines security mechanisms for power-system communication. IEC 62351-3:2023 specifies TLS-based profiles for TCP/IP protocols, including confidentiality, integrity protection, and message-level authentication.
For protocols based on IEC 60870-5, IEC 62351-5:2023 defines an application-profile security mechanism for securing their operation.
The IEC 60870 family then defines the protocol-specific integration in IEC TS 60870-5-7:2025, which explicitly covers security extensions for IEC 60870-5-101 and IEC 60870-5-104. It describes the message formats and adaptations required to apply IEC 62351 and allows a receiver to verify that an APDU originated from an authorized user and was not modified in transit.
So the correct security question is:
What security profile does the deployed implementation support, and is it actually enabled and correctly configured?
Where the Attack Surface Begins
The protocol architecture raises several questions worth investigating.
☐ Session State
STARTDT and STOPDT control the IEC 104 data-transfer state. That makes session-state handling an obvious area for testing. How does an implementation react to unexpected state-control messages? Does it ignore them, reject them, or terminate the connection?
☐ Sequence State
I-format communication depends on synchronized N(S) and N(R) values. That raises questions around duplicate, stale, replayed, or otherwise unexpected sequence information. Again, the interesting part is the implementation's response.
☐ Application Commands
The ASDU structure provides another research surface. If an unauthorized system can reach an IEC 104 endpoint, can it construct a syntactically valid command? Can valid Common Addresses and IOAs be identified? And what controls exist between receiving a command and actually executing it? These are implementation questions.
The protocol specification tells us where to look but the lab tells us what actually happens.
Security Characteristics
| Characteristic | Security Relevance |
|---|---|
| TCP/2404 | Network reachability exposes the protocol endpoint |
| Stateful I/S/U communication | Session behavior becomes an attack surface |
| Sequence numbers | Unexpected sequence state warrants investigation |
| Structured ASDUs | Application messages follow defined semantics |
| CA / IOA addressing | Target identification becomes important |
| Base IEC 104 | No native cryptographic security in the core protocol |
| IEC 62351 extensions | Security mechanisms can be applied to IEC 104 deployments |
The last two rows are deliberately separated. A security assessment of IEC 104 should distinguish between the base protocol and the security mechanisms implemented around it.
From Architecture to Packets
The basic model is now clear:
TCP
|
+-- APCI
| |
| +-- I-Format
| +-- S-Format
| +-- U-Format
|
+-- ASDU
|
+-- Type ID
+-- VSQ
+-- COT
+-- Common Address
+-- IOA
+-- Information
That gives us the vocabulary needed for the next phase. The specification tells us what the fields and state machines are supposed to mean. The next step is to find out what they actually look like on the wire.
Next: IEC 104 packet-level analysis: raw frame construction, state transitions, PCAP dissection, and implementation behavior.
Top comments (2)
I like the “before the wire” framing. Protocol security discussions often jump straight into packets, but architecture and trust boundaries decide what a packet is allowed to mean. If that model is vague, every downstream detection rule ends up carrying too much interpretation.
Thank you, Alex! That’s exactly what I was going for. I’ve noticed that jumping straight into packet dissection without establishing the baseline can make the findings harder to follow. At the same time, putting the architecture primer and wire-level discoveries into one post tends to make the whole thing unnecessarily long. I’m glad the “before the wire” approach resonated with you. It gives each part of the research room to breathe without losing the connection between them.