IEC 62351 Power System Communications Security Guide: Parts, Profiles and Rollout for Utilities

The protocols that run the power grid, IEC 61850, IEC 60870-5-104 and DNP3, were designed to be fast and interoperable, not to authenticate who is sending a trip command. IEC 62351 is the IEC TC 57 series that adds that security: TLS profiles, message authentication for multicast protection traffic, role-based access control, key management and security monitoring objects. Utilities write specific parts into procurement, and "62351 support" means very different things between vendors. This guide explains what each part actually requires, how the parts depend on each other, how to roll them out without disturbing protection and control, and what evidence to collect. It is for utility OT security engineers, protection and control engineers, and procurement teams writing substation and control centre specifications.

Key takeaways

• IEC 62351 is a family, not a single standard. The 2026 series pack lists 20 documents: International Standards, Technical Specifications and Technical Reports, each with its own edition and date. Always specify part and edition.
• Parts 3, 5, 6 and 8 are the ones you buy against. Part 3 profiles TLS 1.2 and 1.3 for TCP/IP protocols, Part 5 secures IEC 60870-5 and derivatives, Part 6 secures IEC 61850, and Part 8 defines role-based access control.
• Part 9 key management is the hidden dependency. Certificates, private keys and GDOI group keys for GOOSE and Sampled Values must be issued, renewed and revoked, or the other parts fail closed or are switched off.
• Most of IEC 62351 is identity for machines. IEDs, RTUs, gateways and control centre applications authenticate with certificates and carry roles, so the series is a non-human identity programme as much as a protocol upgrade.
• Security events are part of the standard. Parts 3, 5, 8 and 9 define security events, and Part 7 defines monitoring objects with an SNMP mapping. Plan to collect them before you enable the controls that raise them.

What it is and who it applies to

IEC 62351, titled "Power systems management and associated information exchange: Data and communications security", is maintained by IEC Technical Committee 57, the same committee that owns IEC 61850, IEC 60870-5 and IEC 60870-6 (TASE.2/ICCP). It adds authentication, integrity and, where timing allows, confidentiality to the TC 57 protocols. The IEC webstore's series pack, IEC 62351:2026 SER, was published on 30 July 2026 and bundles every current part.

The standard is voluntary until a specification, grid code or contract calls it up. Several parts state that their measures only take effect when the protocol specifications accept and reference them: a 62351 part on its own does not change an IED's behaviour until the protocol profile and the product implement it.

It applies to transmission and distribution utilities (substation automation, telecontrol, inter-control-centre links), generation and DER operators, and the IED, RTU, gateway and SCADA vendors and integrators who supply them.

For the wider grid context see the Smart Grid Security Guide.

Structure and key requirements

The table lists the parts in the 2026 series pack with the editions shown on the IEC webstore when checked on 27 October 2026. Editions change: confirm the current one before you put a part in a specification.

How the parts fit together

• Transport and application security: Part 3 TLS protects TCP/IP links hop by hop; Parts 4 and 5 add application-layer protection that survives gateways and protocol converters that terminate TLS.
• Multicast protection traffic: GOOSE and SV are layer 2 multicast with no session, so TLS cannot apply. Part 6 adds message authentication codes keyed with group keys that Part 9 distributes over GDOI. Encryption is not normally used on these messages because protection timing budgets are measured in milliseconds.
• Authorisation and keys: Part 8 says what an authenticated subject may do; Part 9 says how the certificates and keys behind every other part are managed.

Protocol to part reference

The substation-specific design choices for GOOSE, SV and MMS are covered in the IEC 61850 Substation Communications Security Guide.

Identity and NHI requirements

Nearly every authenticated party in an IEC 62351 deployment is a machine: a protection relay, an RTU, a merging unit, a gateway, a SCADA front end or a control centre application. Part 8 makes this explicit: its subjects are human users, automated systems and software applications, covering both local access (built-in HMIs, panels, automated agents) and remote access by control centre applications. That makes 62351 a machine identity programme with four parts to own.

