IEC 60870-5-101 and IEC 60870-5-104
The IEC 60870 telecontrol family defines transport and information exchange for operational systems. Check the applicable edition, message objects, timing and control responsibilities.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
The normative IEC publications are licensed; exact editions, amendments, companion profiles, interoperability lists, national profiles, and device conformance records are required for implementation.
On this page
Overview#
The IEC 60870-5 family defines telecontrol communication used in electricity, utilities, infrastructure, and industrial gateways. IEC 60870-5-101 provides a companion standard for basic telecontrol tasks over serial oriented link profiles. IEC 60870-5-104 carries the relevant IEC 60870-5 application model over TCP/IP. They share many application service data unit (ASDU) concepts but don't share identical link, connection, timing, or security behaviour. IEC 101 IEC 104
These protocols can read measurements and indications, but they can also issue controls, setpoints, clock synchronisation, resets, parameter changes, and file operations. Treat every connection as an operational technology trust boundary.
Standards map#
| Publication | Role | Integration consequence |
|---|---|---|
| IEC 60870-5-1 | Transmission frame formats | Foundational framing concepts; not a complete application profile |
| IEC 60870-5-2 | Link transmission procedures | Link behaviour and control procedures |
| IEC 60870-5-3 | General structure of application data | ASDU construction model |
| IEC 60870-5-4 | Definition and coding of application information elements | Common information element encodings |
| IEC 60870-5-5 | Basic application functions | Application procedures such as time and control behaviour |
| IEC 60870-5-6 | Conformance testing guidance | Test planning; not a product interoperability guarantee |
| IEC 60870-5-101:2003 + AMD1:2015 | Companion standard for basic telecontrol tasks | Serial/link oriented profile and application subset |
| IEC 60870-5-104:2006 + AMD1:2016 | Network access for IEC 60870-5-101 using standard transport profiles | TCP/IP transport and APCI/session behaviour |
| IEC TS 60870-5-7:2025 | Security extensions for 101 and 104 applying IEC 62351 | New technical specification security layer; support must be explicit |
| IEC 62351-3:2023 | Security profiles including TCP/IP | TLS profile referenced for applicable 104 security use |
| IEC 62351-5:2023 | Security for IEC 60870-5 and derivatives | Applicable security mechanisms and lifecycle requirements |
| IEC 62351-8:2026 | Role based access control for power system management | Current RBAC basis; protocol specific role to permission mapping still applies |
| IEC 62351-9:2023 | Cybersecurity key management for power system equipment | Credential and key lifecycle beyond the message security extension itself |
IEC parts and amendments have independent publication states. Don't describe the family as one monolithic edition, and don't treat the 2025 Technical Specification as proof that an installed 101/104 product implements it. IEC 5 7 IEC 62351 5
Communication roles and profiles#
The standards use controlling and controlled station roles. Product documentation may also say master/slave, client/server, control centre/substation, or gateway/remote terminal unit. Record both the standards role and the product term so direction and authority remain unambiguous.
IEC 60870-5-101#
IEC 101 commonly uses FT1.2 framing and balanced or unbalanced link procedures over serial or serial derived communication. A concrete profile must pin:
- physical/electrical interface, modem/converter path, bitrate, character format, and line discipline;
- balanced versus unbalanced procedure and permitted initiating roles;
- link address presence and length, common ASDU address length, information object address length, and cause of transmission field size;
- frame type/subset, retry, response timeout, poll cadence, and duplicate behaviour;
- interrogation, time synchronisation, spontaneous transmission, and event buffer behaviour;
- device interoperability list and national/utility companion profile.
Changing address field lengths or balanced/unbalanced assumptions isn't a discovery technique. A plausible frame can be decoded into the wrong point map when profile settings differ.
IEC 60870-5-104#
IEC 104 uses TCP and an application protocol control information (APCI) layer. APCI frame formats include:
- I format for numbered information transfer containing ASDUs;
- S format for supervisory acknowledgment without an ASDU;
- U format for unnumbered control functions such as starting/stopping data transfer and connection testing.
Sequence counters, send/receive windows, and timers govern delivery and liveness. Record product values and recovery behaviour for connection establishment, STARTDT/STOPDT, test frames, unacknowledged I frames, reconnect, and duplicate or gap handling. TCP delivery is a byte stream guarantee to the peer stack; it doesn't establish ASDU acceptance or physical completion.
TCP port 2404 is an IANA registered convention for iec-104, not proof that a listener is IEC 104 or that it is protected. Use approved inventory and authenticated endpoint identity rather than port based trust. IANA PORTS
ASDU contract#
An ASDU combines a type identifier and structural/control fields with one or more information objects. Exact encodings and field widths depend on the selected companion profile. Preserve the protocol fields before normalisation:
| Field/concept | Meaning to retain | Common integration error |
|---|---|---|
| Type identification | Information object/command form and encoding | Mapping different types to one generic scalar |
| Variable Structure Qualifier | Object count and sequence addressing form | Miscomputing object boundaries or addresses |
| Cause of Transmission | Why the ASDU was sent and relevant qualifiers | Treating spontaneous, cyclic, interrogation, activation confirmation, and termination as equivalent |
| Common Address of ASDU | Station/logical application scope | Confusing it with link address or IP address |
| Information Object Address | Point identity within the common address scope | Persisting it without its station/profile context |
| Information elements | Value, command, quality, time, and type specific fields | Decoding bytes without the matching type and profile |
A stable point identity should include protocol profile, controlled station, common address, information object address, type, and engineering mapping. Display labels aren't protocol identity. Version and review the point list; don't learn it with broad interrogation or exploratory control on a live system.
Causes, confirmations, and command outcome#
Cause of transmission values distinguish cyclic, background, spontaneous, initialized, request/interrogation responses, activation, activation confirmation, activation termination, and other type/profile specific situations. Test, positive/negative, and originator information must be preserved where the configured field form provides them.
For a command, keep these stages separate:
request encoded
-> transport/link delivered
-> activation accepted or rejected
-> activation terminated where applicable
-> controlled process changed or failed
-> authoritative indication/measurement confirms resulting state
Select before execute and direct execute procedures have different risk and state. An activation confirmation is a protocol/application response; it isn't sufficient evidence that a breaker, gate, pump, relay, or other physical asset reached the intended condition. Correlate the command with authoritative telemetry and a bounded completion window. Never retry an indeterminate high impact command merely because the connection was lost.
Quality and value semantics#
Information types can carry quality descriptors for conditions such as invalid, not topical, substituted, blocked, overflow, or type specific state. Counter, measured value, single point, double point, step position, bitstring, and integrated total types have different encodings and quality rules.
- Preserve raw type, value, quality bits, source address, and cause alongside the normalised value.
- Represent invalid, stale, substituted, blocked, intermediate, and indeterminate states explicitly.
- Don't coerce a double point indeterminate/intermediate value to a normal boolean.
- Apply scaling and engineering units from the approved point map; protocol normalised/scaled/floating forms aren't interchangeable.
- Treat overflow and sequence/counter discontinuity as evidence quality conditions, not cosmetic flags.
Time model#
The family includes compact time forms such as CP24Time2a and the fuller CP56Time2a. Their fields, invalid/substituted/summer time indications, and applicable type/profile must be handled exactly. A compact time without full date context can't be interpreted safely without controlled external context.
Record:
- raw encoded time and time format;
- whether time is absent, device generated, gateway generated, or control centre assigned;
- clock source, UTC/local zone contract, daylight saving interpretation, and uncertainty;
- invalid/substituted flags and clock synchronisation events;
- receipt time separately from occurrence/source time;
- behaviour across reconnect, buffer replay, year/day rollover, and clock correction.
Clock synchronisation is a write with operational consequences. It can change sequence ordering, alarm correlation, and forensic evidence and should require explicit authority.
Security baseline and extensions#
The original 101/104 companion standards were designed for trusted operational networks and don't by themselves provide a complete modern identity, confidentiality, integrity, authorisation, and key management profile. VLANs, private addressing, leased lines, or a TCP connection don't add cryptographic peer identity.
IEC 62351-5:2023 and IEC TS 60870-5-7:2025 provide the current standards path for the 101/104 application security mechanisms. For 104, IEC TS 60870-5-7 also points to IEC 62351-3:2023 for the applicable TCP/IP/TLS profile, and its role model draws on IEC 62351-8, whose current edition is 2026. Credential and key management outside the extension's message formats requires a separate lifecycle profile; IEC 62351-9:2023 is relevant where its scope is selected. These parts are independently versioned and must not be collapsed into a generic “IEC 62351 enabled” claim. IEC 5 7 IEC 62351 3 IEC 62351 5 IEC 62351 8 IEC 62351 9
IEC TS 60870-5-7 is a Technical Specification, and deployed support must be verified at both endpoints or intentional security gateways. Record the exact edition, selected mechanism, algorithm/key profile, authenticated role, protected ASDU subset, anti replay state, time dependence, key update/recovery, failure behaviour, and conformance evidence. Don't describe a proprietary tunnel or generic TLS wrapper as IEC 62351 conformance unless the applicable requirements are met.
Defense in depth remains necessary:
- isolate telecontrol networks and allowlist exact controlling/controlled endpoints and direction;
- terminate remote access through managed, strongly authenticated, recorded pathways;
- deny commands, clock changes, file transfer, resets, and parameter operations unless explicitly required;
- protect engineering workstations, converters, terminal servers, gateways, point maps, configuration backups, and keys;
- alert on new peers, role reversal, repeated link/session reset, sequence anomalies, interrogation spikes, time changes, invalid quality, command attempts, and security failures;
- maintain an independent local safety and manual recovery design.
Read only gateway pattern#
For analytics or physical security correlation, prefer a purpose built read only boundary:
telecontrol zone integration zone
controlled station -> approved controlling endpoint
|
v
protocol-aware read-only gateway
- explicit point allowlist
- indication/measurement types only
- preserve cause, quality, and time
- bounded rate, queue, and reconnect
- no transparent reverse session
|
v
normalized event/state API
The gateway should terminate each side independently, reject command/control and management ASDUs, expose stale/gap state, and bind every normalised point to the versioned source mapping. A “receive only” application on a bidirectional transparent network path is weaker than an enforced protocol aware boundary.
Failure cases to design#
- serial converter or TCP connection recovers while the controlled station remains restarted or stale;
- sequence counters/window state diverge and frames are repeated or rejected;
- event buffers overflow before interrogation/recovery completes;
- a gateway reconnect triggers duplicate spontaneous events or a fleet interrogation storm;
- activation confirmation is received but activation termination or physical feedback is absent;
- quality changes to invalid/substituted/blocked while the last numeric value remains plausible;
- source clock jumps, full date context is missing, or buffered timestamps cross a clock correction;
- security peers lose key/sequence state after restore or fail over to an incompatible profile;
- redundant paths deliver the same event under different connection identity.
Design and evidence checklist#
- Exact IEC parts, editions, amendments, national/utility profile, and product interoperability list recorded
- Controlling/controlled roles, physical/link/TCP path, and every address field width explicit
- ASDU type, common address, information object address, cause, quality, time, and engineering mapping preserved
- Balanced/unbalanced or APCI sequence/window/timer behaviour documented as applicable
- Interrogation, spontaneous reporting, buffers, reconnect, duplicate, and gap recovery bounded
- Activation, confirmation, termination, and authoritative physical feedback represented separately
- Invalid, not topical, substituted, blocked, overflow, and indeterminate quality can't appear normal
- Clock source, format, zone, uncertainty, correction, and synchronisation authority defined
- IEC 62351/60870-5-7 support and failure behaviour verified from both endpoint capability records
- Segmentation, endpoint allowlists, remote access, engineering assets, keys, and monitoring included
- Read only integrations enforce type/direction policy and don't create a reverse control path
- Evidence records configuration baseline, mapping version, peer identity, sequence/gap state, and source quality/time
Sources#
- IEC 101, IEC 60870-5-101:2003 with Amendment 1:2015 consolidated version, IEC, companion standard for basic telecontrol tasks.
- IEC 104, IEC 60870-5-104:2006 with Amendment 1:2016 consolidated version, IEC, network access for IEC 60870-5-101 using standard transport profiles.
- IEC 5 7, IEC TS 60870-5-7:2025, IEC, security extensions to IEC 60870-5-101 and IEC 60870-5-104 applying IEC 62351.
- IEC 62351 3, IEC 62351-3:2023, IEC, security profiles including TCP/IP.
- IEC 62351 5, IEC 62351-5:2023, IEC, security for IEC 60870-5 and derivatives.
- IEC 62351 8, IEC 62351-8:2026, IEC, role based access control for power system management.
- IEC 62351 9, IEC 62351-9:2023, IEC, cybersecurity key management for power system equipment.
- IANA PORTS, Service Name and Transport Protocol Port Number Registry, IANA,
iec-104entry, accessed 25 August 2026.