DNP3 Explained: IEEE 1815, Utility SCADA and Secure Authentication

DNP3, the Distributed Network Protocol, is the SCADA protocol that electric, water and other utilities use to collect measurements from field devices and send them control commands. A master station in a control centre polls outstations such as RTUs and substation computers over serial links or over TCP and UDP port 20000, and outstations can report changes on their own. Classic DNP3 has no authentication or encryption; DNP3 Secure Authentication, defined in IEEE 1815 and aligned with IEC 62351-5, adds message authentication for the requests that matter.

Key takeaways

• DNP3 is an application protocol for telemetry and control between a master (now often called a controlling station) and outstations. It was designed for utilities and spread into water and wastewater, transportation, and oil and gas, according to the DNP Users Group.
• It uses a three layer "Enhanced Performance Architecture" from IEC TC57: a data link layer with CRC protected frames, a small transport function that splits and reassembles messages, and an object based application layer. Over IP the whole link frame rides inside TCP or UDP.
• IANA registers port 20000 as dnp (TCP, UDP and SCTP) and port 19999 as dnp-sec, "Distributed Network Protocol - Secure".
• IEEE first published DNP3 as IEEE Std 1815-2010 (1 July 2010). IEEE 1815-2012 (published 10 October 2012) superseded it. IEEE lists 1815-2012 as "Inactive-Reserved" since 30 March 2023, and a revision project, P1815, has an active authorisation approved in 2015.
• According to the DNP Users Group, Secure Authentication version 2 was part of IEEE 1815-2010 and version 5 is part of IEEE 1815-2012. SAv5 authenticates "critical" requests with a challenge and response using message authentication codes, and offers no encryption.
• IEC 62351-5:2023 (published 13 January 2023) replaced IEC TS 62351-5:2013. It removed the challenge and reply procedure, replaced Aggressive Mode with a Secure Data exchange, and added authenticated encryption. The DNP Users Group's implementation is DNP3-SL, the DNP3 Security Layer, formerly called SAv6.
• Classic DNP3 trusts anyone who can deliver a well formed frame, so segmentation and monitoring of who sends controls come first.

What DNP3 is for, the layer and the standard

Why electric and water utilities use it

A utility runs equipment spread over a wide area: substations, pumping stations, reservoirs, feeders, pipelines. The DNP3 Protocol Primer published by the DNP Users Group describes the typical case: an operations centre with a master station that stores incoming data and displays it to operators, and substation computers that collect data from breakers, current sensors and voltage transducers and carry out commands to energise or de-energise equipment. The outstations report binary inputs (a breaker is closed or tripped, a pressure alarm is normal or high), analog inputs (voltages, currents, power, reservoir levels, temperatures), counters (kilowatt hours or fluid volume) and files. The master sends controls (close or trip a breaker, start or stop a motor, open or close a valve) and analog output setpoints.

Three properties made DNP3 the default for this work in North America:

• It was built for slow, noisy, wide area links. Dial up lines, multi drop radio and leased circuits. The link layer detects errors and duplicates, and the application layer can report only what changed.
• It keeps time stamped events. An outstation can buffer state changes with time stamps, so the master can rebuild a sequence of events after an outage or a communications gap.
• It is open. Utilities can buy masters and outstations from different manufacturers and expect them to interoperate.

A 2022 DNP Users Group white paper states that DNP3 "is presently used by over 90% of power utilities in North America" to monitor and control field devices, and that it is also widely used in water and wastewater.

Where it sits in the stack

DNP3 is described by the DNP Users Group as based on the IEC Technical Committee 57, Working Group 03 "Enhanced Performance Architecture", an OSI three layer model for telecontrol. The original design defined the application layer, data link layer and physical layer, with the physical layer most commonly RS-232 or RS-485. A thin transport function sits between application and link. The DNP Users Group notes that IEEE 1815 calls it the "Transport Function" for historical reasons, and the primer calls it a pseudo transport layer because it is part of the application layer software.

Over IP, the primer says "link layer frames ... are embedded into TCP/IP packets". The whole DNP3 link frame, CRCs included, becomes the TCP or UDP payload. DNP3 addressing and CRCs are therefore the same on every medium.

The defining documents

