On 29 December 2025, attackers hit more than 30 wind and solar sites in Poland and a combined heat and power plant that serves close to half a million people. They did not need an exotic exploit. According to CERT Polska, they walked in through internet-exposed VPN devices, then went after the RTUs, protection relays, HMIs and serial device servers sitting at the grid connection points. Generation kept running. What broke was the link between the plants and the grid operator: monitoring, remote control, the eyes and hands of the control room. 

If you run a utility SCADA network, that should make you uncomfortable, and it should make you ask a specific question: what happens to the master-to-outstation channel when someone is already inside? For a large share of electric, water and gas operators, that channel runs on DNP3. 

This Blog covers the DNP3 security risks that matter in 2026, what has changed in the last twelve months, and a practical program for reducing exposure, written for CISOs and OT security leads who already know what a master station is. 

Key takeaways 

• DNP3 (IEEE 1815) was designed for reliability on slow, noisy links. Legacy deployments have no authentication, no encryption and no real integrity protection. 

• Most real-world incidents against utilities start at the edge (exposed VPNs, remote access, internet-facing devices) and only then reach the protocol layer. 

• Two 2026 CVEs affect the DNP3 parser in Suricata, a tool many teams use to watch OT traffic. Your monitoring stack is part of your attack surface. 

• DNP3 Secure Authentication v5 exists and works, but migration is slow. SAv6 and a new Authorization Management Protocol are in development. 

• NERC CIP-015 now pushes North American utilities toward monitoring traffic inside the security perimeter. FERC approved the revised CIP-015-2 on 10 August 2026. 

• You can cut DNP3 risk substantially without replacing a single RTU, if you inventory flows, remove exposure, segment hard and monitor function codes. 

What DNP3 is, and why utilities still run on it 

DNP3 (Distributed Network Protocol 3) carries data between a SCADA master and field devices: RTUs, IEDs, relays, recloser controllers. It was developed in the early 1990s and is now standardised as IEEE 1815. The DNP Users Group describes it as the most widely used protocol for electric transmission and distribution communications in North America, and it is also common in water and wastewater, transportation, and oil and gas. It is a named standard for distributed energy resource communications as well. 

The reasons it stuck are practical. It handles bad links well. It supports event buffering, so an outstation can report what happened while the master was unreachable. It supports class-based polling and unsolicited responses, which saves bandwidth. And there are decades of installed hardware that speaks it. 

It typically runs on TCP or UDP port 20000, or over serial links that are now often bridged onto IP through terminal servers and gateways. That bridging is where a lot of the trouble begins, because a protocol built for a dedicated serial circuit now sits on a routable network. 

Why DNP3 is risky: the design problem 

The protocol is not broken in the sense that a bug is broken. It is incomplete in the sense that security was never part of the job description. 

No authentication in the base protocol. A DNP3 outstation will generally act on a well-formed request from whoever sends it. If an attacker can reach the outstation and speak valid DNP3, there is nothing in the base protocol that asks who they are. 

No encryption. Everything crosses the wire in clear text, so point values, device attributes, configuration details and command sequences are all readable by anyone on the path. 

A CRC is not an integrity check. DNP3 link frames carry a 16-bit CRC on each block of up to 16 data bytes. That catches line noise. It does nothing against a deliberate attacker, who can modify a frame and recompute the CRC in the same step. 

Powerful function codes. Operate and direct operate trigger control actions. Cold restart and warm restart can take an outstation offline. Disable unsolicited can quietly blind the master to events. Write and file operations can change configuration. None of these are protected unless you add something on top. 

Long-lived, hard-to-patch endpoints. RTUs and relays run for 15 to 25 years. Firmware updates are rare, scheduled around outages, and sometimes unavailable from the vendor. 

The academic literature has described these as vulnerabilities by design for years. A 2022 IEEE paper, Risk Analysis of DNP3 Attacks, walks through the attack classes and how they map to risk in smart grid settings. 

DNP3 attack paths utilities should model 

Threat modelling DNP3 works better when you separate the protocol-level abuse from the paths that get an attacker to the protocol. 

The malformed-packet row deserves a closer look, because it is the one most teams underestimate. 

