IEC 62351-9
Cyber-security key management for power-system equipment — the certificate, symmetric-key, and lifecycle profile that every other 62351 part depends on. Often the limiting factor on cryptographic deployment.
Also: 62351-9, key management for power systems, IEC PKI
IEC 62351-9 is the part of the IEC 62351 family that defines key management for power-system equipment — certificate issuance, distribution, rotation, revocation, and the symmetric-key handling for the protocols (notably GOOSE and SV) where TLS isn’t usable.
It is the part that the other parts depend on. -3 TLS, -4 application auth, -5 DNP3 SA, -6 GOOSE/SV HMAC, and -8 RBAC all assume keys exist, are fresh, and can be rotated. -9 is what supplies them.
What -9 covers
| Mechanism | What it specifies |
|---|---|
| X.509 PKI profile | Certificate fields, extensions for power-systems identity, chain validation rules. |
| Enrolment | Profile of EST (RFC 7030) for getting an initial certificate onto a device. |
| Renewal and rotation | How a device requests a new certificate before the current one expires; how a fleet rotates without service interruption. |
| Revocation | CRL and OCSP profiles for distributing revocation status to devices that may have intermittent connectivity. |
| Symmetric key handling | Group-key distribution for GOOSE and Sampled Values, where the receivers form a multicast group sharing one HMAC key. |
| Trust anchor management | How root and intermediate CA certificates are installed, refreshed, and removed across a fleet. |
Why this is the rate-limiting part
For DNP3 SA (-5) the operational bottleneck isn’t the HMAC — it’s the update keys. For GOOSE/SV HMAC (-6) the bottleneck isn’t the GMAC — it’s distributing the group key to every IED on the bus and rotating it without missing a frame. For TLS (-3) the bottleneck isn’t the cipher suite — it’s certificate lifecycle across hundreds of substations.
In every case the cryptographic mechanism has been deployable for years; what’s missing is a workable -9 implementation that the operator’s IT-PKI team and the OT engineering team both trust.
The two-PKI question
Most utilities already operate an enterprise PKI for IT use (Active Directory Certificate Services, a commercial CA). The unresolved architectural question is whether OT should:
- Re-use the enterprise PKI — fewer moving parts, but the IT certificate lifecycle (90-day renewals, automated rotation) doesn’t match an OT device with a 20-year service life and intermittent network access.
- Run a separate OT PKI — fits the lifecycle better, but doubles the PKI operational burden and requires the OT team to grow PKI competence.
- Hybrid — enterprise PKI as trust anchor, OT-specific intermediate CA with looser rotation policy and offline trust paths for substations.
The hybrid pattern is what most maturing programmes are converging on. There is no published GB-utility consensus on the right answer.
Deployment status
-9 conformance is rare. Most 62351 deployments today use bespoke key management — vendor-specific tooling, manual key files, ad-hoc rotation procedures — with -9 as the published target rather than the operational reality. This is the part of the family where the standards-versus-practice gap is widest, and closing it is one of the substantial OT-cyber programmes facing the GB sector through the late 2020s.