"Inactive-Reserved" is IEEE's label for a standard that was not revised within its ten year lifecycle. It does not mean DNP3 is withdrawn or deprecated: 1815-2012 remains the edition vendors and utilities cite, and the revision is in ballot. When a procurement document says "IEEE 1815", ask which edition and which Secure Authentication version it means.

The DNP Users Group says DNP3 was developed by Harris, Distributed Automation Products, and that in November 1993 ownership of the specifications passed to the DNP Users Group, a body of utilities and vendors. The user group still owns the protocol, licenses its work to IEEE under a sharing agreement, and maintains application notes, technical bulletins, test procedures and the XML device profile format for members.

How DNP3 works on the wire

Masters, outstations and topologies

Each DNP3 device keeps arrays of points numbered from zero, called point indexes. The master keeps its own copy of the input data and tries to keep it current by polling. The primer lists the common topologies:

• One on one: one master and one outstation, historically over a dedicated or dial up line.
• Multi drop: one master polls several outstations in turn on a shared line or radio channel. Every outstation hears the master but must only answer messages addressed to it.
• Hierarchical: a sub master is an outstation to the control centre and a master to devices below it.
• Data concentrator or protocol converter: a substation device gathers data from local devices, possibly in another protocol, and serves it to the master as DNP3.

That last pattern matters for security. A data concentrator or gateway parses traffic from both sides and often bridges serial devices onto an IP network, which turns it into the boundary you defend.

The data link frame

The link layer makes an imperfect channel reliable through error detection and duplicate frame detection. Field sizes below combine the primer with Wireshark's DNP3 display filter reference, which lists the start bytes, destination and source as 16 bit fields and length and control as 8 bit fields.

The primer gives the limits: 65,520 individual addresses, three destination addresses reserved for all call (broadcast) messages, a maximum of 250 data octets per frame excluding CRCs, and a maximum frame of 292 octets with every header and CRC octet counted.

Link layer confirmation is optional. A sender can ask the receiver to confirm each frame and retry if no confirmation arrives. The primer notes it is often not used because the application layer has its own confirmations, and because confirmation and retries cost time.

None of these fields is a security control. The source address is a number the sender writes, the CRC is a public algorithm anyone can compute, and the frame count bit only detects duplicates.

The transport function

Application messages can be far longer than 250 octets, so the transport function splits them. It adds one octet to each frame with a FIR flag (first frame of a message), a FIN flag (final frame) and a sequence number, which leaves 249 application octets per frame. The receiver reassembles frames in order and hands the complete fragment to the application layer.

The application layer: fragments, functions and objects

Application messages are broken into fragments sized to the receiver's buffer, which the primer says normally ranges from 2,048 to 4,096 octets. A 2,048 octet fragment takes 9 link frames; a 4,096 octet fragment takes 17. The primer adds a field note: on noisy channels, smaller fragments often work better.

Each fragment starts with an application header:

Each object header names a group (the data type), a variation (the encoding), a qualifier (how the points are identified) and a range (a start and stop index, a count, or a list of indexes). The primer gives the example of analog data. Static analog inputs are group 30 with six variations, from a 32 bit integer with a flag octet to a 64 bit float with flag. Analog input events are group 32 with eight variations, some of which carry an event time stamp. The flag octet tells the master whether the source is online, restarted, lost communication downstream, was forced, or is over range. Every value in a response carries its group and variation, so the master can parse it without knowing the outstation's configuration in advance.

Internal indications, the two octets in every response, are the outstation's status line. Wireshark names bits such as Class 1, 2 and 3 Data Available, Device Restart, Device Trouble, Event Buffer Overflow, Time Sync Required, Configuration Corrupt, Function Code not implemented, Requested Objects Unknown and Parameters Invalid or Out of Range. An outstation that keeps reporting restarts or a corrupt configuration deserves a look.

Static data, events and classes

DNP3 separates static data, the present value of a point, from events, records that something significant happened: a binary input changed state, or an analog value moved by more than its configured deadband. Events can carry time stamps.

Events are sorted into three classes. The primer says class 1 was originally meant as the highest priority and class 3 the lowest, but users now assign classes however suits their operation. The master can poll for class 1, 2 or 3 events or any combination, and the class data available bits in the internal indications tell it which classes have something waiting. The efficient pattern the primer describes is to poll mostly for events, which are few, and only occasionally request all static data "as an integrity measure".

Controls: select before operate and direct operate

