Industrial Firewall Selection for Factory OT: RFP, FAT and SAT

An industrial firewall cannot be chosen by comparing headline throughput and port counts alone. A suitable device must preserve essential PLC and HMI traffic, enforce a useful boundary and behave predictably during a fault. This guide helps factory teams in Thailand and Southeast Asia move from requirements and product comparison to an RFP, factory acceptance testing (FAT) and site acceptance testing (SAT).

Start with traffic paths and production constraints

Before procurement, agree on five things: the assets and boundary to protect; the traffic allowed across it; what may and may not stop during a fault; who will review logs; and what constitutes acceptance at the site. An “industrial grade” label or a reference to IEC 62443 is not a substitute for this work. A firewall with a broad permanent allow rule provides little useful segmentation.

NIST SP 800-82 Rev. 3 treats security alongside OT performance, reliability and safety. ISA/IEC 62443-3-2 addresses system boundaries, risk assessment, zones and conduits. CISA recommends segmentation at the IT/OT boundary and, where appropriate, between functional areas of the OT environment. The practical order is therefore to map required communications before comparing appliances. Applying a standards-based design and holding a particular product certification are separate matters; verify any certification claim for the exact model and scope.

Where should a factory OT firewall sit?

The IT/OT boundary may not be the only boundary

A useful starting model contains enterprise IT, an industrial DMZ, the plant OT network, production lines or cells, and PLCs and HMIs. The placement of a historian, data gateway, remote maintenance workstation and MES interface determines the flows needed across these layers. CISA’s segmentation guidance illustrates a DMZ and controlled access between IT and OT. One device at that boundary cannot stop movement between two lines already sharing an unrestricted OT network.

Decide whether to separate cells by examining the consequence of an incident spreading, vendor maintenance access, shared servers and equipment changes. A central HMI server used by several lines must still communicate with them. Two independent lines that need no PLC-to-PLC traffic may be suitable for separate zones. Check the physical paths as well as VLANs: a VLAN boundary offers little control when an alternate router freely connects the same networks.

Use a zone and conduit diagram as the common procurement document

A zone groups assets with similar security requirements; a conduit describes communication between zones. Show device names, addresses or subnets, switches, gateways, traffic direction, management paths, external links and backup paths. If a safety instrumented function or emergency-stop system is networked, involve the equipment supplier and safety owner in assessing any effect. Choose a firewall position that every relevant flow actually crosses, has no uncontrolled bypass, and can be rolled back during maintenance.

“PLC to HMI” is too vague. An HMI may initiate a read request to a PLC, which then replies. The MES might connect to a PLC directly or receive data from a historian. Record initiator and destination, purpose, operating window and owner of each flow. This makes competing quotations comparable.

Build the PLC network segmentation traffic register

Discover allowed flows from actual operation

Existing drawings and configurations rarely describe all traffic. Collect vendor protocol specifications and observe traffic passively through a mirror port or existing monitoring. Include production, startup, changeovers, batch completion, backup and maintenance. A register based only on a normal shift may miss an occasional recipe transfer or licence check. Assess active scanning with the equipment vendor before using it on control assets.

For every flow record source and destination, direction, protocol and port, purpose, trigger, tolerated delay, effect of interruption and responsible owner. Add separate rows for DNS, NTP, authentication, monitoring, logging and firmware updates. Record fixed and dynamic addressing, multicast, broadcast and redundant paths. Missing management flows may not fail on the first day but can prevent the next maintenance operation.

Default deny needs a managed transition

The target rule set should explicitly allow required traffic and deny everything else at the end. CISA’s defense-in-depth guidance describes the same principle and warns against an any-to-any final rule. On a legacy line, immediately blocking every unobserved flow can disrupt production. Document an observation period, temporary rules, progressive tightening, monitoring and rollback criteria before cutover.

Treat a vendor’s temporary access as an exception linked to a named owner, target, work window, approval reference and expiry. Give every rule an owner and review date. Otherwise temporary allowances accumulate. Where several suppliers service the same PLC, assess individual identities and auditable destinations instead of a shared account or unrestricted shared VPN.

Seven criteria for comparing industrial firewalls

1. Bridge mode, routing and NAT

A transparent bridge may fit a legacy line whose addresses cannot change, but “transparent” does not guarantee every layer-2 protocol passes. A routed boundary is clearer but may require gateway, static-route and return-route changes. NAT can help connect machines shipped with overlapping fixed address ranges. It does not replace a firewall policy. Translation can complicate asset-to-log correlation and affect applications that embed addresses or rely on discovery traffic.

