Deep packet inspection, or DPI, is the practice of reading all the way into a packet's payload rather than stopping at the headers that route it. For industrial protocols this is what turns a security tool from something that only sees that two devices are talking into something that sees exactly what they are saying: which function code was invoked, which register was written, what setpoint changed. A firewall that only reads IP addresses and ports has no idea whether a Modbus connection is harmlessly reading a value or dangerously commanding an output, because both look identical at that level. This page explains how DPI parses the payload of protocols like Modbus, DNP3, and EtherNet/IP to give security tools command-level visibility that header-only inspection can never reach.
DPI of Industrial Protocols in one line: Deep packet inspection is the analysis of a packet's full payload, not just its routing headers, so a tool can understand the actual content of the communication. Applied to industrial protocols, DPI parses the Modbus, DNP3, or EtherNet/IP data inside the packet to see the specific function codes, register or coil addresses, values written, and setpoint changes being exchanged. This gives security tools command-level visibility, such as distinguishing a read from a write, that a traditional firewall reading only IP addresses and ports cannot achieve.
Every packet on an industrial Ethernet network is layered. The outer headers carry the addressing that gets the packet from one device to another, the IP addresses and the TCP or UDP ports, and a traditional firewall reads exactly that far. It can decide whether host A is allowed to reach host B on port 502, and nothing more. What it cannot see is what host A is actually asking host B to do, because that request lives deeper in the packet, inside the payload that the header-only view treats as an opaque blob.
Deep packet inspection keeps reading. It parses the application-layer payload using a protocol dissector, a component that knows the structure of a specific industrial protocol and can decode its fields. For Modbus that means reading the function code, the starting address, and the quantity or values; for DNP3 it means parsing the application-layer objects and function codes; for EtherNet/IP and its CIP messaging it means decoding the service being requested on a particular object. The dissector turns raw payload bytes into meaningful terms: not just a packet on port 502, but a request to write coils at a given address.
This deeper reading is what elevates a tool from connection-aware to command-aware. Two Modbus packets between the same two devices on the same port can be a benign poll for a sensor value or an unauthorized command to force an output, and at the header level they are indistinguishable. DPI reads the function code and tells them apart, which is the whole point. Without it, a security tool is limited to reasoning about who is talking; with it, the tool can reason about what they are actually doing to the process.
In Modbus, DPI reads the function code that defines the operation and the data that parameterizes it. It can distinguish a read of holding registers or input registers from a write to a single register, a write to multiple registers, or a coil write that toggles a digital output, and it can see the exact register or coil addresses and the values involved. That granularity means a monitoring tool can report that a particular device wrote a specific value to a specific register, which is often the difference between observing normal supervisory reads and catching a command that changes the physical process.
DNP3, common in electric utilities and water systems, carries richer structure, and DPI parses its application-layer function codes and data objects to see operations like reading points, issuing a direct operate to control a point, or handling the select-before-operate sequence that guards control actions. Because DNP3 is used for genuine remote control of the grid and of water infrastructure, seeing the actual control functions inside the traffic, rather than just that a DNP3 session exists, is what lets a tool recognize an unauthorized control command amid ordinary telemetry.
EtherNet/IP with CIP is object-oriented, and DPI decodes the service and the object a message targets, distinguishing routine data exchange from configuration changes or commands that alter a controller's state. Across all three protocols the common theme is that the security-relevant meaning, whether this is a read or a command, a data exchange or a configuration change, lives in the payload and only becomes visible through inspection. DPI is the mechanism that surfaces the setpoint change, the output command, and the firmware or configuration action that a process owner most needs to know about.
This payload-level visibility is what makes DPI so valuable for monitoring a SCADA environment. SCADA traffic is a continuous stream of reads and occasional writes flowing between masters and field devices, and the writes, the commands that actually change the process, are the ones that matter most for both safety and security. DPI lets a passive sensor watch that stream and pick out every command-class message, so a monitoring platform can distinguish the vast majority of harmless supervisory reads from the rare, consequential writes and flag the latter for scrutiny.
It also feeds better detection and better records. A behavioral baseline becomes far more precise when it is built from function codes rather than just connections, because the model can learn that a given device normally only reads and treat any write from it as an anomaly. Forensic records become far more useful when they capture not just that two devices communicated but exactly which registers were written and to what values, so an investigator can reconstruct what an attacker or a faulty device actually did to the process rather than merely that traffic occurred.
For centralized and cloud-based monitoring this command-level detail is what makes remote security meaningful. A platform such as Merobix receiving DPI-parsed events from many sites can present not just a map of which devices talk to which, but a feed of the actual control actions happening across a fleet, so an off-hours setpoint change at a distant, unattended site becomes a visible, alertable event rather than an invisible packet buried in normal traffic. Reading past the header is ultimately what lets a remote operator see the process being commanded, which is the visibility a firewall's address-and-port view can never provide.
A traditional firewall reads only the packet headers, meaning the IP addresses and ports, so it can decide whether one host may reach another on a given port but has no idea what they are actually saying. Deep packet inspection reads into the payload beyond those headers and parses the industrial protocol inside, so it can see the specific function codes, register writes, and setpoint changes. That is the difference between knowing two devices are talking and knowing exactly what command one is sending the other.
Yes, and that distinction is one of the main reasons to use it. DPI parses the Modbus function code inside the payload, which explicitly defines the operation, so it can tell a read of registers or coils apart from a write that changes an output or a value. At the header level the two are indistinguishable because both are simply traffic on port 502, so only by reading the function code can a security tool separate harmless supervisory reads from commands that alter the physical process.
Not for monitoring. DPI describes how deeply a tool parses each packet, not where the tool sits, so a passive sensor receiving a copy of traffic from a mirror port or a TAP can perform full DPI on that copy without ever being inline. Sitting inline is only required when a tool intends to block or filter traffic in real time based on what its inspection finds, which is a separate enforcement decision from the inspection itself.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.