There is a common claim in OT security circles that next generation firewalls cannot see industrial protocols. It is not true, and repeating it causes real harm, because it lets teams conclude the technology is useless when the actual problem is configuration.

The capability is extensive. Palo Alto publishes application identifiers covering roughly sixty industrial protocols, including Modbus, DNP3, Siemens S7 and S7-Comm-Plus, BACnet, PROFINET, OPC UA, IEC 60870-5-104 and IEC 61850. The granularity goes well beyond protocol identification: Modbus has fifteen function-level identifiers distinguishing operations such as read coils from write single register, DNP3 has thirty-three function-code variants, and BACnet has over eighty. Fortinet offers OT-specific intrusion prevention signatures through a FortiGuard subscription. The tooling can do the job. In most plants we assess, it is not being asked to.

What we actually find on site

Walk into a typical IT/OT boundary deployment and the firewall is a capable modern appliance running rules a 2005 appliance could have enforced. Four patterns recur.

  • Rules written at the base protocol. A rule permitting the Modbus application, rather than permitting read operations and denying writes. The fifteen function-level identifiers exist and go unused.
  • Any-any between zones. Often added during commissioning to get the plant running, then never tightened because nobody wants to be the person who breaks production.
  • The industrial signature subscription is not licensed or has lapsed. OT protocol coverage on several platforms is a paid add-on. If procurement bought the appliance and not the OT service, the industrial signatures are not there.
  • Inspection disabled for latency reasons. Someone measured jitter on deterministic traffic, got nervous, and turned deep inspection off across the board rather than selectively.

None of these are vendor failures. They are configuration and governance failures, which means they are fixable without buying anything. Our OT/IT network segmentation audit guide covers how we find them.

The limitation that is real: identification is not validation

A firewall can tell you that a packet is modbus-write-single-register, from this host, to that PLC. What it cannot tell you is whether writing that register, at this moment, in this process state, is safe. That judgment needs process knowledge the firewall does not have. This is the genuine conceptual limit of protocol inspection in OT, and no amount of signature coverage closes it. It is why inspection is a control, not a safety case.

 

Where coverage genuinely runs out

Being fair to the critics, there are real gaps. They are narrower than the usual claim but they matter:

  • Proprietary and vendor-specific extensions. Published application coverage is broad on standard protocols and thinner on vendor-specific variants and older proprietary traffic. Vendors note that new industrial identifiers are added on an ongoing basis, which is another way of saying coverage is still filling in.
  • Serial traffic bridged over Ethernet. Encapsulated or tunneled serial protocols are often not identified as the industrial protocol they carry.
  • Non-standard ports and legacy integrations. Identification usually works regardless of port, but misconfigured or heavily customized integrations can defeat it.
  • Anything encrypted without an inspection path. Increasingly common on newer OT protocols and a genuine blind spot.

Why one-way enforcement still matters

Everything above is about a bidirectional device making allow and deny decisions, which can be misconfigured, bypassed, or left permissive. For the highest consequence boundaries, that risk profile is the argument for hardware-enforced one-way transfer rather than better firewall rules. We cover that trade-off in detail in data diode versus firewall. The two are not competitors so much as controls for different consequence tiers.

What to do this quarter

  • Export your current rulebase and read it. Count the rules using function-level identifiers. In most plants the answer is zero, and that single number makes the case to management.
  • Confirm your industrial signature subscription is active. Check the license, not the brochure.
  • Baseline before you tighten. Run in monitor mode and learn what normal traffic looks like per conduit. Tightening without a baseline is how you stop production, and our guide to building an OT monitoring program covers that groundwork.
  • Tighten one conduit at a time, in a change window. Start with the lowest consequence path. Never the safety system.
  • Map rules to IEC 62443 zones and conduits. It gives you a defensible structure and an audit story. See our IEC 62443 guide.

Why Choose Arista Cyber

We are not a firewall reseller, so we have no interest in telling you the box is the answer or that it is useless. We assess what is actually configured on live plants, against the Purdue model and the 62443 zone structure, and we tighten rules in change windows without stopping production. See our case studies.

Next Steps

Start with the rulebase export. It takes an afternoon and it almost always reveals that you already own capability you are not using, which is a far easier conversation with a budget holder than asking for new hardware.

Common Questions

Can a next generation firewall really inspect Modbus and DNP3?

Yes. Palo Alto publishes fifteen function-level identifiers for Modbus and thirty-three function-code variants for DNP3, among roughly sixty industrial protocols. The capability is real. The common problem is that rules are not written to use it.

Do I need a separate license for OT protocol coverage?

On several platforms, yes. Fortinet delivers OT-specific intrusion prevention signatures through a FortiGuard subscription. Check your actual license state rather than assuming the appliance includes it.

Will deep packet inspection add latency to control traffic?

It can, which is why inspection should be applied selectively by conduit rather than enabled or disabled globally. Deterministic control traffic and enterprise reporting traffic do not need the same treatment.

Is a firewall enough at the IT/OT boundary?

It depends on consequence. For many boundaries a correctly configured firewall is proportionate. For the highest consequence paths, hardware-enforced one-way transfer removes the misconfiguration risk entirely.

Should I replace my IT firewall with an OT-specific appliance?

Not necessarily. In most assessments we find the existing platform has unused capability. Establish that first, because the configuration fix is cheaper and faster than a replacement project.

How many of your firewall rules use function-level inspection?

Arista Cyber audits OT firewall rulebases against the Purdue model and IEC 62443 zones and conduits, then tightens them in controlled change windows. No vendor affiliation, no hardware to sell.

Request a rulebase audit