Ask for the exact supported forms of static one-to-one mapping, port translation, bidirectional flows, same-subnet handling, VPN interaction, rule order and logging of original and translated addresses. Siemens documents bridge/routed operation and NAT/NAPT on certain industrial models, but capabilities vary by model and firmware. Validate them against current manuals and a sample configuration.

2. Performance under the intended rule set

Published throughput depends on packet size, encryption, inspection functions, logging and concurrent sessions. Cyclic traffic needs attention to latency, jitter, bursts and retransmissions, not only average bandwidth. Include video, backup and data collection in the peak-load case if they share the boundary. Ask suppliers for measurements with the proposed rule count, logging, VPN and protocol inspection enabled.

Define allowable delay and recovery from the actual control process and vendor specifications; there is no universal value for every line. If the appliance cannot handle a time-critical flow, reconsider its placement before simply buying a larger model. Do not insert inline filtering into a safety or time-critical control loop without equipment-supplier and plant validation.

3. Visibility into industrial protocols

“Supports Modbus” or “supports PROFINET” can mean port forwarding, protocol identification, command-level filtering or anomaly detection. Request a feature matrix for the actual PLC, firmware and communication mode. Identify what becomes invisible when traffic is encrypted. Aggressive inspection can block legitimate operation; move from observation to alerts and then enforcement with process-specific acceptance tests.

4. Redundancy and failure behaviour

Dual power inputs, standby appliances, path failover, state synchronisation and a hardware bypass are different features. Siemens describes VRRP and firewall state synchronisation on some models. Palo Alto Networks explains that fail-open bypass on supported ports may keep traffic flowing after power or operating-system failure but bypasses configured policies; the same mechanism does not cover every soft reboot or maintenance mode. Traffic continuity and continued filtering are distinct acceptance criteria.

Write separate scenarios for power loss, port loss, a failed peer, a bad configuration, firmware update, log-server failure and loss of time synchronisation. For each, specify the expected PLC/HMI behaviour, unauthorised traffic handling, alarm, recovery time and manual authority. Avoid the ambiguous term “fail safe” in an RFP. Ask whether packets pass or are blocked in each stated fault.

5. Logs, time and response ownership

Denied-flow logs reveal missing rules during commissioning. Logging every packet indefinitely can overwhelm the appliance or collector. Decide which allowed and denied flows, administrative actions, configuration changes, VPN sessions, faults and failovers must be retained. Synchronise clocks and retain enough asset, zone and pre/post-NAT address information to investigate events. Agree on syslog transfer, secure transport, retention and behaviour during collector failure.

An alarm is useful only when someone is assigned to review and act on it. Separate production-critical events from planned maintenance and low-priority scanning. If logs feed an IT SOC, explain OT’s cyclic behaviour and production constraints so an automated IT response does not disrupt control.

6. Support life and local service

Compare firmware support periods, vulnerability notifications, patch availability, spare stock, configuration backup, licence renewal and on-site replacement time. A production machine may outlive the firewall generation. Specify end-of-sale/end-of-support notice, migration to a successor model, support language and hours in the procurement package.

At a Thai plant, define the boundaries among headquarters IT, local maintenance, the machine supplier and the network contractor. Name the policy approver, the owner of the outage window and the person who will attend a fault on site. Provide operating and recovery instructions in a language the local team can use.

7. Total cost and scaling

Include engineering, cabling, power, optics, licences, management servers, log storage, spare units, FAT, SAT, training and periodic policy reviews as well as the appliance price. A redundant firewall pair does not remove single points of failure in switches or power supplies. For future lines, consider operational review load as well as spare ports and rule capacity.

What to put in the factory OT firewall RFP

Compare three practical deployment patterns

The first pattern uses an industrial DMZ between IT and OT and controls its entry and exit. It is clear for equipment data sent toward enterprise systems, but internal OT traffic still needs separate consideration. The second places a smaller appliance at each line or cell entrance. This can narrow vendor maintenance paths and PLC reachability, but increases device count and policy work. The third protects only aggregation points for critical flows while retaining other existing segmentation. It may need fewer devices, yet the team must prove from wiring and observation that all relevant paths really cross those points.

No pattern is universally correct. On an existing line, the ability to insert a device without changing IP addresses may dominate the design. A new line offers more freedom to define subnets and gateways for a routed boundary. If several machine suppliers deliver overlapping fixed address ranges, machine-level NAT may be useful, but the addresses seen from maintenance workstations and upstream servers must remain unambiguous. An unmonitored alternate path defeats every pattern. Ask bidders to show wiring changes, outage duration, device count, administrative load and residual risk for each viable pattern.

