IEC 62351

protocol-iec-62351.png

The map answers the through-line that ran under every diagram before this one. IEC 62351-3 is the TLS profile, the transport floor beneath any TCP/IP protocol, so it sits under IEC 104, ICCP and MMS rather than beside them. IEC 62351-4 secures MMS at the application layer, which is the stack that TASE.2 and IEC 61850 client and server communication ride on. IEC 62351-5 is the application-layer Secure Authentication for IEC 60870-5 and DNP3, and it is worth noting it authenticates without necessarily encrypting: it proves a command is genuine and unaltered rather than hiding it. IEC 62351-6 covers the IEC 61850 peer profiles, GOOSE and Sampled Values, the case where TLS cannot help because the traffic is Layer 2 multicast under a hard latency budget, so the protection is a signature or MAC carried inside the frame. The two boxes underneath, role-based access control and key and certificate management, are cross-cutting: 62351-9 supplies the keys and certificates the other parts consume, and 62351-8 governs who is permitted to do what. The honest qualifier is that 62351 is large, conformance varies by part and by vendor, and field deployment tends to lag the standard, most visibly for GOOSE protection.

Of those parts, IEC 62351-5 is the one with a message exchange of its own, so it can be drawn like the rest.

protocol-iec-62351-b.png

IEC 62351-5 is what turns the DNP3 select-and-operate exchange, drawn earlier as a safety interlock with no security, into something an attacker cannot simply replay. The lower half is the core idea. When the master sends a critical message, a control rather than a routine poll, the outstation does not act on it. It returns a challenge carrying random data, and the master has to answer with a MAC computed over that challenge together with the message, using the current session key. Only a holder of the key can produce a MAC that verifies, so a forged or replayed command fails at that step. The upper half exists because the session keys are not static: they are refreshed through a key status and key change exchange, with the new keys wrapped under a longer-lived Update Key so the refresh itself is protected. Aggressive mode is the latency escape hatch, folding the authentication into the request so a time-critical control does not pay for the extra round trip. The property to keep in view is that this is authentication and integrity, not confidentiality. It proves a command is genuine and unmodified; concealing it would mean adding the 62351-3 TLS layer underneath.

Fifteen parts

IEC 62351 is the security standard series published by IEC Technical Committee 57, the same body responsible for IEC 61850, IEC 60870-5, and the TASE.2 specification. Where those standards define what protocol implementations do, IEC 62351 defines how to secure them. The series spans fifteen parts, each addressing a different protocol, layer, or operational concern. Not all parts are equally deployed, and the gap between what the series defines and what runs in substations and control centres is the gap that characterises OT security more broadly.

The series was initiated in the early 2000s and has expanded as the scope of the problem became clearer. Parts 3 and 4 address TLS wrapping for TCP-based protocols. Part 5 defines challenge-response authentication for the IEC 60870-5 family, which is also the basis of DNP3 Secure Authentication v5. Part 6 defines MAC-based authentication for GOOSE and Sampled Values. Part 8 defines role-based access control for MMS. Part 9 defines key management. Part 14 addresses PKI and certificates for power system equipment.

TLS profiles: Parts 3 and 4

Part 3 defines TLS profiles for protocols that run over TCP: IEC 60870-5-104 and TASE.2/ICCP. It specifies permitted cipher suites, certificate requirements, and the handshake profile. The intent is that a Part 3 implementation provides a consistent TLS configuration across utility deployments rather than leaving cipher suite selection to each vendor.

Part 4 addresses MMS specifically. MMS runs over the ISO/OSI upper-layer stack (TPKT, COTP, ISO Session and Presentation, ACSE) rather than directly over TCP, so a dedicated profile is needed to describe how TLS wraps that stack. The result is TLS at the transport layer with the ISO stack above it, providing the same confidentiality and authentication properties as Part 3.

Parts 3 and 4 are the most widely deployed parts of the series. The toolchain for TLS is mature, certificate infrastructure exists in most utility IT environments, and the performance overhead is acceptable for MMS and TASE.2 traffic. The deployment gap is smaller here than elsewhere in the series, though many substations commissioned before vendor support was available remain unprotected.

Verifying whether a Part 3 endpoint is actually using TLS, and which cipher suites it accepts, is a two-command check:

# Check TLS on an IEC 104 endpoint (port 2404) or TASE.2 endpoint (port 102)
openssl s_client -connect 10.0.0.1:2404 2>/dev/null | grep -E "Protocol|Cipher"

# Enumerate cipher suites: flag any outside the Part 3 permitted set
nmap --script ssl-enum-ciphers -p 2404 10.0.0.1

Message-level authentication: Parts 5 and 6

Part 5 defines authentication for the IEC 60870-5 family, covering both the serial (101) and TCP (104) variants. The mechanism is challenge-response: before executing a designated critical message (typically a command), the receiving device issues a challenge containing a random nonce. The sender responds with an HMAC computed over the challenge and the message content using a shared session key. A message without a valid HMAC response is rejected.

The key structure uses two tiers. An Update Key is provisioned on both parties during commissioning. Session keys are derived from the Update Key periodically; the Update Key itself is used to authenticate the session key update exchanges. An attacker without the current Update Key cannot substitute a new session key. DNP3 Secure Authentication v5, published as IEEE 1815 Annex A, implements the same design and references Part 5 directly.

