DNP3 Secure Authentication Guide: SAv5, DNP3-SL and Keys

A DNP3 outstation will normally execute any well-formed operate command it receives, because the base protocol has no way to tell a genuine master station from an attacker on the same link. DNP3 (IEEE Std 1815) carries telemetry and control for electric utilities, water and wastewater, oil and gas and transport, often over long-lived serial, radio and IP links. Secure Authentication version 5 (SAv5) has been in the standard since 2012, but it is unevenly deployed and its key management is widely misunderstood, while the DNP Users Group's newer DNP3 Security Layer (formerly SAv6) and Authorization Management Protocol change the model again. This guide explains how the DNP3 security options work, how to choose between them, how to manage keys and certificates, and what to monitor. It is for SCADA engineers, utility and water OT security teams and integrators; the wider grid context is in the Smart Grid Security Guide.

Key takeaways

Base DNP3 has no authentication. Integrity checks in the link layer detect transmission errors, not tampering, so spoofed operate or restart commands are accepted unless a security layer is added.
There are three distinct security options. TLS under IEC 62351-3 protects TCP links hop by hop; SAv5 in IEEE 1815-2012 authenticates at the application layer over any medium; DNP3-SL with AMP is the certificate-based successor aligned with IEC 62351-5:2023.
Key management decides success. SAv5 depends on update keys per user and outstation; DNP3-SL and AMP move to X.509 identity and attribute certificates issued by an Authority, so no human has to handle secret keys.
Every master and outstation is a machine identity. Inventory them with their keys or certificates, owners, and renewal dates, as you would any non-human identity.
Monitoring complements authentication. Even where SAv5 is enabled, watch for unexpected function codes, new masters, authentication failures and SA statistics, and on unauthenticated links monitoring is the only control left.

How DNP3 works and why it is exposed

DNP3 was developed by Harris in the early 1990s from IEC TC 57 "Enhanced Performance Architecture" work, handed to the DNP Users Group (DNP-UG) in 1993, and adopted as IEEE Std 1815 in 2010. IEEE 1815-2012 superseded the 2010 edition; the IEEE lists 1815-2012 as Inactive-Reserved since 30 March 2023 with an active P1815 revision project, but it remains the edition products are built and certified against. A controlling station (master) polls outstations (RTUs, IEDs, PLCs), which can also report events unsolicited. It runs over serial, radio and TCP or UDP, with port 20000 the usual IP port.

DNP3 feature	Operational purpose	Abuse without authentication	ATT&CK for ICS v20
Select-before-operate and direct operate	Open or close breakers, start pumps	Spoofed control commands	T1692.001 Unauthorized Message: Command Message
Cold and warm restart	Remote device restart	Repeated restarts to deny control	T0816 Device Restart/Shutdown
Unsolicited responses	Report-by-exception to the master	Spoofed or suppressed events and values	T1692.002 Unauthorized Message: Reporting Message
Disable unsolicited, stop application	Maintenance functions	Silencing an outstation	T0814 Denial of Service
File transfer and configuration	Firmware and configuration management	Configuration change or exfiltration	T0888 Remote System Information Discovery
Plaintext on the wire	Simplicity, low bandwidth	Interception and modification on the path	T0842 Network Sniffing, T0830 Adversary-in-the-Middle

The exposure is not theoretical: DNP3 outstations are frequently found reachable from the internet or from corporate networks, mapped by T0883 Internet Accessible Device and T0846 Remote System Discovery. Segmentation is the first control on every link; see the OT Network Segmentation Guide.

The DNP3 security options compared

Option	Where defined	What it protects	Media	Keys and identity	Main limitations
TLS	IEC 62351-3:2023 profile (TLS 1.2 and 1.3)	Confidentiality and integrity per TCP connection	TCP only	X.509 certificates per endpoint	No protection on serial or radio; terminated by gateways and front-end processors; hides traffic from passive monitoring
SAv5	IEEE 1815-2012 (Secure Authentication version 5)	Authenticity and integrity of critical messages; optionally all messages	Any, including serial	Symmetric update keys per user and outstation, or asymmetric update key change; session keys derived and changed periodically	Complex key management; challenge-response adds round trips on slow links; uneven vendor support
DNP3-SL with AMP	DNP-UG DNP3 Security Layer (formerly SAv6) implementing IEC 62351-5; Authorization Management Protocol as the Central Authority	Authentication and integrity of every message, optional encryption	Designed as a separate layer usable across networks	X.509 identity certificates; X.509 attribute certificates for roles per IEC 62351-8; Authority issues and revokes	New; product availability and conformance testing still maturing; needs an Authority service
Bump-in-the-wire or VPN	Outside the DNP3 and 62351 standards	Encrypted tunnel between two devices	IP, some serial encryptors	Device keys in the appliance	Protects the link, not the endpoint; adds devices to manage