The primer names two styles of control. Select before operate is a two step sequence: the master first selects the point, gets the outstation's response, and only then sends a separate operate request. Direct operate does it in one message. The extra step is there to make sure the intended point is armed before anything moves. It is an operational safeguard, not authentication: any sender that can produce both messages gets the same result.

Unsolicited responses

An outstation that supports it can send an unsolicited response, reporting events without waiting to be polled. The primer says this is useful where there are many outstations and the master needs to hear about a change quickly. It also warns that spontaneous transmissions should be infrequent, or contention on a shared channel makes polling better, and that DNP3 leaves the collision avoidance algorithm to the implementer.

A typical exchange

Master (controlling station)                 Outstation
   |                                               |
   |-- Read: class 1, 2, 3 events --------------->|   poll for events
   |<-- Response: events + IIN (class data bits) --|
   |-- Application confirm ---------------------->|   events can be cleared
   |                                               |
   |-- Read: static data (occasional) ----------->|   integrity poll
   |<-- Response: present values + IIN ------------|
   |                                               |
   |-- Select: breaker 3 trip ------------------->|   select before operate
   |<-- Response to select ------------------------|
   |-- Operate: breaker 3 trip ------------------>|
   |<-- Response to operate -----------------------|
   |                                               |
   |<-- Unsolicited response: event (UNS set) -----|   outstation reports a change
   |-- Application confirm ---------------------->|

Over IP the same exchange runs inside one TCP connection, or as UDP datagrams, with the DNP3 link frame as payload.

IANA registrations

Port 20000 is a default, not a rule. Devices and masters can be configured to other ports, so an inventory based only on port numbers will miss some links.

Versions and history

What is deployed in practice:

• Implementation levels. DNP3 groups features into subset levels. The primer describes level 1 as the most basic, with level 2 and level 3 progressively richer. A simple feeder device may only support level 1, which limits which requests the master can use.
• Secure Authentication adoption is uneven. Many outstations in service predate SAv5 or support it only in later firmware.
• Terminology is shifting. Recent DNP Users Group documents replace "master" with "controlling station". Both terms refer to the same role.

Security properties and known weakness classes

What DNP3 does and does not guarantee

NIST SP 800-82 Rev. 3, the US government's guide to OT security, states the general case: "Many OT protocols have no authentication at any level", which creates "the potential to replay, modify, or spoof data or devices", and "Integrity checks are not built into most OT protocols, so adversaries could manipulate communications undetected." Classic DNP3 fits that description. It was designed for private serial and radio links where the main risks were noise and equipment failure, and it carried that trust model onto IP.

Weakness classes, explained as concepts

These are the recurring ways DNP3 deployments go wrong, described so you can recognise them in your own systems. Most follow from the design and need no software bug.

Unauthenticated control commands

Without Secure Authentication, an outstation checks that a request is well formed, addressed to it, and allowed by its configuration. It has no way to check who sent it. Select before operate confirms the intended point, not the sender. Any host that can reach an outstation's DNP3 port, or inject frames onto a serial or radio channel, can in principle issue the same controls and setpoints as the control centre. Restart, time set and file functions fall into the same class.

Spoofed outstation responses and false data

The risk runs the other way too. A master accepts whatever responses and unsolicited responses arrive with the right addresses and sequence. Spoofed or altered data can show operators a breaker as closed when it is open, or hide an alarm. Unsolicited responses widen the window, because the master expects data it did not ask for. NIST's phrase "spoof data or devices" covers this: integrity of the picture on the operator's screen is a safety issue in its own right.

Addresses are not identities

DNP3 source and destination addresses are 16 bit numbers each device writes into its own frames. Some masters and outstations check that the source address matches the configured peer, which helps against misconfiguration but not against a sender who writes the expected number. All call addresses deliver a message to every device on a link at once.

Parser flaws in masters and gateways

DNP3 is rich: dozens of groups and variations, several qualifier codes, ranges and counts, fragments reassembled from frames, and responses whose length is driven by the sender. The master parses all of that from every outstation it polls, and a data concentrator parses it from both directions. A device in the field, or anything on the path to it, controls the input to the parser in the control centre. Length, count and range values that disagree with the bytes actually received are a classic source of crashes and memory safety bugs in protocol stacks. That is a supply chain problem, covered below.

Exposure of port 20000