In 2013, researchers Adam Crain and Chris Sistrunk reported improper input validation across numerous DNP3 master and outstation software products, which led to a CISA (then ICS-CERT) advisory, ICSA-13-291-01B. Their point was that the flaw was in implementations rather than in the protocol specification itself. They found it with fuzzing tools, and they advised vendors to run extensive negative testing and advised asset owners to keep DNP3 traffic off business networks, using an IPS or firewall with DNP3-specific rules. Individual products got their own CVEs, for example CVE-2013-2790, an infinite loop in a master-station driver triggered by crafted packets to TCP port 20000. 

Thirteen years later, the same pattern is still showing up. More on that below. 

Latest developments (as of November 2026) 

1. The Poland attacks show where DNP3 environments actually get hit 

CERT Polska's incident report on the 29 December 2025 attacks is worth reading in full. The key facts, as reported by CERT Polska and summarised by outlets including Help Net Security and SecurityAffairs: 

• At least 30 wind and photovoltaic facilities were affected, along with a CHP plant and a manufacturing company. 

• In every case, initial access came through internet-exposed FortiGate devices acting as VPN concentrators and firewalls. At least one device had a configuration that had previously been stolen and posted on a criminal forum. 

• At the renewable sites, the attackers compromised RTU controllers, protection relays, HMI computers and serial device servers, including equipment from Hitachi Energy, Mikronika and Moxa. They uploaded corrupted firmware, deleted files and reset devices to factory settings. 

• Communication between the facilities and distribution system operators was lost. Electricity generation continued. 

• At the CHP plant, the intrusion had been going on for months. A custom wiper called DynoWiper was deployed through Group Policy, and an EDR platform blocked it. 

• CERT Polska linked the activity to a cluster it tracks as Static Tundra, associated with Russia's FSB Center 16. ESET assessed it as most likely the work of Sandworm. Attribution differs between vendors, but both point to Russia-linked actors. 

A fair caution: the public reporting does not say that DNP3 itself was the attack vector, and we are not claiming it was. The relevance is the target. Attackers went after the RTU and gateway layer that carries supervisory traffic between a remote site and the control room, and they got there through the edge. Anyone running DNP3 between distributed sites and a central master should read this as a description of their own threat model. 

2. Two 2026 CVEs hit the DNP3 parser in Suricata 

Suricata is a widely used open-source IDS/IPS and network security monitoring engine, and many OT teams use it for passive monitoring of DNP3. Two vulnerabilities this year affect its DNP3 parser: 

• CVE-2026-22259, published in January 2026, is an unbounded transaction growth issue that lets specially crafted DNP3 traffic drive up memory use and cause denial of service. It is rated CVSS 7.5. Fixed in Suricata 8.0.3 and 7.0.14. 

• CVE-2026-45765, published 10 September 2026, is an unbounded reassembly issue with the same end result: excessive memory consumption from crafted DNP3 traffic. Fixed in 7.0.16 and 8.0.5. 

In both cases the DNP3 parser is disabled by default, and the suggested workarounds are to disable it if you do not need it, or, for the second issue, to set a limited stream reassembly depth. If your team enabled DNP3 parsing for visibility, check your version today. The uncomfortable lesson is the one from 2013 again: parsers for industrial protocols are attack surface, including the parsers inside your defensive tools. 

3. Exposed OT devices are being actively exploited, and CISA has told operators to check for DNP3 

CISA, the FBI, NSA, EPA, DOE and partners published advisory AA26-097A on 7 April 2026 and expanded it on 22 July 2026. It describes Iranian-affiliated actors, tied to the CyberAv3ngers persona and IRGC-CEC, compromising internet-exposed PLCs, with Rockwell Automation devices named first and further vendors added in the update. The reported techniques include project file tampering and manipulation of data on HMI and SCADA systems. This is not a DNP3 story. It is the same exposure story: reachable devices, weak or default credentials, and a network path that should not exist. 

CISA's separate Internet Exposure Reduction Guidance goes further for protocol owners. It tells operators to scan their own address ranges for exposed OT services and lists DNP3 among the protocols and ports to look for, alongside Modbus, OPC UA, EtherNet/IP and BACnet. It also recommends routing necessary remote access through a centrally managed gateway with unique credentials and phishing-resistant MFA, not direct connections to an RTU or HMI. 

4. FrostyGoop showed what protocol-native malware can do to a legacy industrial protocol 