How SAv5 works

Critical messages are challenged: when the outstation receives a message it treats as critical (for example a control operation), it replies with a challenge, and the master answers with a message authentication code computed with the current session key. Aggressive mode lets the master send the MAC with the request to save a round trip.
Two key levels: long-term update keys, shared per user between the master and each outstation, are used to change the shorter-term session keys, which are refreshed after a set time or number of messages.
Update key change: SAv5 supports a symmetric method, where update keys are distributed by an authority as shared secrets, and an asymmetric method using public keys.
Statistics: SAv5 defines security statistics for monitoring association state, which the master can poll and report.

What changed with IEC 62351-5:2023 and DNP3-SL

IEC 62351-5:2023 replaced the 2013 technical specification that SAv5 was aligned with. According to the IEC, it sets up secure communication per controlling and controlled station association, removes user management and the symmetric update key change method, reviews the asymmetric method, removes challenge and reply, replaces aggressive mode with a Secure Data exchange, and adds authenticated encryption and event logging. The DNP-UG describes DNP3-SL as implementing IEC 62351-5, authenticating every message so the challenge step disappears, and able to run alongside SAv5 during migration. Its Zero Trust in DNP3 paper (revision 3, May 2022) explains that SAv6 sits as a layer between the application and transport layers and derives session keys with ECDH and HKDF using X.509 identity certificates, the same primitives as TLS 1.3.

Choosing the right protection per link

Master to outstation over IP, both ends under your control: TLS under IEC 62351-3 is the fastest win where products support it; add application-layer authentication if a front-end processor or protocol gateway sits in between.
Serial or radio links: TLS cannot help. Use SAv5 where both ends support it, or plan DNP3-SL as equipment is replaced; until then use link encryptors and monitoring.
Through gateways and data concentrators: application-layer security (SAv5 or DNP3-SL) is the only option that stays end to end across devices that terminate the transport.
Bandwidth-constrained links: measure the added round trips of SAv5 challenge-response on polling cycles; DNP3-SL's per-message authentication avoids the extra exchange.
New procurement: require IEC 62351-3:2023 TLS, SAv5 per IEEE 1815-2012 as a minimum, a roadmap for DNP3-SL and AMP, conformance certification from the DNP-UG, and export of security events.
Small water utility vs large transmission operator: a small utility with a few dozen RTUs may realistically start with segmentation, a VPN between the SCADA server and each site, and monitoring, then enable SAv5 at the next RTU refresh. A large operator should run a central key or certificate authority, standard templates per RTU model, and a phased SAv5 to DNP3-SL plan.

Where identity fits: keys, certificates and the Authority

Whichever option you choose, DNP3 security turns every master and outstation into an authenticated machine identity, and the operational work is identity lifecycle management.

Credential	Used by	Lifecycle questions
SAv5 update keys	Master and each outstation, per user	How are they generated and loaded (field visit, authority, asymmetric change)? Who can read them on the master? When are they changed after staff or contractor changes?
SAv5 session keys	Derived automatically	Change interval and message count configured consistently on both ends
TLS certificates	SCADA front end and IP outstations	Issuing CA, validity, renewal without a site visit, revocation reachable from site
DNP3-SL identity certificates	Every device	Issued by the AMP Authority or another PKI; devices can generate their own keys so personnel never handle secrets
AMP attribute certificates	Per controlling station and outstation association	Carry roles under IEC 62351-8; revocable quickly after an incident; status checked periodically by policy
Authority policy	All managed devices	How devices find the Authority, how often credentials update, and behaviour if the Authority is unavailable

Protect the master: the SCADA master holds keys for every outstation. Treat it as a tier 0 asset with restricted administrator access and keys stored in hardware or an encrypted keystore. See the OT and ICS Identity and Access Guide.
Avoid pre-shared keys in spreadsheets: SAv5 symmetric update keys typed in by field technicians end up in configuration files and emails. Prefer the asymmetric method or DNP3-SL, and if symmetric keys are unavoidable, vault them. See the Secrets Management Guide.
Run the PKI as an OT service: separate the Authority's CA certificate from the identity certificate it uses to sign AMP messages, as the DNP-UG recommends ("one key, one purpose"). See the Machine Identity, PKI and Certificate Lifecycle Guide.
Plan for post-quantum: the DNP-UG flyer states AMP will use ML-KEM for key establishment. Record algorithms per device now. See the Post-Quantum Migration for NHIs Guide.

Implementation steps