DNP3 over IP made remote data collection cheap, and also made outstations reachable from wherever a route exists: a flat corporate network, a cellular modem with a public address, a port forward for a vendor, a cloud hosted master. CISA's May 2025 fact sheet on OT mitigations says OT devices "are quickly found by searching for open ports on public IP ranges", and its first recommendation is to "Remove OT connections to the public internet". Once a classic DNP3 outstation is reachable, the protocol offers no second line.

Weak or partial Secure Authentication deployments

SAv5 protects only what it is configured to protect, and only where both ends enforce it. Concepts to watch:

• Critical only. In SAv5 only requests designated critical are challenged. The DNP Users Group's own description of SAv6 says it "no longer has the concept of 'critical' messages", because every message is authenticated. In SAv5, reads and the data returned by them can travel unauthenticated, so spoofed data remains possible even when controls are protected.
• Fallback. If an outstation can be configured to accept unauthenticated critical requests when authentication is disabled or fails, an association can quietly run without protection. Check that enforcement, not just support, is switched on.
• Key handling. SAv5 relies on Update Keys installed on both ends. The 2013 edition of IEC 62351-5 added a remote method to change them; before that they were often loaded by hand. The design principles for SAv6 list "no human access to any shared secrets", which tells you where the earlier pain was. Keys that are shared across many outstations, never rotated, or stored in plain configuration files reduce SAv5 to a password.
• No confidentiality. SAv5 does not encrypt. Point lists, setpoints and operational patterns remain readable to anyone on the path.

Availability

Serial and radio channels have little spare capacity. Floods of requests, excess unsolicited traffic, or a full event buffer (internal indication "Event Buffer Overflow") can cost the master data it needs.

How Secure Authentication version 5 challenges critical requests

IEEE 1815-2012 is a paid standard, so this description is conceptual and draws on IEC's published summaries, DNP Users Group material and the protocol objects Wireshark decodes. Check the standard itself before designing around a detail.

SAv5 lives in the application layer as additional function codes and objects. The objects Wireshark decodes for it include Challenge Sequence Number, Challenge Data, Reason for Challenge, MAC Algorithm, MAC Value, Key Wrap Algorithm, Key Status, Key Change Sequence Number, Encrypted Update Key Data, User Number and User Name. They map to these ideas:

1. Two levels of keys. Each user on an association has a long lived Update Key, shared by master and outstation. Update Keys are used to deliver short lived session keys, wrapped with a key wrap algorithm, and the session keys compute the message authentication codes. Session keys are replaced from time to time, and the 2013 IEC edition added "measures to avoid being forced to change session keys too often".
2. Challenge on a critical request. When an outstation receives a request it treats as critical, such as an operate command, it does not act. It replies with a challenge carrying fresh challenge data, a sequence number and a reason. The master must answer with a MAC, computed with the current session key, over the challenge and the original request. If the MAC verifies, the outstation executes the request.
3. Aggressive Mode. To save the round trip on slow channels, a master can include authentication data in the critical request itself, based on the last challenge it received. IEC 62351-5:2023 replaced this with a "Secure Data message exchange mechanism".
4. Users and roles. SAv5 identifies a user by number, so actions can be tied to an operator or application rather than only to the master station. IEC 62351-5:2023 removed the in protocol user management (add, change or delete a user).
5. Statistics. The 2013 edition added security statistics "to aid in detecting attacks", such as counts of failed authentications, and told implementations to discard unexpected messages "more often as possible attacks".

Its limits are the ones listed above: partial coverage, symmetric key management, and no encryption.

What DNP3-SL (formerly SAv6) and IEC 62351-5:2023 change

IEC 62351-5:2023 cancelled and replaced IEC TS 62351-5:2013 as a technical revision. Its published summary lists the main changes: security is performed per controlling station and controlled station association; user management was removed; the symmetric method to change the Update Key was removed and the asymmetric method reviewed; the challenge and reply procedure was removed; Aggressive Mode was replaced by Secure Data; authenticated encryption of application data was added; the permitted algorithms and the sequence number rules were updated; and event monitoring and logging was added.

The DNP Users Group describes DNP3-SL, the DNP3 Security Layer and formerly SAv6, as its implementation of IEC 62351-5. From the user group's flyers and its zero trust white paper:

