OT Firewall Reviews: Five Checks Before Changing the Rules

An OT firewall review is not only about whether the appliance works. It is about whether the rules still reflect the access the process needs.

The starting point is to understand what each rule permits, why it exists and what depends on it. These five checks help structure that review.

1. Broad “any-to-any” rules

Look for rules that permit any source, any destination and any service.

They may have been created for commissioning, troubleshooting or a temporary test. Before changing them, identify which traffic currently depends on them and what narrower access would support the same requirement.

Review their position and scope within the rulebase. A broad permit rule can undermine the separation the network design was intended to provide.

2. Rules with no recent hits

A rule with no recorded hits is a candidate for investigation, not automatic deletion.

Check the observation period, when counters were reset and whether the usage data is complete. Counter behavior and visibility differ between firewall platforms, so confirm what the displayed number actually represents.

Then identify the rule owner and the process dependency. Some OT communication occurs only during maintenance, startup, shutdown, batch changes or emergency operation.

No recent traffic does not prove that the access is no longer required.

3. Temporary and vendor-access rules

A temporary rule needs an end condition.

Review its source, destination, service, permitted time window and owner. Confirm who can enable the access and whether the original work is complete.

The question is not simply whether a vendor still supports the system. It is whether this particular access path is still needed in its current form.

4. Direct IT-to-OT access

Identify paths that bypass the intended DMZ or controlled access route.

Pay particular attention to engineering workstations, HMIs, PLCs and remote-support systems. Each direct path needs a documented purpose and a review of whether the same requirement can be met through the intended architecture.

5. Engineering and administration access

Separate routine process communication from access that can change the system.

PLC programming, HMI administration, remote desktop, file transfer and vendor tools deserve particular attention. Review the permitted sources and destinations, available logging, rule ownership and next review date.

Make cleanup a sequence of controlled changes

Do not turn the review into a single bulk deletion.

Take one rule or a small related group. Confirm dependencies with the process owner, prepare a rollback and use an approved change window. Disabling a rule before deleting it can make recovery easier, but disabling is still an operational change.

Observe traffic and process behavior afterward. The evidence should cover the operating conditions that matter, including infrequent communication—not just a quiet period during normal production.

Remove the rule only when the review supports that decision. Then move to the next group.

Start with one rule: establish its purpose, check its dependencies and plan the change.