Dragos disclosed FrostyGoop in 2024: ICS malware that speaks Modbus TCP directly to controllers. It was linked to an attack on an energy company in Lviv, Ukraine, in January 2024 that cut heating to more than 600 apartment buildings for roughly two days. Initial access reportedly came through a vulnerable MikroTik router. 

FrostyGoop targeted Modbus, not DNP3. The comparison is ours, not Dragos's: both are legacy protocols without built-in authentication, so the same class of capability, reading and writing device registers with valid protocol messages, is conceptually available against unprotected DNP3 deployments. The Lviv case also shows how little the attacker needed: an exposed router and months of quiet access. 

5. The standard itself is moving: SAv6, AMP and a new IEEE 1815 revision 

The base standard has been through several iterations. IEEE 1815-2010 was superseded by IEEE 1815-2012, which introduced Secure Authentication version 5 (SAv5). The older SAv2 relied on pre-shared keys. SAv5 supports public key infrastructure and remote key changes, which matters a great deal operationally. An independent review during the development of SAv5 flagged several SAv2 features as potentially vulnerable. 

The DNP Users Group lists its current work as an update to IEEE 1815, Secure Authentication version 6, an Authorization Management Protocol (AMP), a DER communications standard (IEEE 1815.2, draft), new test procedures and an expanded conformance certification program. The group also announced a Utility Council, with a launch meeting on 21 May 2026, to tighten the feedback loop with utility members. If you buy DNP3 equipment, these are the items to ask vendors about. 

For migration planning, the EPRI guide DNP3 (IEEE Std 1815) Secure Authentication: Implementation and Migration Guide and Demonstration Report is still the most practical single reference. It covers 192 test scenarios, including coexistence of SAv2, SAv5 and non-secure environments, and key management. 

6. Regulation is shifting toward monitoring inside the perimeter 

FERC approved NERC CIP-015-1 (Internal Network Security Monitoring) in Order No. 907 in June 2025, and directed NERC to extend it to electronic access control or monitoring systems and physical access control systems. The revised CIP-015-2 was approved by FERC letter order on 10 August 2026, according to Dragos' analysis. The practical meaning for DNP3 operators in North America: east-west traffic inside your electronic security perimeter, including SCADA polling traffic, needs to be visible and monitored. Utilities elsewhere are not bound by CIP, but the logic transfers directly. 

How to reduce DNP3 security risk: a practical program 

You do not need to wait for a hardware refresh. These steps are ordered roughly by cost and impact. 

Step 1. Build a real inventory of DNP3 flows 

List every master, outstation, data concentrator, protocol gateway and serial-to-IP converter that speaks DNP3. For each one, record the source and destination, port, transport (TCP, UDP or serial), which function codes it actually uses, and who owns it. Passive network monitoring is the fastest way to get this, and it usually turns up flows nobody remembered: a vendor's maintenance connection, an old test master, a gateway bridging a legacy serial loop. 

Step 2. Remove exposure first 

Search your public IP ranges for port 20000 and for the other OT ports CISA lists. If any DNP3 outstation or gateway answers from the internet, treat it as an incident, not a ticket. Then fix the path: no direct inbound connections to RTUs, HMIs or gateways, and remote access only through a hardened, centrally managed entry point. 

Step 3. Harden the edge, because that is where attackers start 

The Poland case is a VPN story before it is an RTU story. Patch perimeter devices on a short clock. Enforce MFA on every VPN account with no exceptions for service accounts. Rotate credentials and review configurations after any vendor advisory, because stolen device configs can sit on criminal forums for months. Review what each remote user can actually reach once connected. Remote access should land in a jump zone, not on the SCADA network. 

Step 4. Segment and allow-list 

Place DNP3 traffic in defined conduits between zones, and write rules that permit only known master-to-outstation pairs on the expected port. If a DNP3 outstation never initiates connections to the internet or to corporate IT, make that a hard rule. Keep DNP3 networks away from the corporate firewall path, as the 2013 research advised. 

Step 5. Filter by function code, not just by port 

A port-based rule says "these two hosts may talk DNP3." A deep-packet-inspection rule says "this master may read and operate, but may not issue cold restart, warm restart, disable unsolicited or file transfer commands outside a maintenance window." Where your firewall or an inline OT security appliance supports DNP3 awareness, build an allow-list of function codes per master. Block or alert on the ones that can take a device offline or hide events. This is one of the highest-value controls you can add without touching the field device. 