• Shared device passwords: Part 8 explicitly leaves usernames and passwords out of scope. Until RBAC is deployed, many IEDs still have one local password per access level. Store them per device in a vault, rotate after staff and contractor changes, and record who retrieved them. See the OT and ICS Identity and Access Guide.
• Service identities on servers: SCADA front ends, historians and gateway software hold their own certificates and often an LDAP bind account for Part 8 role retrieval. Inventory these with owners and expiry dates like any other service account. See the Service Account Security Guide.
• Certificate expiry is an availability risk: an expired certificate on a telecontrol link stops telemetry. Expiry monitoring and renewal automation are operational requirements, not nice-to-haves. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Post-quantum planning: Part 9 expects post-quantum cryptography to be considered in future but gives no measures yet. See the Post-Quantum Migration for NHIs Guide.

Implementation steps

Treat 62351 as a multi-year programme tied to asset replacement: every new bay and telecontrol link is 62351-capable at commissioning, and legacy assets are compensated by segmentation and monitoring.

1. Inventory protocols and capability: for each link record protocol, endpoints, firmware, and which 62351 parts and editions the product actually implements (ask for the vendor's conformance statement, not a brochure). See the OT Asset Visibility Guide.
2. Write the specification: name part and edition (for example "IEC 62351-3:2023 including the TLS 1.3 profile"), required roles under 62351-8, support for CRL and OCSP, GDOI under 62351-9 for GOOSE, and export of security events. Reference conformance testing under the relevant 62351-100 part where one exists.
3. Build the OT PKI before enabling anything: a dedicated issuing CA for the OT environment, enrolment and renewal procedures, a revocation service reachable from substations, and an inventory of every issued certificate with its expiry.
4. Collect security events first: route Part 7 objects (via SNMP) and syslog security events to the SOC or OT monitoring platform, and confirm you can see a failed TLS handshake before you rely on it. See the OT Network Security Monitoring Guide.
5. Enable TLS on control centre links: start with IEC 104 or DNP3 links between control centre and a pilot substation. Run in parallel with the unprotected link where the SCADA allows a redundant channel, compare data quality, then cut over.
6. Add application-layer security: Part 5 on IEC 104 and DNP3 Secure Authentication where gateways or converters terminate TLS, so the end-to-end path is still authenticated.
7. Introduce RBAC: map engineers, operators, auditors and automated agents to Part 8 roles, start with read-only and viewer roles, then restrict control and configuration rights.
8. Pilot GOOSE and SV authentication on a new bay: measure latency added by MAC computation against the protection scheme's timing budget, test key rollover and loss of the key distribution centre, and get protection engineering sign-off.

Testing and rollback: run factory acceptance, site acceptance and a monitored soak period for every step. Keep the previous configuration file (CID or SCD for IEC 61850, device configuration for RTUs) under change control so a link can be reverted within the outage window. Never enable revocation checking in fail-closed mode until the revocation service has proven availability.

Decision guidance:

• TLS only vs TLS plus application security: TLS alone is enough on a direct link between two endpoints you control. Add Part 5 or Part 4 where data passes through protocol converters, front-end processors or third-party networks.
• TLS 1.2 vs 1.3: Part 3 profiles both. Specify 1.3 for new procurement where products support it, keep the 1.2 mandatory suites for interoperability with installed equipment.
• Authenticate GOOSE now or segment: if the IEDs and the protection timing allow it and you can run a key distribution service reliably, authenticate. If not, isolate the process and station bus, block any routing of GOOSE out of the substation, and monitor.
• Small utility vs large TSO: a small distribution utility may run one OT CA and TLS on a handful of links; a large transmission operator needs a redundant PKI, regional GDOI services and an RBAC directory tied to identity governance.

Evidence and assessment

Build the evidence pack as you deploy, not afterwards.

Metrics that show progress:

• Protected link coverage: percentage of telecontrol and inter-control-centre links running Part 3 TLS, tracked per protocol.
• Certificate health: certificates expiring in the next 60 days with no renewal scheduled (target zero), and certificates issued outside the OT CA (target zero).
• Shared credentials remaining: count of IEDs still accessed with shared local passwords instead of named or role-based access.
• Event visibility: percentage of 62351-capable devices whose security events reach the SOC, and mean time to triage an authentication failure.

Mapping to other frameworks

ATT&CK for ICS entries are the techniques each area is designed to make harder.

• IEC 62443: 62443 sets programme, zone and conduit, and component security level requirements; 62351 supplies the concrete protocol mechanisms that let power system components meet communication integrity and authentication requirements. See the IEC 62443 Guide and the IEC 62443-3-3 and 4-2 System and Component Security Levels Guide.
• NERC CIP: in North America, 62351 mechanisms are one way to meet requirements on electronic access and on protecting real-time data between control centres (CIP-012). See the NERC CIP Guide.
• ISO/IEC 27001:2022: Annex A controls on network security (A.8.20), use of cryptography (A.8.24) and access control (A.5.15) are where a utility's ISMS records its 62351 decisions.

Common pitfalls

• Specifying "IEC 62351 compliant": the phrase means nothing without part and edition. A product supporting the 2014 TLS profile may not support the 2023 TLS 1.3 profile or the removal of challenge-response in the 2023 Part 5.
• Enabling TLS with self-signed or vendor default certificates: encryption without trust anchors gives a false sense of security; an attacker on the path can present their own self-signed certificate.
• No revocation path: substations with no route to a CRL or OCSP service either ignore revocation or fail closed and lose telemetry. Decide and test which.
• Forgetting the key distribution service: authenticated GOOSE depends on GDOI group keys. If the key server is a single point of failure, the protection scheme inherits that weakness.
• Breaking deep packet inspection: OT monitoring tools that parse IEC 104 or MMS lose visibility once TLS is on. TR 62351-90-2 discusses options; plan monitoring at the endpoints or authorised inspection points before cutover.
• Leaving engineering access unchanged: securing the protocol while the engineering laptop with the SCD file and relay setting software has a shared local admin account leaves the easier path open. See the Engineering Workstation Security Guide.

Practitioner checklist

• List every TC 57 protocol link with endpoints, firmware and the exact 62351 parts and editions each product supports.
• Rewrite procurement specifications to name part and edition, required Part 8 roles, revocation support, GDOI support and security event export.
• Stand up a dedicated OT PKI with enrolment, renewal, revocation and an expiry report before enabling TLS.
• Route Part 7 objects and 62351 security events to the SOC and test that an authentication failure is visible.
• Pilot Part 3 TLS on one control centre to substation link, with a documented rollback to the previous configuration.
• Add Part 5 or DNP3 Secure Authentication where gateways or converters terminate TLS.
• Replace shared IED passwords with Part 8 roles where supported, and vault per-device credentials where not.
• Pilot authenticated GOOSE and SV on a new bay with latency measurement and key rollover tests signed off by protection engineering.
• Record algorithms and key lengths per device to scope a future post-quantum migration.

Standards and references

• IEC: IEC 62351:2026 SER, Data and communications security, all parts
• IEC: IEC 62351-3, Profiles including TCP/IP
• IEC: IEC 62351-5, Security for IEC 60870-5 and derivatives
• IEC: IEC 62351-6, Security for IEC 61850
• IEC: IEC 62351-8, Role-based access control for power system management
• IEC: IEC 62351-9, Cyber security key management for power system equipment
• IEC: IEC 62351-7, Network and System Management data object models
• MITRE ATT&CK for ICS: Unauthorized Message: Command Message

Related NHI Mgmt Group resources: Smart Grid Security Guide · IEC 61850 Substation Communications Security Guide · DNP3 and DNP3 Secure Authentication Guide · NERC CIP Guide · Industrial Protocol Security Guide