IEC 62351-5
The IEC standardisation of DNP3 Secure Authentication. Adds HMAC-based challenge/response to DNP3 so outstations can verify commands actually came from an authorised master.
Also: DNP3 SA, DNP3 Secure Authentication, 62351-5
IEC 62351-5 is the part of the IEC 62351 family that secures DNP3 (and IEC 60870-5 telecontrol protocols). It standardises the DNP Users Group’s DNP3 Secure Authentication specification — currently SAv5 in the published 2013 IEC edition, with SAv6 the current DNP Users Group version.
What it does
SA does not encrypt the payload. It authenticates it. The mechanism is challenge/response with a keyed HMAC:
- Outstation receives a control command from the master.
- Outstation challenges the master to prove identity.
- Master computes an HMAC over the original message using a session key, returns the HMAC.
- Outstation verifies the HMAC and either executes the command or rejects it.
For high-volume traffic where the round-trip cost is too high — telemetry polls every second or two — SA defines an aggressive mode in which the HMAC is included in the original message, no separate challenge, at the cost of slightly weaker freshness guarantees.
Key types
There are two key types in the SA model:
- Update keys. Long-lived, distributed by an out-of-band mechanism, used to authenticate session-key changes. Rarely changed in practice.
- Session keys. Rotated via key-change messages, used for the actual HMAC computation. The rotation interval is the operational tuning knob: too long and freshness suffers, too short and the key-change messages start eating bandwidth.
Key management for SA is one of the rate-limiters on actual deployment. See IEC 62351-9 for the broader key-management context.
Where it fits a 62443 design
SA closes the FR4 (Data Confidentiality) and FR3 (System Integrity) gap on a DNP3 conduit. An attacker who can sit on the WAN and inject packets can no longer forge a valid control command without the session key. The conduit’s plain-text payload becomes signed-plain-text, which is what an SL-T of 2 on FR4 actually requires.
Why deployment lags the standard
The mechanism has been standardised for over a decade. Adoption in GB transmission and distribution is patchy because the substation gateways in the field were specified before SA was widely supported. Refreshing the firmware across hundreds of sites is a multi-year programme that competes with primary-plant refresh, IEC 61850 station-bus migration, and every other capex priority.
The interim pattern most operators appear to have settled on is compensating controls — pin the conduit at both ends to known IPs, monitor with protocol-aware sensors (Dragos, Claroty), accept the residual FR4 gap with documented justification. Not as good as SA. Defensible until SA arrives.