What is DPI (Deep Packet Inspection)?

DPI (Deep Packet Inspection) is a technique in which a network device such as a firewall, IDS or IPS examines not only the headers of a data packet (IP address and port) but also parses its contents, so that the protocol, the command and the data fields can be checked, logged or blocked. In industrial networks this means seeing not just that a workstation is talking to a PLC over Modbus TCP, but whether it is sending a read or a write command, and to which register. Because many OT protocols such as Modbus, DNP3 and S7 have no authentication or encryption, this content-level check is often the only way to recognise misuse of otherwise legitimate traffic.


🧠 How does DPI work?

A DPI engine processes each packet in a number of steps:

  1. Read the headers - like a classic firewall, DPI first looks at Layers 3 and 4 of the OSI model: source, destination, port and session state.
  2. Identify the protocol - the engine determines which application protocol the packet carries. It does not rely on the port number alone, because an attacker can run any protocol on any port.
  3. Parse the payload - a protocol decoder splits the message into fields: for Modbus the unit ID, function code, register address and value; for DNP3 the application function code and objects.
  4. Compare against policy - the fields are checked against rules (an allowlist), known attack patterns (signatures) or a learned profile of normal behaviour (anomaly detection).
  5. Act - allow, block, reset the connection or send an alert to a SIEM or security monitoring platform.

There are two main approaches. Signature-based DPI looks for known malicious patterns, such as an exploit for a specific firmware version. Protocol-specific DPI understands the grammar of the protocol and checks whether each message is valid and permitted. In OT the second form is usually the more valuable, because attacks there typically consist of valid commands with malicious intent.


πŸ” What is the difference between DPI and a traditional firewall?

Aspect Traditional (stateful) firewall DPI
Inspection level IP address, port, session state (Layers 3–4) Also protocol fields and commands (Layer 7)
Example rule ”Allow TCP 502 from HMI to PLC" "Allow Modbus function code 3 on registers 0–99, block writes”
Protocol-aware No Yes, per supported protocol
Detection of misuse Only from an unknown IP address or port Also an unusual command from a known system
Load and latency Low Higher; needs processing per packet
Encrypted traffic No difference Payload unreadable, only metadata visible

A classic firewall therefore cannot stop a compromised HMI that already has access to port 502 from sending a write command. DPI can. Protocol Filtering is the application of DPI in which these rules are enforced per protocol and per command.


🏭 Which industrial protocols can DPI inspect?

Protocol Default port What DPI checks
Modbus TCP TCP 502 Function codes 1–4 (read) versus 5, 6, 15 and 16 (write), register range, unit ID
DNP3 TCP/UDP 20000 Function codes such as READ, OPERATE, DIRECT OPERATE and COLD RESTART sent to RTUs
S7 (S7comm) TCP 102 Read and write requests, program download, CPU stop/start
OPC UA TCP 4840 Services such as Read, Write and Call, provided the session is not encrypted
IEC 60870-5-104 TCP 2404 Type IDs and commands sent to substations
IP (CIP) TCP 44818, UDP 2222 CIP services, configuration changes, firmware updates

Support varies widely between products. OT networking vendors such as Hirschmann (Belden), Moxa and Phoenix Contact supply an industrial firewall with DPI for a limited set of OT protocols. Open-source engines such as Zeek include Modbus and DNP3 decoders out of the box, and Suricata has rule keywords for Modbus, DNP3 and EtherNet/IP. Commercial NDR platforms from vendors including Nozomi, Claroty and Dragos parse dozens of industrial protocols.


πŸ” Why does DPI matter for OT security?

Well-known attacks show that the danger lies in the content, not in the connection:

  • Stuxnet manipulated Siemens PLCs over the S7 protocol, using valid commands from an infected engineering station.
  • Industroyer sent switching commands over IEC 60870-5-104 and IEC 61850 in Kyiv in December 2016 to open circuit breakers.
  • FrostyGoop used Modbus TCP in January 2024 to manipulate control equipment at a district heating company in Lviv, leaving around 600 apartment buildings without heating.

In each case a port-level firewall would have let the traffic through. DPI can recognise such commands and, when placed inline, block them. DPI also gives visibility of insider threats, misconfigured systems and the communication that precedes ransomware.