• It is a separate layer between the application layer and the transport function, so it authenticates every application message instead of a selected few, and it "Can co-exist with DNP3-SAv5".
• It uses HMACs and, optionally, authenticated encryption with additional data (AEAD). The encrypted mode is optional because, as the white paper explains, "the ability to perform deep inspection of control commands and real-time data often trumps the confidentiality requirement" at the grid edge.
• Association establishment uses Elliptic Curve Diffie-Hellman and HKDF, the same primitives TLS 1.3 uses, and requires X.509 identity certificates for both the controlling station and the outstation. The newer flyer says it "Will use post-quantum cryptography for Association establishment", naming ML-KEM.
• It "Does not use pre-set keys": no person handles shared secrets.
• The companion Authorization Management Protocol (AMP) acts as an IEC 62351-5 central authority. It issues identity certificates, authorises each controlling station to outstation association with X.509 attribute certificates carrying IEC 62351-8 roles, can revoke authorisation quickly, distributes security policy, and provides certificate status checks without distributing full revocation lists. AMP transports are defined for AMQP and DNP3-SL.

The white paper is candid about gaps: object level access control is "Still to be added", remote attestation is "Not provided in this version", and implementing roles in devices "is the responsibility of the vendor".

For planning: SAv5 is what most installed equipment can do, if anything, and DNP3-SL is where new specifications point. Know which associations run which, and which run nothing.

Secure configuration and exposure checks, with defender side commands

Securing DNP3 is mostly about where it can be reached, from where, by whom, and whether Secure Authentication is enforced on the associations that carry controls. Commands below come from the ss(8) man page, the tcpdump(1) and pcap-filter(7) man pages, the tshark and wireshark-filter man pages with Wireshark's DNP3 display filter reference, and Microsoft Learn's Get-NetTCPConnection page, all listed in Sources. Only run them against systems and networks you own or are authorised to test. Passive capture on a control network is generally safe, but agree it with operations first, and never send DNP3 requests to production outstations as a "test".

1. Find every DNP3 listener and client on hosts you run

Start with the Linux and Windows hosts on the control network: SCADA masters, front end processors, historians, data concentrators running embedded Linux, and engineering workstations. A listener on 20000 you did not expect, such as a simulator left from commissioning, is a common finding.

# Linux: processes listening for DNP3 (20000) or the registered secure port (19999)
ss -tlnp 'sport = :20000'
ss -tlnp 'sport = :19999'
ss -ulnp 'sport = :20000'

# Linux: processes on this host holding connections to DNP3 outstations
ss -tnp 'dport = :20000'

-t and -u select TCP and UDP, -l shows listening sockets, -n keeps ports numeric and -p shows the owning process; the port filter syntax is from the ss(8) man page.

# Windows: DNP3 listeners and outbound DNP3 connections, with the owning process ID
Get-NetTCPConnection -LocalPort 20000 -State Listen
Get-NetTCPConnection -RemotePort 20000 | Select-Object LocalAddress,RemoteAddress,State,OwningProcess

2. Build a baseline of who talks DNP3

Outstations cannot run ss, so you learn about them from the network. On a mirror or SPAN port you control, capture DNP3 for a representative period, long enough to include integrity polls and some unsolicited traffic:

# Capture DNP3 over TCP and UDP on a monitoring interface you own, without name resolution
tcpdump -n -i eth1 -w dnp3.pcap 'port 20000 or port 19999'

Then summarise it with tshark:

# Which IP hosts hold DNP3 conversations
tshark -r dnp3.pcap -q -z conv,tcp

# IP pair, DNP3 source and destination addresses, and application function code
tshark -r dnp3.pcap -Y 'dnp3' -T fields \
  -e ip.src -e ip.dst -e dnp3.src -e dnp3.dst -e dnp3.al.func | sort | uniq -c | sort -rn

# Unsolicited responses: which outstations report on their own, and to whom
tshark -r dnp3.pcap -Y 'dnp3.al.uns == 1' -T fields \
  -e frame.time -e ip.src -e ip.dst -e dnp3.src -e dnp3.dst

# Outstation health flags worth a ticket: restarts, device trouble, corrupt configuration
tshark -r dnp3.pcap -Y 'dnp3.al.iin.rst == 1 or dnp3.al.iin.dt == 1 or dnp3.al.iin.cc == 1' -T fields \
  -e frame.time -e ip.src -e dnp3.src