Handle unknown traffic on legacy machines explicitly

Older machines may have outdated supplier specifications and no experienced owner on site. Do not go live with guessed ports. Review the production calendar and observe passively through a product change, batch completion, weekly backup and remote service event where possible. Mark an unresolved flow as “purpose not yet confirmed” and give its temporary allowance an owner, monitoring method, deadline and next review date. A time-limited investigation differs from a permanent broad permit.

Do not identify a machine from the observed source IP alone. NAT and stale inventories can make the visible address misleading. Cross-check switch port, MAC address, control-cabinet wiring, equipment number and operator records. If a cross-line flow appears, determine whether it serves quality data, a shared HMI, an interlock or a protective system before blocking it. Enter understood traffic in the formal register; identify unresolved traffic as a SAT follow-up with a responsible person.

Make the comparison sheet useful after procurement

Write each comparison row as an observable outcome rather than a sales phrase. “Advanced security” cannot be accepted or rejected. “The specified PLC/HMI flow passes, the same port from another line is denied, and both outcomes appear in time-stamped logs” can be reused in the RFP, FAT, SAT and operating procedure. Mark evidence as documentation, laboratory measurement, site measurement or unverified. A catalogue claim is not a successful site test.

Keep separate columns for “feature exists” and “works in our topology”. NAT may be present yet incompatible with the required protocol or overlapping addresses. Redundancy may exist but interrupt an HMI longer than the process permits. Syslog may exist but omit the original and translated addresses needed for investigation. Compare final prices only among candidates that satisfy mandatory operating conditions.

Give all bidders the same testable brief

Include the asset scope, current network diagram, traffic register, candidate position, allowable outage, required redundancy, maintenance responsibilities and acceptance plan. Control distribution and versions of sensitive network diagrams. Have bidders distinguish standard capability, extra licence, custom integration, unsupported requirement and alternative design. This makes the implementation difference visible behind a headline price.

Ask explicitly: Can all specified flows pass? What are the limits of bridge, route and NAT modes? Under what conditions were performance figures measured? What happens to traffic and policy during power loss, restart or failover? How are changes approved, compared and rolled back? How do logs reach the current monitoring system? Who supplies and witnesses FAT/SAT equipment? How are vulnerability notices and patch outages handled?

Separate mandatory requirements from scoring criteria

A low price should not compensate for failure of a mandatory production requirement. Mandatory items may include the required interfaces and temperature range, redundancy, log forwarding, address compatibility and local support. Award extra points only for features the team can actually operate, such as rule visibility or backup automation. State the required outcome rather than copying a vendor’s feature name.

Turn each RFP line into a FAT case

A supplier’s “compliant” answer is not a test. Link each requirement to prerequisites, an action, observation point, pass criterion and evidence. For time-limited maintenance access, test an approved workstation during the window, an unapproved workstation, access outside the window and logs for all three. If authentication lives on a separate VPN gateway, verify the whole system rather than attributing the result to the firewall alone.

Give every traffic-register row a test ID. Test both allowed flows and close variants that must be blocked, such as another destination or port. Synchronise clocks so packet captures, firewall logs and the operator record can be reconciled. If a simulator replaces a production PLC, document what it cannot reproduce and carry the residual test into SAT. Check that exceptions for false positives do not turn into broad permanent permits.

Budget for policy change management

New lines, PLC replacement, new contractors and MES upgrades will change the rule set. Define who requests a change, who explains the operational need, who approves it and when it is applied. Keep a configuration difference and prove rollback during FAT. Give emergency changes a retrospective approval deadline. If operation is outsourced, contract for changes, urgent support, night work and ownership of backups as well as monitoring.

Request a human-readable rule list with equipment numbers, zone, purpose and approver, not only a proprietary export file. Confirm that a spare unit can restore the backup, that firmware versions are compatible, and what happens when a licence expires.

FAT: test real communications before touching production

A factory or laboratory acceptance test validates product and policy fit without stopping the live line. Use real PLCs and HMIs where possible; otherwise reproduce protocol, direction, cycle and load. A successful ping is insufficient. Test display, control, alarms, recipe transfer, historian collection and maintenance access separately. Include both flows that must pass and flows that must be denied.

Test rule addition and deletion, address translation, VPN connect/disconnect, power loss, peer failover, configuration restoration and loss of the log collector. For a bridge, test required VLAN, multicast and broadcast behaviour. Save packet captures, device logs, timestamps and equipment state. Record pass, conditional pass or fail. Any broad temporary permit must have a reason, owner, expiry and SAT closure condition.