DPI fits within standards and legislation. IEC 62443-3-3, part of the IEC 62443 series, requires zone boundary protection (SR 5.2) and continuous monitoring (SR 6.2); DPI is a common way to implement both within the zones and conduits model. NIS2 and the Dutch Cyberbeveiligingswet, in force since 15 August 2026, do not prescribe DPI literally, but they do require appropriate measures for network security and incident detection.


πŸ”§ How do you deploy DPI in an OT network step by step?

  1. Map the communication - start passively: mirror traffic via a SPAN port or a network TAP and build an asset inventory and an overview of who talks to whom over which protocol. Tools such as Wireshark help with the analysis.
  2. Choose the position - place DPI on conduits between zones, for example between the DMZ and the control network, or directly in front of critical PLCs.
  3. Start in monitoring mode - let the DPI function log only for a few weeks, so you can see which commands occur in normal operation, including maintenance and batch changeovers.
  4. Define allowlist rules - for example, allow only reads from HMIs and historians, and allow writes and programming only from the engineering station.
  5. Switch gradually to blocking - per conduit, outside production peaks and with a fallback plan.
  6. Choose the failure behaviour deliberately - decide whether the device passes traffic when it fails (fail-open) or stops it (fail-closed). In OT, availability often takes priority.
  7. Connect to detection and response - forward alerts to a SIEM or OT SOC and review the rules after every process change.

⚠️ What are the limitations of DPI?

  • Encryption - with TLS or OPC UA in SignAndEncrypt mode the payload is unreadable; DPI then sees only metadata such as addresses, timing and message size. Content inspection then has to happen at the endpoint or through a trusted gateway.
  • Latency - inline DPI costs processing time per packet. For time-critical traffic such as PROFINET RT or motion control, DPI is therefore rarely placed inline; passive monitoring is more common there.
  • Unknown or proprietary protocols - without a decoder, DPI falls back to port filtering.
  • Management effort - rules have to evolve with the process; an overly strict rule can stop a production line.
  • No replacement for segmentation - DPI works best as one layer within defence in depth, together with network segmentation, access control, zero trust and central logging.

❓ Frequently asked questions

What does DPI stand for?

DPI stands for Deep Packet Inspection. It is a technique in which a firewall, IDS or IPS also parses the contents of network packets instead of looking only at the IP address and port. This allows DPI to decide per command whether traffic is permitted.

Is DPI the same as a next-generation firewall?

No. DPI is a technique; a next-generation firewall is a product that uses DPI, often combined with application identification and IPS. For OT, what matters most is whether the product can genuinely parse industrial protocols such as Modbus, DNP3 and S7.

Can DPI inspect encrypted OT traffic?

DPI cannot read the content of encrypted traffic, such as OPC UA with SignAndEncrypt or TLS, without the keys. The engine then sees only metadata such as addresses, timing and message size. In that case content checks have to take place at the endpoint or in a trusted gateway.

Does DPI slow down the industrial network?

Inline DPI adds processing time to every packet, and how much depends on the device and the number of rules. For most SCADA and HMI traffic this is not a problem, but for time-critical real-time protocols organisations often choose passive DPI via a SPAN port or TAP. Always test the latency before commissioning.

What is the difference between passive and inline DPI?

Passive DPI analyses a copy of the traffic and can only raise alerts, without any risk to process communication. Inline DPI sits in the data path, usually in an industrial firewall or IPS, and can actually block commands. Many organisations start passively and switch to inline zone by zone.

Which standard requires DPI in OT?

No standard prescribes DPI literally, but IEC 62443-3-3 requires zone boundary protection (SR 5.2) and continuous monitoring (SR 6.2). DPI is a common way to meet those requirements. NIS2 and the Dutch Cyberbeveiligingswet also require appropriate network security, for which DPI is a suitable measure.


πŸ“Œ In summary

Deep Packet Inspection makes OT traffic controllable down to the protocol and command level, so that a write command to a PLC is treated differently from a read request. Deploy DPI passively first to learn normal behaviour, then enforce allowlist rules per conduit and combine it with segmentation, monitoring and compliance with IEC 62443 for robust industrial cybersecurity.