Step 6. Deploy Secure Authentication where devices support it 

DNP3 Secure Authentication adds a challenge-response mechanism for critical operations, so an outstation can verify that a command really came from an authorised master and was not replayed. Plan for SAv5 over SAv2, because of PKI support and remote key management. Two cautions. First, authentication is not encryption: SA does not hide the data, so if confidentiality matters you still need a tunnel. Second, the hard part is key management and interoperability, not the protocol. Pilot with one vendor pair, test coexistence with non-secure devices as the EPRI work does, and write down who owns key rotation before you roll out. 

Step 7. Protect legacy endpoints that cannot be upgraded 

For RTUs that will never support SA, wrap them. Options include a bump-in-the-wire security gateway at the site, an IPsec or TLS tunnel between the master side and the remote site, or at minimum strict firewall policy plus monitoring. Document the exception, the compensating control and a retirement date. 

Step 8. Monitor the protocol, not only the network 

Baseline normal DNP3 behaviour: which masters poll, how often, which function codes, which object groups. Then alert on deviations such as: 

• a new source IP speaking DNP3 to an outstation 

• restart, stop application or disable unsolicited function codes outside change windows 

• operate commands outside scheduled switching activity 

• sudden spikes in unsolicited responses or event-buffer overflow indications 

• DNP3 on a segment where it has never appeared 

• repeated malformed frames or parser errors, which may point at fuzzing or exploitation attempts 

If you run Suricata or any other parser-based sensor, patch it (see the CVEs above), cap reassembly depth and treat sensor resource exhaustion as an alert condition in its own right. 

Step 9. Raise the bar on implementations 

The 2013 findings were about software quality, and the lesson holds. In procurement, ask vendors whether their DNP3 stack has been fuzz-tested, whether they hold DNP Users Group conformance certification, what their patch policy is for the protocol stack and when they will support SAv5 and later versions. Track advisories for the DNP3 libraries inside your products, since the same open or commercial stack often appears across several vendors. 

Step 10. Plan for loss of visibility and remote control 

The Poland attacks did not turn the lights off. They removed remote monitoring and control from distributed sites and left operators dealing with bricked devices. Prepare for that outcome. Keep offline copies of RTU configurations and known-good firmware. Test how fast you can restore a device to service. Rehearse manual or local operation of key substations, and agree in advance how you will operate if the SCADA link to a site disappears. 

A 90-day plan for security leaders 

Questions CISOs ask about DNP3 security 

Is DNP3 secure? Not by default. The base protocol has no authentication or encryption. DNP3 Secure Authentication adds authentication of critical commands, and tunnelling adds confidentiality, but both have to be deliberately deployed. 

What is the difference between DNP3 SAv2 and SAv5? SAv2 uses pre-shared keys. SAv5, introduced in IEEE 1815-2012, supports public key infrastructure and remote key changes, and was developed partly in response to concerns about SAv2 features. 

Which port does DNP3 use? Port 20000, on TCP or UDP, is the standard assignment. Any DNP3 service reachable from the internet on that port should be investigated immediately. 

Can an attacker use DNP3 to open a breaker? If an attacker can reach a legacy outstation that accepts control commands from unauthenticated sources, and speaks valid DNP3, then in principle yes. That is why network access control and function-code filtering matter so much. 

Do I need to replace my RTUs to be safe? No. Segmentation, exposure removal, remote access hardening, DPI filtering and monitoring reduce risk significantly on existing equipment. Replacement and SA adoption can follow on a longer timeline. 

Does NERC CIP cover DNP3? CIP does not name DNP3, but CIP-015 requires internal network security monitoring for high and medium impact BES cyber systems, which covers the traffic where DNP3 polling happens. FERC approved CIP-015-2 on 10 August 2026. 

Where Shieldworkz fits 

Shieldworkz is an end-to-end industrial OT cybersecurity company covering the stack that DNP3 environments need: assessment and architecture review, OT network visibility and monitoring, vulnerability and patch management built for operational constraints, and services to design and test the segmentation and response plans described above. If you are mapping your DNP3 estate, reviewing remote access paths or preparing for internal network monitoring requirements, the Shieldworkz team can help you go from inventory to a prioritised, deployable plan.