DPI-based command filtering uses deep packet inspection to enforce rules on the actual commands inside industrial traffic, not just on the connections carrying them. Because a protocol-aware firewall can read the Modbus function code or the DNP3 control function in a packet, it can make a decision no ordinary firewall can: allow a read to pass while blocking a write, stopping an unauthorized control command mid-stream even though it shares a connection with legitimate monitoring traffic. This turns a coarse allow-or-deny-the-connection control into a fine allow-reads-but-not-writes control. This page explains how command filtering works, what it can enforce, and why it is a powerful tool for protecting a control network without cutting off the visibility operators need.
DPI Command Filtering in one line: DPI-based command filtering is a firewall technique that inspects the payload of industrial protocol traffic and permits or blocks individual commands based on their function, rather than allowing or denying an entire connection. For Modbus and DNP3 this typically means allowing read function codes to pass while blocking write and control function codes, so a device can be monitored but not commanded. Because the firewall parses each packet's function code and drops disallowed commands mid-stream, it enforces a read-only policy on a live control link that a port-based firewall cannot express.
A traditional firewall decides at the level of the connection. It can allow or deny traffic between two hosts on a given port, so its finest control over a Modbus link is to permit the whole conversation or block it entirely. That is too blunt for a control network, because the same connection carries both the harmless reads that a monitoring system depends on and the writes that could change the physical process. Blocking the connection kills visibility, while allowing it permits every command, including the dangerous ones.
DPI-based command filtering breaks that all-or-nothing choice. Because deep packet inspection lets the firewall read the function code inside each packet, it can apply a rule to the specific command rather than to the connection. The classic policy is an allowlist of function codes: permit the read functions, such as reading holding registers or input registers in Modbus, and deny the write functions, such as writing a register or forcing a coil. The connection stays up and monitoring keeps working, but any packet carrying a disallowed command is dropped before it reaches the device.
The effect is a read-only enforcement point that still lets data flow. A supervisory system or a security monitor on the wrong side of the firewall can keep polling a controller for its values, while any attempt to command that controller, whether from an attacker, a compromised host, or a misconfigured tool, is stopped at the firewall. This is exactly the control an operator wants around a sensitive device: full visibility into what it is doing, with no ability for the monitored side to reach in and change it.
In Modbus the filter works on function codes. Read operations and write operations carry distinct function codes, so a policy can permit the reads while dropping the writes, and it can go finer still, allowing writes to some register ranges but not others, or blocking coil forcing while allowing register reads. This lets a plant express a rule like allow this monitoring host to read anything on this PLC but never write to it, enforced packet by packet, which a port-based firewall could never articulate because every Modbus packet looks the same to it.
DNP3 carries its own control semantics, and command filtering reads the DNP3 application-layer function to enforce them. It can allow the read and reporting functions that make up normal telemetry while blocking the direct-operate and control functions that actually actuate a point, and it can be aware of the select-before-operate sequence that DNP3 uses to guard control. Because DNP3 is used for real remote control of electric and water infrastructure, being able to permit telemetry while denying control commands at the protocol level is a meaningful protection for assets where an unauthorized operate could have physical consequences.
The enforcement is real-time and inline, which distinguishes it from passive monitoring. A passive sensor watching a copy of traffic can detect a bad command after it has already happened, but a command filter sits in the path and drops the disallowed packet before it reaches the device, so the command never executes at all. That inline position is what gives command filtering its teeth, and it is also what demands care, because a device that fails in the traffic path must be engineered so that a failure does not cut a control link that the process actually needs.
Command filtering shines at boundaries within a SCADA architecture where one side should observe but not control. A common placement is around a segment of especially sensitive controllers, letting a broader SCADA or historian network read their values for monitoring and reporting while denying it any ability to command them, so the sensitive devices are commanded only by their own local controllers and no one else. Another is at a link to a less-trusted zone, where you want to expose telemetry outward but never accept control inward.
The technique pairs naturally with a read-only monitoring posture. Where an organization wants a remote or centralized system to see everything a control network is doing while guaranteeing that system can change nothing, a command filter enforcing reads-only at the boundary provides that guarantee at the protocol level rather than relying on the remote system to behave. This is a stronger assurance than a policy or a configuration, because the filter physically drops any write regardless of what the upstream system intends or is tricked into sending.
For cloud-connected and centralized monitoring this matters because it lets an operator safely expose control-network data to systems outside the plant. A cloud SCADA or security platform such as Merobix can be given a rich, read-only view of a site's Modbus and DNP3 telemetry through a boundary that permits reads and blocks every write, so the remote platform gains full visibility while the command filter guarantees it can never reach back and actuate anything in the field. Filtering on the command rather than the connection is what lets visibility and control be separated cleanly, giving remote monitoring its reach without giving it its risk.
It inspects the payload of each packet with deep packet inspection and reads the protocol function code, which explicitly says whether the packet is a read or a write. The firewall then applies a rule to that specific command rather than to the whole connection, passing packets whose function code is on the allowlist and dropping those that are not. Because reads and writes carry different function codes, a read-only policy can let every read through while dropping every write, all on the same live connection.
No, they are opposite in one key way. Passive monitoring watches a copy of traffic and can only detect a bad command after it has already reached the device, sending nothing itself. Command filtering sits inline in the traffic path and actively drops a disallowed command before it reaches the device, so the command never executes. Filtering therefore prevents rather than merely detects, but because it is inline it must be engineered so that a failure does not cut a control link the process depends on.
Yes, if the filter supports address-level rules. Deep packet inspection reads not only the Modbus function code but also the register or coil address and the quantity involved, so a policy can be written to allow writes to some address ranges while blocking others, or to block coil forcing while permitting register reads. This lets a plant express fine-grained rules such as permitting a setpoint write within a safe range while denying writes to protected addresses, all enforced packet by packet.
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.