IEC 62351 Security for IEC 61850 and 60870

Back to Blog

Securing Protocols That Assumed Trust

The telecontrol and substation protocols were built when the network was a private, physically protected circuit, so they carried no authentication or encryption - a device on the wire was trusted by definition. As those networks became IP-connected and, in some cases, reachable from wider infrastructure, that assumption stopped holding. IEC 62351 is the multi-part standard written to close the gap without discarding the installed base: it layers security onto the existing protocols rather than replacing them.

Different parts of IEC 62351 address different profiles. For TCP-based traffic such as IEC 60870-5-104 and MMS, it specifies transport-layer security to authenticate endpoints and encrypt the session. For the connectionless Layer 2 services - GOOSE and Sampled Values - where full encryption would break the timing, it defines authentication and integrity mechanisms so a subscriber can verify a message is genuine and unaltered. It also covers key management, role-based access control, and security event logging, so the security is operable and not just cryptographic.

Where It Fits in an OT Security Program

IEC 62351 is protocol-level security, and it works alongside - not instead of - network segmentation and monitoring. Keeping GOOSE and Sampled Values on an isolated segment with VLAN and priority tagging remains good practice; IEC 62351 authentication adds defense in depth on top of that isolation, which connects to broader SCADA subnetting and segmentation design.

Adoption is uneven and requires care: enabling authentication or TLS on a live telecontrol link touches every endpoint and can affect timing and interoperability, so it is a planned engineering change, not a switch. The details of what a given device supports come from its documentation, and the change is validated the way any protocol change is - by confirming the link still carries data correctly afterward. IEC 62351 spans both IEC 61850 and IEC 60870-5-104, which is why it is the common security reference across the family.

The Parts of the Standard at a Glance

IEC 62351 is a family, and most projects only need a few of its members.

Part	What it covers
3	Transport-layer security (TLS) for the TCP-based profiles
4	Security for MMS-based communication
5	Security for IEC 60870-5 and derivatives, including serial links
6	Authentication for GOOSE and Sampled Values
8	Role-based access control
9	Key management for the cryptography the other parts rely on

Read the table as a menu keyed to your protocol mix. A telecontrol shop running 60870-5-104 mostly cares about parts 3, 5, 8, and 9; a substation automation project on 61850 adds parts 4 and 6. Part 9 is the one nobody plans for and everybody needs, because every other part assumes keys and certificates exist and are managed - which is an operational program, not a protocol setting.

Certificates and Keys Are the Real Project

Enabling the cryptography is a configuration change; operating it is a program. Every endpoint needs an identity - certificates and keys issued, stored securely on the device, renewed before expiry, and revocable when a device is compromised or retired. The failure mode that catches teams is mundane: a certificate expires silently and a healthy link simply stops authenticating. Certificates therefore belong in the asset inventory with their expiry dates, with alerting far enough ahead that renewal is routine maintenance instead of an outage response.

Clocks quietly become security-critical, because certificate validity checking depends on the device knowing the correct time - a failed time sync can turn into an authentication failure that looks like a network problem. And the fleet constrains the design: devices that cannot store credentials securely or run the required cryptography limit where protocol security can reach, which is why some programs terminate security at a gateway in front of legacy equipment as a documented interim rather than pretending the old RTU can do TLS.

A Phased Rollout That Keeps Telecontrol Up

Security on a live telecontrol link is change-managed engineering work for qualified personnel, and a sequence like this keeps it boring in the good sense.

1. Inventory every endpoint: firmware, and what each supports per the manufacturer's documentation.
2. Stand up key management before touching any link - certificates must exist before anything can use them.
3. Prove each device pairing in a lab or test bench with security enabled.
4. Enable on one non-critical link, inside a maintenance window, with a tested fallback configuration ready.
5. Soak through a full operational cycle, including failover and restart behavior, before declaring success.
6. Phase across the remaining links, documenting the security settings beside the protocol settings for each.

The fallback plan deserves emphasis because authentication fails closed: a misconfiguration does not degrade the link, it stops it. That is the correct security behavior and the exact reason the rollout is phased - you want to discover any surprise on one planned link, not on all of them at once.

Operating and Monitoring Once Security Is On

Enabling IEC 62351 creates a new observable class of failure: TLS negotiation failures, authentication rejections, and certificate errors. Each is simultaneously an operational fault and a potential security event, so route them both ways - into operations alerting, because the link is down, and into security logging, because repeated authentication failures on a telecontrol link are exactly what an intrusion attempt looks like. The standard's event-logging work anticipates precisely this dual use.

Protocol security is one layer, not the program. Segmentation, gateway hardening, and monitoring still carry their share, and where telecontrol traffic terminates in a cloud-connected gateway the same layered thinking applies end to end - the adjacent layers are covered in the cloud SCADA security checklist and in hardening a cellular SCADA gateway. The goal is that no single control, cryptographic or otherwise, stands between an attacker and the process.

Frequently Asked Questions