# DNP3 on a non default port (here 20001): tell tshark to decode it as DNP3
tshark -r other.pcap -d tcp.port==20001,dnp3 -Y 'dnp3' -T fields -e ip.src -e ip.dst -e dnp3.al.func

dnp3.src, dnp3.dst, dnp3.al.func, dnp3.al.uns and the dnp3.al.iin.* flags are field names in Wireshark's DNP3 display filter reference; -z conv,tcp and -d (decode as) are from the tshark man page, and the or operator is from the wireshark-filter man page. tshark prints function codes by name, which makes the output readable for operations staff.

The result is your baseline: the masters that poll, the outstations they poll, the DNP3 addresses each uses, which function codes each master sends, and which outstations report unsolicited. Two questions to ask of it straight away. Does any host other than a known master send select, operate or direct operate? Does any IP address appear with more than one DNP3 source address, or any DNP3 address appear from more than one IP?

3. Check whether Secure Authentication is actually in use

Configuration screens say what a device supports. Traffic shows what it does. When SAv5 is active, challenges, replies and key status messages appear on the wire as the Secure Authentication objects Wireshark decodes:

# Associations that carry SAv5 traffic: challenges, MACs and key status
tshark -r dnp3.pcap -Y 'dnp3.al.sa.csq or dnp3.al.sa.mac or dnp3.al.sa.ksq' -T fields \
  -e ip.src -e ip.dst -e dnp3.src -e dnp3.dst -e dnp3.al.sa.usr -e dnp3.al.sa.mal | sort | uniq -c

# Authentication errors and reasons for challenge, which can show failed or misconfigured peers
tshark -r dnp3.pcap -Y 'dnp3.al.sa.err or dnp3.al.sa.rfc' -T fields \
  -e frame.time -e ip.src -e ip.dst -e dnp3.al.sa.err -e dnp3.al.sa.rfc

Compare the list of associations from step 2 with the list here. Every association where controls flow but no Secure Authentication objects appear is running unauthenticated. For each one that does use it, confirm with the vendor's configuration tool that the outstation rejects unauthenticated critical requests rather than merely supporting authentication, check which MAC algorithm is negotiated, and find out how the Update Keys were installed, where they are stored, and when they were last changed. For DNP3-SL associations, ask the vendor how you can see whether the encrypted mode is on and how certificates are issued and revoked; that tooling varies by product.

4. Segment with zones and conduits

NIST SP 800-82 Rev. 3 recommends "network segmentation utilizing levels, tiers, or zones" with a DMZ as an enforcement boundary between IT and OT, and CISA's fact sheet recommends segmenting IT and OT and "introducing a demilitarized zone for passing control data to enterprise logistics". For DNP3:

• Put outstations, data concentrators and the front end processors that poll them in their own zone. Nothing else belongs there.
• Write conduit rules per master and per outstation: only the master addresses from your baseline may open TCP 20000 to an outstation, and only to the outstations they poll. Avoid "any to RTU subnet on 20000".
• Where masters receive unsolicited responses over UDP, or outstations open the connection to the master, write those directions explicitly.
• Keep the enterprise network out. Historians or one way gateways in the DMZ publish values outward so office users never reach port 20000.
• NIST notes that OT firewalls "often provide built-in parsers for common OT protocols, such as DNP3, CIP, and Modbus". A conduit that allows reads from the historian and controls only from the SCADA masters removes much of the unauthenticated control risk even before Secure Authentication.
• Treat serial to IP converters and cellular routers as part of the zone boundary, with the same rule discipline.

The ISA/IEC 62443 series formalises this as zones and conduits; our posts on IEC 62443 roles, zones, conduits and safety and who is responsible for what under ISA/IEC 62443 cover the model.

5. Control remote access

CISA's guidance: if remote access is essential, move OT assets off the public internet onto a private connection and use a VPN with "phishing-resistant multifactor authentication", apply least privilege "for the specific asset and user role", and disable dormant accounts. Vendor support for RTUs and masters should land on a jump host in the DMZ, never on the outstation network, and only for the duration of the job. Then ask the teams that run your perimeter, cloud accounts and cellular fleet whether 20000 or 19999 is reachable from the internet or a partner network; CISA asks organisations to "identify their public-facing assets and remove unintentional exposure".

6. Log and monitor

