IEC 62351 for Power Control Systems: Guide
If a device claim says only “IEC 62351 compliant,” that is not enough. I would check the exact parts, the exact protocols, and the exact device role before I approve any purchase.
Here’s the short version:
- IEC 62351 secures power-system communications, not the whole device.
- It adds controls such as TLS, message checks, access roles, anti-replay, and certificate handling to protocols like IEC 60870-5-104, DNP3, IEC 61850, and ICCP.
-
Different parts do different jobs:
- Part 3: TLS for TCP/IP links
- Part 4: MMS security
- Part 5: IEC 60870-5 and DNP3 command checks
- Part 6: GOOSE and Sampled Values frame protection
- Part 7: security monitoring data
- Part 8: role-based access control
- Part 9: keys and certificates
- Part 10: system design guidance
- It does not cover patching, physical site protection, or full device hardening.
- For buying, I would ask for PICS/PIXIT, TLS 1.2 or TLS 1.3 support, X.509 certificate details, RBAC behavior, log export, and FAT/SAT test proof.
- Timing still matters: GOOSE often needs millisecond delivery, and some Sampled Values paths need sub-millisecond timing, so security must be tested after it is turned on.
A simple way to think about it: Part 3 and Part 5 help protect SCADA links, Part 6 helps protect fast substation traffic, Part 8 controls who can do what, and Part 9 keeps certificates from becoming a site-wide failure point.
| What I would verify | Why it matters |
|---|---|
| Exact IEC 62351 parts | “Compliant” is too broad |
| Protocol match | A device may secure MMS but not DNP3 |
| TLS version | Older versions should be off |
| Certificate handling | Expired certs can break links |
| RBAC | Login alone does not control actions |
| Logging | I need proof of access and security events |
| FAT/SAT coverage | Paper claims are not enough |
If I were sourcing relays, RTUs, gateways, or control-center gear in the U.S., this is the filter I would use: match the protocol, name the IEC 62351 part, test the security behavior, and get the proof in writing.
IEC 62351 for the cybersecurity of IEC 61850 substations and interactions with DER systems
sbb-itb-501186b
IEC 62351 Scope and the Parts That Matter for Buyers
IEC 62351 Parts: Protocols, Security Functions & Equipment at a Glance
IEC 62351 is a set of parts tied to specific protocols and device roles. In plain English: one device may need more than one part at the same time, based on the protocols it uses and the job it does in your system. That’s why buyers should match each part to the protocol and equipment role it protects.
Core parts: IEC 62351-3, -4, -5, -6, -7, -8, -9, and -10 explained
Parts 3 through 6 deal with protocol security.
Part 3 defines a TLS profile for TCP/IP-based power communications. It adds transport-layer confidentiality, integrity, and authentication.
Part 4 secures MMS-based exchanges, including IEC 61850 MMS and ICCP.
Part 5 focuses on IEC 60870-5 and DNP3. It adds challenge-response authentication for telecontrol commands.
Part 6 covers GOOSE and Sampled Values in IEC 61850 substation settings. These messages are fast multicast traffic, so TLS doesn’t fit here. Instead, Part 6 uses MAC-based frame authentication that keeps real-time performance in place.
Parts 7 and 8 shift from protocol protection into day-to-day operations.
Part 7 defines security events, alarms, and monitoring data for SIEM or NMS tools.
Part 8 defines RBAC. It shows how roles map to permissions for users and automated agents, and it includes LDAP integration.
Part 9 covers certificate and key lifecycle across Parts 3, 4, 5, and 6.
Part 10 is a security architecture technical report. It explains how the other parts work together across control centers, substations, and field sites.
What IEC 62351 does not cover
IEC 62351 secures communication protocols. It does not harden the underlying device, handle patching, or replace physical security controls.
That point matters in buying decisions. A vendor can support IEC 62351 and still leave gaps elsewhere if the device itself isn’t locked down, maintained, and managed well. IEC 62351 is one layer of a broader security program, not the whole thing.
You still need separate controls for:
- Physical and site controls
- Patch management
- Incident response
- Governance aligned with NERC CIP or NIST frameworks
IEC 62351 parts mapped to protocols and equipment types
Use this map to write precise procurement requirements. The table below links each part to the protocols it secures, its main security job, and the equipment most likely to need it. Ask for specific parts, not just “IEC 62351 compliance.”
| IEC 62351 Part | Protocols Covered | Primary Security Function | Typical Equipment |
|---|---|---|---|
| Part 3 | IEC 60870-5-104, DNP3/TCP, ICCP, IEC 61850/TCP | TLS transport security (confidentiality, integrity, authentication) | RTUs, gateways, control-center servers, ICCP links |
| Part 4 | IEC 61850 MMS, ICCP/TASE.2 | Application-layer authentication and integrity | Station servers, ICCP gateways, IEDs with MMS |
| Part 5 | IEC 60870-5 (serial/TCP), DNP3 | Challenge-response secure authentication for telecontrol commands | RTUs, outstations, SCADA masters, DNP3 gateways |
| Part 6 | IEC 61850 GOOSE, Sampled Values | MAC-based frame authentication for Layer-2 multicast | Protection relays, merging units, process bus devices |
| Part 7 | IEC 61850 over MMS, GOOSE/SV, IEC 60870-5-104, DNP3, serial telecontrol profiles | Security event monitoring and NSM data objects | SCADA/EMS systems, IEDs, gateways |
| Part 8 | MMS-based systems (IEC 61850) | Role-based access control (RBAC) for users and agents | Control-center servers, IEDs, engineering tools |
| Part 9 | Devices using TLS, secure authentication, or MAC-based message protection | Key and certificate lifecycle management | All IEC 62351-enabled devices |
| Part 10 | System-wide | Security architecture guidance and design principles | System integrators, control-center and substation designers |
Procurement specs should name the required parts, not IEC 62351 as a broad label. If a device serves more than one role, it may need to support several parts at once.
With the scope defined, the next section shows how IEC 62351 secures each supported protocol.
Supported Protocols and How IEC 62351 Secures Each One
IEC 62351 secures each protocol based on how that protocol moves data and how much delay it can tolerate. The key is simple: match the right IEC 62351 part to the link, the device role, and the operating setting. That makes it much easier to check whether a vendor claim lines up with the exact protocol and security method you need.
IEC 60870-5, DNP3, and ICCP links between field sites and control centers
IEC 60870-5-104, DNP3 over TCP/IP, and ICCP/TASE.2 run across IP-based SCADA links between RTUs, IEDs, and control centers. IEC 62351-3 applies TLS to these protocols, which adds mutual authentication, encryption, and integrity at the transport layer. IEC 62351-5 adds command authentication for IEC 60870-5 and DNP3, using MACs or digital signatures to verify source and integrity.
For ICCP links, this matters even more because control center connections often pass through shared or third-party network infrastructure. TLS helps protect high-value operational data - tie-line flows, schedules, and contingency information - from interception and tampering.
IEC 61850 MMS, GOOSE, and Sampled Values inside substations
Inside a substation, IEC 61850 splits into MMS traffic and time-critical multicast traffic, so IEC 62351 handles them in different ways.
IEC 62351-3 and -4 secure MMS with TLS and an MMS security profile for mutual authentication and integrity, with optional encryption.
GOOSE and Sampled Values work differently. They are peer-to-peer multicast protocols at the Ethernet layer, and they carry time-critical protection traffic. GOOSE messages trigger protection trips, while Sampled Values carry high-rate analog measurements. In many cases, protection functions expect GOOSE delivery within a few milliseconds, and some SV setups need sub-millisecond end-to-end timing.
Because of that timing pressure, IEC 62351-6 uses lightweight frame-level protections - HMACs/MACs and sequence counters - instead of a TLS session. In plain terms, it protects the message without adding the sort of session overhead that could slow protection traffic down.
That said, turning these features on isn't the finish line. Engineers still need to test end-to-end latency after security is enabled. They also need to use dedicated VLANs or priority tagging, such as IEEE 802.1Q/802.1p, so secured GOOSE and SV traffic can still hit millisecond-level performance targets.
Protocol-to-security mapping table
The table below gives a condensed protocol-to-security map for procurement.
| Protocol | IEC 62351 Parts | Security Mechanisms | Typical Path | Key Deployment Concerns |
|---|---|---|---|---|
| IEC 60870-5-104 | 62351-3, 62351-5 | TLS; application-layer authentication, integrity, anti-replay | Field RTUs/IEDs ↔ control center over IP WAN | PKI and certificate management; legacy RTU CPU limits; NERC CIP key management expectations |
| DNP3 over TCP/IP | 62351-3, 62351-5 | TLS; DNP3 secure authentication with MACs/signatures and sequence checks | Substations/field devices ↔ SCADA master over IP | Interoperability with vendor DNP3 SA implementations; secure key provisioning and rotation |
| ICCP/TASE.2 | 62351-3 | TLS with mutual authentication, encryption, and integrity | Control center ↔ ISO/RTO over WAN | Cross-organization PKI coordination; cipher policy alignment; certificate renewal without link disruption |
| IEC 61850 MMS | 62351-3, 62351-4 | TLS for client-server sessions; MMS security profile | IEDs ↔ bay/station controller ↔ gateway | MMS TLS interoperability; certificate store capacity in IEDs |
| IEC 61850 GOOSE | 62351-6 | HMACs/MACs and sequence counters in the frame; origin authentication | IED ↔ IED over substation LAN (multicast) | Latency validation; network QoS; IED CPU headroom |
| IEC 61850 Sampled Values | 62351-6 | HMACs/MACs and sequence counters in the frame; origin authentication | Merging units ↔ protection IEDs over process bus | Sub-millisecond timing requirements; end-to-end latency testing after security is enabled |
These protocol controls rely on message protection, access control, and key management, which the next section covers.
Message Protection, Access Control, and Key Management
How transport and message protection works in practice
Once you know which protocol parts are in scope, the next step is simple: check how security behaves on live traffic, who can send commands, and how keys stay in good standing.
Focus on four things: confidentiality, integrity, authentication, and anti-replay protection. The way those show up depends on the protocol and the IEC 62351 part in use:
- IEC 62351-3 secures TCP-based power traffic with TLS.
- IEC 62351-4 secures IEC 61850 MMS with TLS, X.509 device authentication, and digital signatures.
- IEC 62351-5 adds command authentication for IEC 60870-5 and DNP3.
- IEC 62351-6 protects GOOSE and Sampled Values with message-level authentication and sequence counters.
That sounds technical, but the buying point is pretty direct: treat these as procurement requirements, not sales talk.
Transport protection is only part of the picture. A locked door doesn't help much if too many people have the key. Access rights decide who can actually do something on secured systems.
Role-based access control and user permissions
IEC 62351-8 separates authorization from authentication: authentication confirms who you are, while authorization controls what you can do once you're in. Typical roles include operator, engineer, technician, and administrator, tied to permissions such as view, control, configuration, and admin rights.
Check that RBAC is enforced the same way across HMIs, IEDs, gateways, and management software, not just inside one tool. That part matters more than it may seem. A clean login screen in one app means little if a gateway or device handles permissions differently.
Also confirm that access attempts are logged to local or central audit trails.
Key management, certificates, and security monitoring
Access control leans on backend systems. Certificate lifecycle and clock accuracy help keep secure sessions trusted.
IEC 62351-9 covers certificate renewal, revocation, and key handling across the device fleet. It supports revocation methods such as CRLs, OCSP, and SCVP, and it covers enrollment protocols and CSR processing. Track certificate expiration across the fleet. If a certificate lapses, secure links can fail. Before you buy, ask the vendor to walk through provisioning and renewal workflows, and make sure those workflows have been tested at scale.
IEC 62351-7 gives operators visibility into device health, security status, and communication performance. Use 62351-7 monitoring to flag certificate expiry, degraded security states, and time-sync drift before they disrupt sessions or audit logs.
What to Check When Buying IEC 62351-Compatible Equipment
Questions to ask before buying
Once you've mapped your protocols, the next step is simple: check every vendor claim before you buy.
Ask each vendor exactly which parts of IEC 62351 their device supports. Then match those parts to the exact protocols in your site. A relay might support IEC 61850 MMS, but that doesn't help much if your substation also uses DNP3 over TCP/IP. In that case, get written confirmation on how that traffic is secured and which security options the device offers.
For transport security, set a hard floor. Require TLS 1.2 or newer and make sure older versions can be turned off. Reject SSLv3 and anything earlier than TLS 1.0. You should also check which certificate formats and key lengths the device accepts. In most cases, that means X.509 certificates in DER or PEM format, with RSA 2048-bit or ECDSA support. Just as important, find out whether the device can join your current PKI or if it only works with self-signed certificates.
Two points often slip through the cracks. First, is RBAC enforced for security-related functions across the whole device? Second, can roles be managed from one place, or only on the device itself? Also ask how security features are licensed. TLS, centralized logging, or centralized key management may not be part of the base price. That can change fleet-wide cost in a hurry.
How to review product documentation and test plans
Start with the vendor paperwork. Look for a Protocol Implementation Conformance Statement (PICS) and a Protocol Implementation eXtra Information for Testing (PIXIT). These documents spell out which IEC 62351 parts, options, and limits the device supports. If the vendor can't hand them over, that's a gap.
Next, compare the PICS with the cybersecurity manual. That manual should show how to set up TLS, RBAC, logging, and key management. It should also explain how the device fits into common U.S. substation or SCADA setups. That part matters more than it may seem. A device can check boxes on paper and still be awkward in your network. Under IEC TS 62351-100-3, vendors submitting devices for conformance testing must provide the device, a Protocol Implementation Document (PID), and installation and operation manuals. If those items are missing, procurement has a problem.
For FAT and SAT, don't settle for generic test plans. The plan should call out IEC 62351 security behavior in plain terms, including:
- TLS handshake verification
- RBAC enforcement
- Logging of security events
- At least one controlled firmware update to confirm security settings survive the update
You should also see proof that the device works with your current control center, VPN, or firewall setup before budget is locked in, not after the gear arrives on-site.
Use those documents to complete the checklist below.
Buyer comparison checklist for IEC 62351 support
Use this checklist to compare IEC 62351 support side by side. Claims in product listings should always be checked against official datasheets and conformance documents.
| Attribute | What to verify |
|---|---|
| Equipment type | Relay, RTU, gateway, meter, switch/router |
| Supported IEC 62351 parts | Parts 3, 4, 5, 6, 7, 8, 9 - mapped to your protocols |
| Supported protocols | IEC 60870-5-104, DNP3/TCP, ICCP/IEC 60870-6, IEC 61850 MMS/GOOSE/SV |
| TLS version support | TLS 1.2 minimum; TLS 1.3 preferred; older versions disableable |
| Certificate and key management | X.509 format, key lengths, PKI integration, revocation (CRL/OCSP) |
| RBAC support | Centrally managed roles, per-function permissions, audit logging |
| Logging and monitoring | Tamper-evident logs, SIEM export, IEC 62351-7 NSM objects |
| Required licenses | Which security features are included vs. paid add-ons |
| Testing and conformance evidence | PICS/PIXIT, lab attestations, FAT/SAT coverage |
Use the checklist to test whether the claims hold up under review, not just in the datasheet.
Key takeaways for secure sourcing and deployment
Buy against the exact IEC 62351 parts your protocols call for. Match each protocol to the required part before purchase. Message protection and RBAC are not the same thing. One protects communications; the other controls who can do what. You need to verify both on the device and again during FAT and SAT.
A broad claim like "IEC 62351 compliant" is not enough on its own. Without PICS documents, conformance proof, and clear licensing terms, that claim doesn't give you much to build on.
FAQs
Which IEC 62351 parts apply to my devices?
Identify the protocols and security functions your equipment uses, then map them to the matching IEC 62351 parts.
- Part 1: Overview. Use this as the starting point to understand the scope of the series and how the parts fit together.
- Part 3: TCP/IP with TLS. This applies when equipment protects network traffic over TCP/IP with TLS.
- Parts 4–6: Protocol security for MMS, DNP3, IEC 60870, GOOSE, and Sampled Values. Match these parts to the specific field and substation protocols your devices use.
- Part 8: Role-based access control. Use this when the equipment supports user roles and permission-based access.
- Part 9: Certificate and key management. This covers how devices handle digital certificates and cryptographic keys.
- Part 14: Security logging. Use this for event logs, audit trails, and other security-recording functions.
Does IEC 62351 secure the device or only communications?
IEC 62351 goes beyond device-to-device messaging. It is built to secure communications across the utility network from end to end, from control centers all the way to sensors and actuators in substations.
With X.509 certificates and TLS, it supports mutual authentication and encryption. That means each communication point can verify who it's talking to, while the data moving across the power system stays protected.
How do I verify a vendor’s IEC 62351 claim?
Don’t stop at the feature list. Ask for the datasheet, security guide, protocol implementation statement, firmware notes, and any third-party test reports.
Then verify the device supports RBAC, unique user accounts, configurable passwords, and audit trails.
Just as important, ask for proof these controls work in practice during FAT or SAT, including:
- authentication
- digital signatures
- rejected plain MMS attempts
- account lockouts
A checkbox on a brochure doesn’t tell you much. Test evidence does.
