Why the Electric Grid's Control Protocol Still Trusts Every Command

A control center polls a remote terminal unit every few seconds. The RTU answers. This conversation has run, essentially unchanged, for three decades — and it was designed to be reliable and interoperable, not to ask “who are you?” before obeying a command.

DNP3 — Distributed Network Protocol 3 — is the language of North American electric utilities. It’s how a control center talks to substations, how an RTU reports a breaker opening, how a SCADA master raises a setpoint. It was built in 1993 by GE-Harris Canada (formerly Westronic), drawn from the partially completed IEC 60870-5 specification, to solve one specific problem: getting equipment from different vendors to interoperate reliably on the grid.

Reliability, it solved brilliantly. Security was never in the original brief — and that’s the problem worth understanding.

What DNP3 is, and why the grid depends on it

DNP3 is a layered protocol: a data link layer, a transport function, and an application layer that defines the functions and data types used across SCADA. It’s what lets a master station (the control center) poll remote terminal units (RTUs) and intelligent electronic devices (IEDs) at the substation — and lets those devices report events back.

What makes DNP3 more than a “better Modbus” is its data model. It organizes field data into objects and event classes:

Class 0 is the static, current state of every monitored point.
Classes 1, 2, and 3 hold buffered events at different priority levels.

On first contact, the master issues an integrity poll — a combined read of all classes. Then it settles into a rhythm: poll Class 1 events frequently, Classes 2 and 3 less often, Class 0 on a slower cycle. Outstations can also push data without being asked, through unsolicited responses. And every point carries a time-stamped variant, so the master can reconstruct a sequence of events even between polls.

That regularity is the key insight for detection — and we’ll return to it.

Why security wasn’t built in

For most of its life, DNP3 had no authentication and no encryption. A device that could reach the network and speak DNP3 was presumed to be a legitimate participant. This wasn’t negligence in 1993 — it was a design assumption. The threat model was equipment failure and electrical fault, not a network adversary. Serial links were point-to-point; the idea that someone would sit on the wire and inject commands wasn’t part of the calculus.

Over time, the community added security. Secure Authentication Version 5 (SAv5) was standardized in IEEE 1815-2012 — a challenge-response scheme that lets a master and outstation prove they hold shared keys, with PKI support for key changes. TLS is recommended for IP transport under IEC 62351-3, and DNP3’s secure authentication aligns with IEC 62351-5.

Here’s the reality on the ground: a great deal of deployed DNP3 still runs over serial or bare IP with no authentication at all. Brownfield substations are hard to touch, and retrofitting security onto a protocol never designed for it is expensive and risky. The gap between “the standard now supports authentication” and “the grid has authentication everywhere” is where the attack surface lives.

What makes a DNP3 attack hard to detect

This is the part that matters for defenders. The most dangerous DNP3 attacks don’t look like attacks — they look like the protocol doing its job.

DNP3 has two control models. The safe one is Select-Before-Operate (SBO): the master issues a Select, the outstation echoes back exactly what it’s about to do, the master confirms with an Operate. Two steps, one sanity check. The fast one is Direct Operate (function code 5): a single command that writes straight to an output — open a breaker, close a valve, raise a setpoint — with no select handshake.

Direct Operate is a legitimate, everyday command. It exists for speed and for points where the two-step dance is unnecessary. But it’s also the command an adversary would reach for first, because it acts immediately with no confirmation step to trip over.

And Direct Operate is only the beginning. A device that can speak DNP3 can:

Inject unsolicited responses that make a master believe a breaker opened when it didn’t — or didn’t when it did.
Issue time-synchronization commands to poison the event timestamps an investigator will later rely on to reconstruct an incident. Break the clock, and you break the sequence-of-events record.
Send a Cold Restart or Warm Restart to force an RTU to reinitialize at a critical moment.

None of these are exploits. They’re function codes in the specification. A signature-based detector looks at “function code 5, Direct Operate” and sees a valid, in-spec command — there’s nothing to match. The signature paradigm assumes attacks look different from normal traffic. On DNP3, the attack is normal traffic.

How do you detect an attack that uses valid commands?

The answer is to stop asking “is this command allowed?” and start asking “does this command belong here?”

DNP3 is — ironically for a protocol that makes attacks hard to spot — an ideal subject for behavioral detection, because its normal behavior is so stable:

Who talks to whom is fixed. A given outstation is polled by a specific master, on a specific link, from a specific source address. A Direct Operate arriving from an address that has never issued a control command before is a signal.
When commands happen is predictable. Control operations cluster around scheduled switching, maintenance windows, and human work hours. A Direct Operate at 3 a.m. from a silent source is a signal.
What gets commanded is bounded. An operator opens and closes a defined set of breakers and valves. A Direct Operate targeting a point that hasn’t been operated in a year is a signal.
The rhythm is regular. Poll intervals, unsolicited-response patterns, event-class cadence — these settle into a baseline that’s measurable.

None of these signals requires a signature for a “DNP3 attack,” because there’s no such thing to write. They require a baseline of what’s normal and the ability to notice when a valid command lands outside it. That’s the whole game: freeze the baseline, not the detection — the attack is still fully caught, but now it’s caught because it doesn’t fit, not because it matches a known pattern.

What should an operator do today?

The most useful moves are architectural, not tooling:

Know your DNP3 map. Which masters poll which outstations, on which links, with which source addresses. If you can’t draw that map, you can’t tell when it breaks.
Prefer Select-Before-Operate for safety-critical points, and reserve Direct Operate for the narrow set of points where it’s genuinely needed. Direct Operate is a privilege — treat it like one.
Protect the clock. Time-synchronization commands should come from one source and one source only. Poisoned timestamps are how attackers hide inside your own incident record.
Watch the control commands, not just the traffic. Breakers and setpoints matter more than packet counts. Detection should be oriented toward process impact, not network noise.
Segment and authenticate where you can — TLS per IEC 62351-3, secure authentication per IEC 62351-5 — even if rollout is phased.

The lesson of a trusting protocol

The lesson of DNP3 isn’t that the grid is broken. It’s that the grid runs on a protocol built for reliability — and the commands that keep it reliable are the same commands an adversary would use to disrupt it. That’s not a signature problem; it’s a baseline problem. And it’s exactly the problem Maigadi was built to solve.

Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.

Maigadi Networks provides passive, signature-less network detection and response for OT/ICS environments. We help electric utilities, water systems, and industrial operators see the commands that don’t belong — before they become incidents.