Alert on new DNP3 talkers, controls from unexpected sources, a master's DNP3 address appearing from a new IP, bursts of authentication errors, and outstation restarts. NIST observes that some IDS and IPS products include signatures for DNP3, and the DNP Users Group's newer security work adds security statistics and logging aligned with IEC 62351-14. Keep conduit firewall logs. Keep logic in the outstation or PLC that limits setpoints to safe ranges, because the protocol will deliver any well formed value.

7. Keep the software that speaks DNP3 patched

DNP3 runs inside software you own and ship: SCADA masters and front end processors, historians, data concentrators and protocol gateways on embedded Linux, DER controllers, simulators, and container images at the edge, many of them built on open source or commercial DNP3 stacks. Segmentation cannot remove parser bugs in those stacks, because the master must parse what its outstations send. Inventory those components and their versions like any other dependency. Our posts on vulnerabilities in SCADA and industrial control software and the Civil Infrastructure Platform and industrial Linux cover the patterns and the Linux base many gateways ship on.

This is where Safeguard fits, and only here. Safeguard's software composition analysis, generally available, builds a full transitive dependency inventory of the repositories and container images you give it, including the protocol libraries inside them, and its SBOM generation and analysis (SPDX and CycloneDX, generally available) lets you ask which products contain a given DNP3 or TLS library version. Vulnerability management with EPSS and KEV enrichment and reachability analysis, both generally available, rank the findings, and policies and gates (generally available) stop a known vulnerable version from shipping. Safeguard does not inspect or block DNP3 traffic or replace vendor firmware updates.

NERC CIP and NIST SP 800-82

For North American bulk electric system owners, NERC's Critical Infrastructure Protection standards frame much of this work: electronic security perimeters, remote access, patching and supply chain risk. Our posts on energy sector software security and NERC CIP, NERC CIP evidence for utility vulnerability management and NERC CIP-013 and software supply chain risk cover the compliance side. NIST SP 800-82 Rev. 3, "Guide to Operational Technology (OT) Security", was published in September 2023 and supersedes Rev. 2 (3 June 2015); it lists DNP3 as "published as IEEE 1815" and cites IEEE Std 1815-2012 among IEEE Power and Energy Society standards.

How to segment and verify DNP3 in one checklist

When to use DNP3 versus IEC 60870-5-104, IEC 61850 and Modbus

Choose DNP3 for telemetry and control across wide area links where report by exception, time stamped events and buffered history matter, and where your utility, vendors and regulators already work in it. Choose IEC 60870-5-104 where your region and suppliers use the IEC 60870-5 family. Choose IEC 61850 for substation automation and modern DER plants where modelled data and engineering files pay off; IEEE 1815.1 exists precisely because many utilities run IEC 61850 inside the substation and DNP3 back to the control centre. Choose Modbus for simple devices inside a protected cell. Our Modbus deep dive covers its framing and the Modbus/TCP Security protocol, and our OPC UA deep dive covers the certificate based alternative used for plant to enterprise integration.

For TCP lifecycle details that apply to any of these over IP, see our TCP state machine post, and for what anyone on the path can read and change in a plaintext session, see TCP vs UDP: what an eavesdropper can see and change.

Common mistakes

• Treating the CRC as security. It catches noise on a radio channel. Anyone who can send a frame can compute it.
• Trusting the DNP3 source address. It is a number the sender writes. Firewall rules and Secure Authentication identify peers; addresses do not.
• Assuming "supports Secure Authentication" means "uses it". Check the traffic and the enforcement setting on each association.
• Leaving SAv5 Update Keys as installed at commissioning, shared across many outstations or stored in plain configuration exports.
• Assuming SAv5 encrypts. It authenticates. Point lists and values are visible on the path.
• Protecting controls but not data. Spoofed responses and unsolicited responses can mislead operators even when operate commands are authenticated.
• Forgetting the converter. A serial to IP gateway or cellular router exposes every serial outstation behind it.
• Writing conduit rules as "any to RTU subnet on 20000" instead of named masters per outstation.
• Patching outstations but not masters. The master parses input from every field device; its DNP3 stack needs the same version tracking.

FAQ

What port does DNP3 use?

IANA registers TCP and UDP port 20000 (service name dnp) for DNP3, plus SCTP 20000 since December 2022. Port 19999 is registered as dnp-sec, "Distributed Network Protocol - Secure". Devices can be configured to other ports, so confirm with your configuration and traffic.

Is DNP3 encrypted?