Inventory links: for every master and outstation pair record medium, firmware, DNP3 subset level, and support for TLS, SAv5 and DNP3-SL. See the OT Asset Visibility Guide.
Segment and restrict: allow port 20000 only between known masters and outstations; block it at the enterprise and internet boundary.
Start monitoring: deploy passive DNP3-aware monitoring and baseline normal function codes, masters and polling patterns before you change anything.
Choose the key model: decide on an authority for SAv5 update keys or certificates, its location, redundancy and operating procedures.
Pilot on one site: enable SAv5 (or TLS on IP links) between the master and one outstation in a test rig, then one live site, measuring poll cycle times and failed authentications.
Agree failure behaviour: decide with operations what happens if authentication fails or keys expire: alarm, fall back, or refuse control. Protection of the process must not depend on an untested key server.
Roll out by template: per RTU model and firmware, with configuration under change control and the previous configuration kept for rollback within the maintenance window.
Plan DNP3-SL migration: as vendors ship DNP3-SL and AMP, pilot alongside SAv5 (they can coexist) and move new sites first.

Testing before go-live: in the test rig, confirm that a replayed operate command is rejected and logged, that a command from an unconfigured master is refused, that session keys change on schedule without dropping polls, and that the master raises an alarm when an outstation's authentication fails. Repeat after every firmware upgrade on either end, because security settings are a frequent casualty of upgrades. Ask vendors for DNP-UG conformance certificates covering the security functions you use, and keep the test results as assurance evidence.

Rollback: keep the last known good configuration of both master and outstation, and agree in advance who can authorise disabling authentication on a link during an operational emergency, how that is logged, and how quickly it must be re-enabled.

Detection and measurement

Unexpected function codes: restart, stop application, disable unsolicited, file transfer and operate commands outside maintenance windows or from hosts that are not approved masters.
New masters: any source address or IP sending requests to an outstation for the first time.
Authentication events: SAv5 authentication failures, key change failures and session key changes outside the configured schedule, from SA statistics and master logs.
Protocol anomalies: malformed frames, unusual object groups, broadcast addresses and traffic volume changes.
Standardised monitoring: IEC 62351-7:2025 defines network and system management objects that cover IEEE 1815 monitoring data with an SNMP mapping, which helps bring outstation health and security state into the SOC. See the OT Network Security Monitoring Guide and the Zeek Network Monitoring Guide.

Metrics: percentage of control links with SAv5, DNP3-SL or TLS; outstations reachable from outside their zone (target zero); authentication failures per week investigated; keys or certificates past their planned change date (target zero); percentage of links covered by DNP3-aware monitoring.

Framework mapping

Control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat (ATT&CK for ICS v20)
SAv5 or DNP3-SL message authentication	SC-8, SC-23	PR.DS-02	T1692.001, T1692.002, T0830
TLS on IP links	SC-8, SC-13	PR.DS-02	T0842, T0830
Device authentication with certificates	IA-3, SC-17	PR.AA-03	T0859 Valid Accounts
Update key and certificate lifecycle	SC-12, IA-5	PR.AA-01	T0830
AMP roles	AC-3	PR.AA-05	T0816, T0814
Segmentation of port 20000	SC-7	PR.IR-01	T0883, T0846
DNP3-aware monitoring	SI-4, AU-2	DE.CM-01	Detection of the above

Common failure patterns

SA enabled only on paper: devices support SAv5 but it is switched off because commissioning was easier without it, and nobody revisits it.
Same update key everywhere: one symmetric key loaded into every outstation, so a key extracted from one RTU in a remote kiosk authenticates commands to all of them.
Critical message list too narrow: only operate commands challenged, while restarts and configuration changes go through unauthenticated.
TLS terminated at the gateway: encryption on the WAN, then plaintext DNP3 on to the outstation through a protocol converter, with no end-to-end authentication.
Blind spots after encryption: monitoring loses visibility once TLS is enabled and nobody moves sensors to the endpoints.
Exposure through remote access: outstations reachable through an integrator's always-on VPN or cellular modem. See the OT Third-Party and Integrator Access Guide.

No live NHI Mgmt Group breach page covers a DNP3 compromise, so none is linked here.

Practitioner checklist

Inventory every DNP3 master and outstation with medium, firmware and supported security options.
Restrict port 20000 to known master and outstation pairs and remove any internet or enterprise exposure.
Deploy DNP3-aware monitoring and baseline function codes and masters before enabling security.
Enable TLS under IEC 62351-3 on IP links that support it, and application-layer authentication across gateways.
Enable SAv5 with unique keys per outstation and a challenged message set that covers restarts and configuration changes.
Run key and certificate management as an OT service with an owner, vault and renewal schedule.
Agree and test failure behaviour for authentication and key expiry with operations.
Specify IEC 62351-5:2023 alignment, DNP3-SL and AMP roadmaps and DNP-UG conformance in procurement.
Track coverage and authentication failure metrics monthly.

DNP3 and DNP3 Secure Authentication Guide: SAv5, DNP3-SL, Key Management and Monitoring