Part 6 applies authentication to GOOSE and Sampled Values. Both protocols run directly over Ethernet with no IP header, at timescales where challenge-response would add unacceptable latency. Part 6 takes a different approach: a Message Authentication Code is appended to each frame, computed over the frame content using a shared symmetric key. A subscribing IED that receives a frame with an absent or invalid MAC rejects it. There is no encryption; the frame content remains visible to any observer on the segment. The intent is integrity and source authentication, not confidentiality. Adding encryption would add latency incompatible with protection functions that operate in tens of milliseconds.

The shared key in Part 6 is per GOOSE Control Block. A substation with multiple IEDs each publishing several GOOSE Control Blocks may have dozens of keys to distribute and maintain. Deployment is growing, particularly on new substation projects where IED firmware support is available at the time of commissioning. Retrofit to existing substations requires firmware updates that may take the IED out of service during installation.

Role-based access control: Part 8

Part 8 defines an RBAC model for MMS. It specifies a set of standard roles (Viewer, Operator, Engineer, Installer, SecurityAdministrator, and others) and maps each role to a set of permitted MMS operations. A Viewer can read data objects but cannot write setpoints or issue control commands. An Operator can issue control commands within the select-before-operate sequence. An Engineer can modify configuration. The IED or MMS server enforces the role assignments when a client connects.

Part 8 is rarely deployed. It requires the IED firmware to implement the RBAC enforcement logic, an authentication mechanism to identify the connecting client and determine its role, and an administrative process to assign and maintain role memberships. Most IED firmware that supports Part 8 at all does so optionally, and many sites leave it unconfigured. Where it is deployed, it limits what a client that has reached the station bus can do based on its identity, which is a meaningful control given that the alternative is full MMS access for any authenticated connection.

Key management: Part 9

Part 9 is where the series encounters its hardest operational problem. Parts 5 and 6 both depend on shared symmetric keys. Those keys need to be distributed to every device that participates in the authenticated exchange, rotated periodically, and replaced if compromised. Part 9 defines the architecture for doing this at scale.

The model centres on a Key Distribution Centre (KDC): a trusted server that holds Update Keys for all registered devices and issues session keys on request. Devices authenticate to the KDC using their Update Keys and receive session keys for the specific exchanges they participate in. Key rotation happens through the KDC without requiring manual intervention at each device.

The operational challenge is significant. Update Keys are provisioned during device commissioning and represent the root of trust for the key hierarchy. Compromising an Update Key compromises everything derived from it. Replacing an Update Key requires authenticated access to the device, which typically means a maintenance window. IEDs in service may have had the same Update Key since commissioning, with rotation deferred indefinitely because the outage cost of taking the IED out of service exceeds the perceived benefit.

A substation that has deployed Part 6 GOOSE authentication but has never rotated its keys since commissioning has weaker protection than the specification intends. The static key is the actual threat model: an attacker who obtains it once can forge authenticated GOOSE frames indefinitely. Part 9 addresses this problem by design; the gap is in whether its key rotation procedures are actually followed.

PKI for OT: Part 14

Part 14 defines certificate profiles for power system equipment, building on X.509 with OT-specific extensions. Standard X.509 profiles were designed for IT systems with network connectivity, automated renewal toolchains, and certificate validity periods of one to two years. OT devices have different characteristics: limited connectivity during operation, no automated renewal capability, and operational lifetimes of ten to twenty years or more.

Part 14 addresses this by defining extended validity periods for device certificates, offline issuance procedures for devices that cannot connect to a CA during operation, and certificate content extensions that identify the device’s role and the protocols it participates in. It also defines a trust hierarchy for utility PKI, including the concept of a utility root CA that issues certificates for substation devices independently of commercial PKI infrastructure.

Deployment of Part 14-compliant PKI is limited to a small number of utilities that have invested in OT-specific certificate infrastructure. Most sites that use certificates for OPC UA or TLS-wrapped TASE.2 rely on self-signed certificates or commercial CAs with standard IT certificate profiles, accepting the operational risk of expiry outages and the security limitation of weaker identity assurance.

The deployment picture

The pattern across the series is consistent. The parts that map onto familiar IT security mechanisms (TLS in Parts 3 and 4) see the highest deployment. The parts that require OT-specific mechanisms (MAC authentication in Part 6, RBAC in Part 8, key management in Part 9) see less deployment, constrained by firmware support timelines, commissioning complexity, and the operational cost of retrofit.

The result is that IEC 62351 is present in the specification documents of most new substation and control centre projects and absent from a large fraction of equipment currently in service. The series defines what secured power system communication looks like. The distance between that definition and the current installed base is the gap that compensating network controls are filling in the interim.

  • IEC 60870-5-104: Parts 3 and 5 cover this protocol; Part 3 for TLS, Part 5 for challenge-response authentication of control commands

  • DNP3: DNP3 Secure Authentication v5 implements the Part 5 design directly and references Part 5 in the IEEE 1815 specification

  • IEC 61850: Parts 4, 6, and 8 cover MMS, GOOSE, and Sampled Values respectively; Part 6 GOOSE authentication is the most operationally significant gap in current deployments

  • ICCP / TASE.2: Parts 3 and 4 provide TLS for the TCP transport and the ISO upper-layer MMS stack

  • IEC TC 57: the IEC Technical Committee that publishes the 62351 series alongside IEC 61850, IEC 60870-5, and the TASE.2 specification