Classic DNP3 is not encrypted, and Secure Authentication version 5 in IEEE 1815-2012 authenticates messages without encrypting them. DNP3-SL, the DNP Users Group's implementation of IEC 62351-5:2023, adds optional authenticated encryption. Where encryption is needed today, it usually comes from the network, such as an IPsec or VPN tunnel between sites.

What is DNP3 Secure Authentication?

It is DNP3's built in message authentication. In SAv5, an outstation challenges critical requests such as controls, and the master proves knowledge of a shared session key by returning a MAC over the challenge and the request. The successor, DNP3-SL (formerly SAv6), authenticates every message and bases its keys on X.509 certificates.

What is the difference between a DNP3 master and an outstation?

The master, now often called the controlling station, is the control centre computer that polls for data and issues commands. Outstations are the field devices, such as RTUs and substation computers, that hold point data and carry out commands. A sub master can act as both.

What are DNP3 event classes and unsolicited responses?

Events are time stampable records of changes, and outstations sort them into classes 1, 2 and 3 so the master can poll for them selectively. An unsolicited response is an outstation reporting events without being polled, which speeds up notification but adds traffic and contention on shared channels.

DNP3 vs Modbus: what is the difference?

Modbus is a simple register read and write protocol, usually inside a plant. DNP3 adds time stamped events, classes, unsolicited reporting, richer data types and built in Secure Authentication, which suit utility SCADA over wide area links. Both are unauthenticated in their classic forms.

DNP3 vs IEC 60870-5-104: which should I use?

Both descend from the IEC TC57 telecontrol work and solve similar problems. DNP3 dominates in North America; IEC 60870-5-104 (TCP 2404) is common where the IEC 60870-5 family is the regional standard. IEC 62351-5 covers security for both families. Choose what your vendors, region and existing control centre support.

Is DNP3 safe to expose to the internet?

No. Classic DNP3 accepts commands from anyone who can reach it, and CISA's guidance is to remove OT connections to the public internet. Use private networks, VPNs with phishing resistant MFA for remote access, and conduit rules that admit only known masters.

Fix it without waiting for upstream

DNP3 bugs that matter to software teams usually live in a library or service you depend on: the DNP3 stack inside a SCADA master, a protocol gateway or a DER controller, or the TLS, VPN and Linux components underneath it.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not DNP3 traffic monitoring or changes to RTUs and masters. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image for a protocol gateway or a SCADA front end that speaks DNP3, the same scan lists the DNP3, TLS and Linux libraries inside with their versions and any known vulnerabilities, without the image leaving your machine.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a DNP3 or TLS library pinned in a gateway, historian connector or DER controller you build.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular DNP3 stack version, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 1815-2012, Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3)
• IEEE SA: IEEE 1815-2010
• IEEE SA: P1815 draft standard project
• DNP Users Group: Overview of DNP3 Protocol
• DNP Users Group: Features of DNP3
• DNP Users Group: A DNP3 Protocol Primer, Revision A, 20 March 2005 (PDF)
• DNP Users Group: Zero Trust in DNP3, white paper revision 3 (PDF)
• DNP Users Group: Two Page Summary, Next Gen DNP Security (PDF)
• DNP Users Group: Flyer, DNP Cybersecurity, DNP3-SL and AMP (PDF)
• DNP Users Group and MESA: IEEE 1815.2 press release, 5 February 2026 (PDF)
• DNP Users Group: Public Documents
• IEC Webstore: IEC 62351-5:2023
• IEC Webstore: IEC TS 62351-5:2013
• IEC Webstore: IEC 60870-5-104:2006
• IEC: IEC 61850 home
• IANA: Service Name and Transport Protocol Port Number Registry
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security, September 2023
• NIST SP 800-82 Rev. 3 full text (PDF)
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology, 6 May 2025
• Wireshark: Display Filter Reference, Distributed Network Protocol 3 (dnp3)
• Wireshark: tshark man page
• Wireshark: wireshark-filter man page
• tcpdump: tcpdump(1) man page
• tcpdump: pcap-filter(7) man page
• man7.org: ss(8)
• Microsoft Learn: Get-NetTCPConnection

Last reviewed: 23 October 2026. IEEE P1815 is in ballot and Secure Authentication support varies by product and firmware; check your vendor's documentation and the DNP Users Group for the current edition and DNP3-SL status.