Specifying an NGFW for the IT/OT Boundary: 12 Questions to Ask Vendors

Most firewall comparisons are written by people selling firewalls. The result is a feature matrix where the author happens to lead on every row. If you are specifying a firewall for an industrial boundary, a feature matrix is the wrong tool anyway, because the features are broadly similar across the serious platforms and the differences that will hurt you show up in operation rather than on a datasheet.

We do not sell firewalls. What follows is the question set we use when helping clients specify one for a Level 3 or Level 3.5 boundary, in the order that matters. Our guide to the Purdue model explains the boundary this sits on.

Before you talk to any vendor

Three answers you need first, because without them every vendor conversation is theater:

• What traffic actually crosses this boundary today. Not what the design document says. What a monitoring period shows. This is the single most common missing input.
• What the consequence of failure is. A boundary protecting a safety instrumented system and one protecting a historian warrant different answers on availability and on whether a firewall is the right control at all.
• Who will operate it in three years. An appliance your team cannot administer is a future any-any rule.

The twelve questions

Protocol and inspection depth

• 1. Which of our specific industrial protocols do you identify, and at what granularity? Ask for function-code level, not protocol level. Make them name the protocols on your asset list.
• 2. Is industrial protocol coverage included in the base license or is it a separate subscription? Get the answer in writing, with renewal cost.
• 3. How do you handle serial protocols tunneled over Ethernet, and encrypted OT traffic where we cannot provide an inspection path?

Availability and failure behavior

• 4. What is the failure mode, and is it configurable per policy? Fail-open preserves production and loses the control. Fail-closed preserves the control and may stop the plant. You need to choose deliberately, per conduit.
• 5. What is the measured latency and jitter under inspection for our traffic profile? Ask for numbers against deterministic control traffic, not aggregate throughput marketing figures.
• 6. How long does a software upgrade take, and does it require a traffic interruption? In a plant with an annual outage window, a platform needing quarterly disruptive patching is the wrong platform.

Operations and change

• 7. Can we run new rules in monitor mode before enforcing them? If not, every tightening is a gamble on production.
• 8. What does the rule change audit trail look like, and can it satisfy an IEC 62443 or NERC CIP evidence request?
• 9. Can policy be expressed in terms of zones and conduits rather than only addresses and ports? This matters more than it sounds, because it is what makes your rulebase reviewable by an engineer two years from now.

Environment and lifecycle

• 10. What are the environmental ratings, and do you have a hardened or DIN-rail variant for cabinet installation? Temperature, vibration and conformal coating, if the device is going anywhere near the process.
• 11. What is the published support lifetime for this specific model, and what is your end-of-sale notice period? OT assets live fifteen to twenty years. Most firewalls do not.
• 12. Who provides local support, and what is the realistic response time to our site? Not the SLA. The honest answer for a plant in Sarnia or Fort McMurray at 3am.

What not to evaluate on

Aggregate throughput is close to meaningless at an IT/OT boundary, where traffic volumes are usually modest and the constraint is determinism rather than bandwidth. Signature counts are a marketing metric. And the number of protocols supported matters far less than whether your protocols are supported at the granularity you intend to enforce. A platform covering sixty protocols poorly is worse than one covering your eight precisely.

Where a firewall is not the answer

Worth stating plainly in a post about buying one. For the highest consequence boundaries, particularly outbound-only data flows from a safety or critical control zone, hardware-enforced one-way transfer removes the entire class of misconfiguration and bypass risk that a bidirectional policy device carries. We compare the two in data diode versus firewall. Specify the control to the consequence, not to the convention.

Why Choose Arista Cyber

We have no vendor affiliation and no hardware margin, so our specification work is about what your boundary needs rather than what we stock. We assess the traffic first, define the zones and conduits to IEC 62443, and then help you choose. See our OT cybersecurity services and our case studies.

Next Steps

Run a monitoring period before you shortlist. Knowing exactly what crosses your boundary changes which questions matter and usually shrinks the requirement. Teams that specify from real traffic data buy less firewall and get more control.

Common Questions

Which next generation firewall is best for OT?

There is no single answer, which is why this post is a question set rather than a ranking. The right platform depends on your protocols, your consequence tiers, your outage windows and who will operate it. Any article naming a winner without knowing those is selling something.

Do I need an OT-specific firewall or will an enterprise model do?

Both are deployed successfully. The deciding factors are environmental requirements if the device sits near the process, failure mode configurability, and whether industrial protocol coverage at your required granularity is included or an add-on.

Should the firewall fail open or fail closed?

It depends on the conduit. A path carrying safety-relevant traffic and a path carrying historian data to the enterprise warrant different decisions. Insist the platform lets you choose per policy rather than globally.

How important is throughput at the IT/OT boundary?

Much less than vendors suggest. Volumes are usually modest. Latency and jitter under inspection matter far more for deterministic traffic.

Can one firewall cover all our Purdue levels?

Architecturally possible, operationally risky. A single device enforcing every boundary becomes a single point of failure and a single point of misconfiguration. Most mature designs separate the enterprise boundary from the control boundary.