Let the process define acceptance values

Allowable delay and recovery time come from PLC cycles, supplier constraints and quality-record requirements. A buffered historian message and a PLC interlock cannot share one generic threshold. Safety, equipment and production owners should approve outcomes that might affect protective functions.

SAT, rollback and observation after installation

SAT verifies that the FAT configuration works with actual wiring, load and operating states. Back up current settings, switch configuration, cables and addressing. Name a rollback owner and a latest time to reverse an unsuccessful cutover. If a temporary bypass cable is prepared, control its use and removal.

Observe normal running, changeovers, data submission, batch completion, remote maintenance and restart. Weekly or monthly work that cannot occur on the installation day needs an observation period and a named owner. Hand over final configuration, logs, wiring and the change record. Review deny logs jointly across OT and IT to distinguish missed business traffic from unnecessary permits.

Roll out one well-understood cell first

Begin with a cell whose flows are understood and whose outage window is available. Use its results to improve the traffic register, logging, support process and rollout template. Do not copy its rules unchanged to a different line; PLC types, vendor access and quality systems differ. On cutover day, check production health, change wiring, apply limited rules, exercise the equipment, inspect denials and obtain production approval before returning to normal operation.

When a flow fails, record its time, source, destination, port and machine state before widening a rule. If a broad temporary permit is needed to keep production running, couple it with an owner, expiry, monitoring and a formal rollback decision.

Define when the observation period can end

The site test sees only part of the factory’s operating cycle. Check weekly backups, month-end work, supplier maintenance and calibration where relevant. Close the period when those activities have been observed, temporary rules have been removed or formally approved, denied flows have explanations and the team has rehearsed fault escalation. Assign dates and owners for work still untested.

The handover pack should include physical wiring, IP/NAT mapping, zone and conduit diagram, allowed flows, secure credential storage procedure, configuration backup, log destination, support contacts and rollback steps. Keep secrets in the company’s approved store, not in ordinary shared documents. Update this pack whenever equipment changes.

Frequent mistakes and how to avoid them

First, an IT-only rule design misses maintenance and cyclic traffic; review the register with equipment, production, IT and safety owners. Second, NAT does not automatically solve overlapping address ranges; verify embedded addresses, return paths and log correlation. Third, a bypass that keeps traffic moving may remove filtering; evaluate process safety and boundary protection separately. Fourth, do not leave all-port test permits in production. Fifth, budget for logs and firmware support. Sixth, use common templates with documented per-line differences instead of one universal rule set.

Related reading

For the broader risk and governance context, see OT security for factories in Thailand. For cabling, switching and addressing, see industrial network construction. Each specific machine still needs its own flow and failure assessment.

FAQ: selecting and deploying an industrial firewall

Is one firewall at the IT/OT boundary enough?

It depends on the flows and the consequence of lateral movement. The IT/OT entry point matters, but cells sharing an unrestricted OT network may need additional control points. Draw zones and conduits and verify that every path to a protected process crosses the intended boundary.

Which specification matters first when comparing industrial firewalls?

Check placement mode, addressing impact, required protocols, fault behaviour and logging before headline throughput. Then compare measured performance with actual rules enabled, redundancy, local service and full lifecycle cost.

Is NAT mandatory for PLC network segmentation?

No. Use it when overlapping addresses or existing routing constraints justify it, and test applications that embed addresses, discovery traffic and log traceability. NAT translates addresses; it is not a security policy on its own.

How much RFP, FAT and SAT work is necessary?

Scale the paperwork to the project, but retain each function: a shared requirement and acceptance statement in the RFP; live communication and fault tests in FAT; and actual wiring and operating verification in SAT. Even a small deployment benefits from an allowed-flow list, rollback plan and recorded results.

Conclusion

Choose an industrial firewall only after drawing the zones, registering required traffic and defining the production and safety outcome of failure. Make the RFP testable; measure passing and blocked traffic, failover and logging in FAT and SAT. Review temporary rules and changes after handover to keep the boundary effective.

If your Thai plant is still mapping the placement or traffic flows for a new or existing line, contact TOMAS TECH. A discussion can start with requirements or FAT/SAT criteria before a device is selected.

Sources

• NIST SP 800-82 Rev. 3
• ISA/IEC 62443 series
• ISA 62443-3-2 table of contents
• CISA segmentation guidance
• CISA defense-in-depth guidance
• Siemens SCALANCE S
• Palo Alto Networks fail-open guidance