Insecure OT Protocols: Why Modbus and DNP3 Need Network-Level Protection

01Key takeaways

1. 01

   Common industrial protocols such as Modbus and DNP3 lack authentication and encryption by design.

2. 02

   A device that can reach a controller speaking these protocols can usually read and command it.

3. 03

   These protocols cannot simply be replaced, because they are embedded in long-lived equipment.

4. 04

   Protection therefore comes from the network: segmentation, reduced reachability and monitoring.

5. 05

   Secure protocol variants exist but adoption is slow and partial, so network-level controls remain essential.

02Why industrial protocols lack security

Protocols like Modbus and DNP3 were created for a world of isolated, trusted networks, where the only devices that could communicate were the ones an engineer had physically connected. In that world, authentication and encryption seemed unnecessary overhead.

Modbus, one of the most widely used, simply carries function codes and data with no notion of identity. DNP3 added features for the demands of utilities but, in its original form, likewise lacked built-in security. They were designed to be reliable and simple, and they succeeded, which is why they are everywhere.

These protocols are not broken; they are doing exactly what they were designed to do in a world that no longer exists.

03What no authentication or encryption means

The absence of authentication and encryption has direct, serious consequences for any network an attacker can reach.

• Any device that can reach a controller can issue commands, because identity is not checked.
• Traffic can be read in transit, exposing process information.
• Traffic can be modified or spoofed, because integrity is not protected.
• Engineering and control functions are available to anyone on the network path.
• There is no protocol-level way to tell a legitimate command from a malicious one.

In short, for these protocols, being able to reach a device is close to being able to control it. That single fact drives the entire defensive approach.

04Why you cannot just replace them

The obvious answer, replace insecure protocols with secure ones, runs into the reality of OT. These protocols are implemented in countless field devices, controllers and systems that were installed years or decades ago and are expected to keep running.

• Devices have long lifecycles and are rarely replaced for security alone.
• Changing protocols can require replacing or reconfiguring large amounts of equipment.
• Vendor support and interoperability constrain what can be changed.
• Downtime to make such changes is costly and operationally sensitive.

Wholesale replacement is rarely feasible, so the insecure protocols remain, and the security has to be added around them rather than within them.

05Network-level protection

If a protocol trusts anything that can reach it, then controlling what can reach it is the protection. This is why industrial communication security is fundamentally a network discipline.

• Segment networks so only authorized systems share a segment with controllers.
• Reduce reachability so devices are reachable only by what genuinely needs them, and only when needed.
• Use one-way paths where the flow is publication, removing the ability to send commands back.
• Monitor industrial traffic to detect unexpected commands or sources.

Because the protocol cannot defend itself, removing unnecessary reachability is especially valuable. An AIRGAPNET controlled connectivity pattern can keep segments that speak these protocols disconnected by default and reachable only for approved windows, so an unauthenticated protocol is simply not exposed to attackers most of the time.

06Secure variants and their limits

Secure versions of some protocols exist, such as authenticated variants of DNP3 and secure profiles for others, and they are worth adopting where possible. They add authentication and integrity that address the root problem directly.

But adoption is slow and partial. Many devices do not support the secure variants, mixed environments must support the old and new together, and upgrades face the same lifecycle constraints as any OT change. Secure protocols are part of the long-term answer, not a substitute for network-level controls today.

07Closing thought

Insecure industrial protocols are one of the defining realities of OT security. They cannot be wished away, replaced quickly, or trusted to defend themselves, because they were never built to. Pretending otherwise leads to defenses that do not match the threat.

Accept the protocols as they are and put the security in the network around them. Segment, reduce reachability, prefer one-way flows where you can, and monitor. When a protocol trusts whatever reaches it, controlling what reaches it is the whole game.

FAQFrequently asked questions

SRCSources of record