Best Practices for Industrial Firewall Deployment

By Dustin Guttadauro, Product Line Manager - Telecom & Fiber, Infinite Electronics 

A firewall that's in the wrong place does nothing. A firewall with rules too permissive to disrupt production also does nothing. And a firewall rated for a data center that's sitting in a 55°C electrical enclosure next to a variable frequency drive will fail — usually at the worst possible time. 

Industrial firewall deployment gets all three of these wrong more often than it gets them right. This guide covers where to put firewalls, how to configure them for OT environments, what hardware requirements matter, and how to keep them working after they're installed. 

What Is an Industrial Firewall, and How Is It Different From an IT Firewall? 

An industrial firewall is a network security device that controls traffic between zones in an operational technology (OT) environment – manufacturing plants, substations, water treatment facilities, and oil and gas operations. Like an IT firewall, it inspects packets and enforces rules. Unlike an IT firewall, it's built and configured for a completely different set of constraints. 

Purpose-built industrial firewalls from vendors like Fortinet (FortiGate Rugged series), Cisco (IR series), Hirschmann (Eagle series), and Moxa (EDR series) are designed for these constraints. [CONFIRM: verify current product lines before publishing] Deploying a standard IT firewall in an OT environment is possible — but it requires careful hardware selection, additional environmental protection, and extra attention to OT protocol handling. 

Where Should Industrial Firewalls Be Deployed? 

Firewall placement follows zone boundaries. The Purdue Model — the reference architecture for ICS/SCADA network design — defines five levels, and firewalls enforce the boundaries between them. In practice, three placement points matter most. 

 Placement 1: The IT/OT Boundary (Most Critical) 

The boundary between the corporate IT network and the OT network is where most attacks attempt to cross. A firewall here — typically in a DMZ configuration — controls what data can move between business systems and control systems, in which direction, and under what conditions. 

This boundary should enforce strict default-deny rules. Only explicitly approved traffic (historian data pulls, remote access through a jump server, and time sync from a dedicated NTP source) should be permitted. General internet browsing, email, and file sharing from the OT side should be blocked entirely. 

The industrial gateway at this boundary needs to support both OT protocol inspection and standard IT security features: stateful packet inspection, VPN termination, VLAN segmentation, and logging. This is where L-com's industrial wireless gateways fit — they're designed for exactly this boundary role in environments where the physical conditions rule out standard IT hardware. 

 Placement 2: Between OT Zones (Defense in Depth) 

Within the OT network, different systems have different risk profiles. A SCADA server that aggregates data from across the plant has no legitimate reason to directly initiate connections to a PLC on the shop floor. Firewalls between OT zones enforce least-privilege communication between systems that only need to talk in defined ways. 

Common zone boundaries within OT networks include: 

•       SCADA / DCS server zone vs. field device zone (PLCs, RTUs, I/O modules) 

•       Safety instrumented system (SIS) network vs. process control network — SIS networks should be as isolated as possible; many organizations use data diodes rather than firewalls here 

•       High-risk legacy equipment zone (older PLCs with no security features) vs. modern equipment zone 

•       Engineering workstation zone vs. operator HMI zone 

 Placement 3: Remote Site Connections 

Every remote site connection — cellular, MPLS, VPN — is a potential entry point. A firewall at the remote site, before the WAN connection, limits what an attacker who compromises the link can reach. A firewall at the main site, terminating the remote site connection, limits lateral movement if a remote site is compromised. 

Remote site firewalls face the harshest physical conditions: outdoor enclosures, wide temperature swings, limited power conditioning, and no on-site IT staff to respond to failures. Hardware selection here is not an afterthought — it's the primary variable that determines whether the security control is actually in place or just theoretically deployed. 

 How Do You Write Firewall Rules for an OT Network? 

Writing firewall rules for OT is different from IT in one fundamental way: the cost of being too restrictive is much higher. A misconfigured rule that blocks a control loop communication can stop production or, worse, disable a safety system. This creates pressure to write permissive rules, which defeats the purpose of the firewall. 

The way out of that trap is to know exactly what traffic should be flowing before you write a single rule. 

 Step 1: Build a Communication Baseline Before Touching Rules 

Deploy passive OT network monitoring (Claroty, Nozomi, Dragos, or open-source tools like Zeek) for 2–4 weeks before writing firewall rules. Let it map every communication flow: which IP talks to which IP, which protocol, which port, in which direction, and at what frequency. 

This baseline does two things. First, it tells you what rules you actually need — not what you think you need. OT networks in production often carry undocumented traffic that surprises engineers who've worked with them for years. Second, it gives you a before-picture that makes post-deployment validation possible. 

Step 2: Apply Default-Deny With Protocol-Aware Allow Rules 

Default-deny means all traffic is blocked unless explicitly permitted. In IT environments, this is standard. In OT environments, careful preparation is required because blocking traffic can stop production. 

The rules you write should be protocol-aware, not just port-based. A rule that allows TCP 502 (Modbus) between a SCADA server and a specific PLC IP is much tighter than a rule that allows all TCP from the SCADA subnet. Industrial firewalls with deep packet inspection (DPI) for OT protocols can go further — allowing Modbus read commands while blocking write commands from the SCADA server, for example. 

 Step 3: Handle Legacy OT Protocols Carefully 

Several OT protocols don't behave well under stateful firewall inspection. DNP3, for example, uses unsolicited responses from field devices to masters – the direction of session initiation is the reverse of what stateful firewalls expect. EtherNet/IP uses a connection-based model for I/O traffic that requires the firewall to track connection state for high-frequency, low-latency updates. 

If your industrial firewall doesn't have native support for the OT protocols on your network, stateful inspection will break those protocols even with technically correct allow rules. This is one of the main reasons generic IT firewalls fail in OT environments — and why protocol support is a required feature in your firewall selection, not a nice-to-have. 

 Step 4: Log Everything, Alert on Anomalies 

Every firewall in an OT environment should be configured to log denied traffic — and ideally all traffic. Denied traffic logs are the most direct signal that something unexpected is attempting to communicate. An ICS-targeting malware that's attempting lateral movement will show up as denied traffic before it causes damage if someone is watching the logs. 

Log storage at the firewall itself is typically limited. Forward logs to a centralised SIEM or log management platform. In bandwidth-constrained environments (remote sites on cellular), log pre-filtering at the firewall — forwarding only denied and high-priority events—keeps costs manageable. 

What Are the Hardware Requirements for an Industrial Firewall? 

The firewall that keeps your OT network secure is only useful if it keeps running. Industrial environments create hardware failure modes that standard IT equipment doesn't survive. 

One detail that gets overlooked: the cable plant connecting the firewall to the rest of the network is part of the reliability equation. A ruggedized firewall connected with standard patch cables in a high-vibration environment will develop intermittent connectivity issues that are difficult to diagnose remotely. Industrial-rated patch cables with locking connectors and fiber optic runs for longer distances or electrically noisy environments are the right call. 

Fiber optic connectivity solutions eliminate the ground loop and EMI problems that copper introduces in environments with large motor loads or welding equipment — and they're the right choice for inter-cabinet runs in most industrial settings. 

How Do You Manage Firewall Rules in OT Without Disrupting Production? 

Firewall rule management in OT is where the practical challenges pile up. Rules need to change as equipment is added, modified, or replaced. But every rule change carries risk. The answer isn't to avoid changes — it's to make changes safely. 

Maintain a Change Management Process for Firewall Rules 

Every firewall rule change in an OT environment should go through a documented change management process: proposed change, impact assessment, maintenance window scheduling, rollback plan, and post-change validation. This isn't bureaucracy for its own sake — it's the procedure that prevents a well-intentioned rule tweak from stopping a production line. The impact assessment step is where OT knowledge matters. An IT engineer who doesn't know that a specific PLC uses unsolicited Modbus responses might correctly implement a rule change that still breaks communication. OT engineering staff need to be part of the firewall change process. 

Use Staged Rollouts and Monitoring Windows 

When implementing a new firewall or a significant rule change, don't go straight to enforce mode. Most industrial firewalls support a monitoring or learning mode that logs what would have been blocked without actually blocking it. Run in this mode for a validation period — typically one to two weeks — and review the would-be-blocked traffic before flipping to enforce. 

For rule changes on live systems, schedule changes during maintenance windows. Verify that all expected communication paths are still working before ending the maintenance window. Keep the rollback procedure — whether that's reverting a rule, falling back to a previous config, or bypassing the firewall temporarily — documented and tested before you need it. 

 Audit Rules Regularly 

Firewall rules accumulate. Equipment gets decommissioned; the rule permitting traffic to it stays. A vendor gets remote access for a project; the rule permitting that access isn't removed when the project ends. Over time, a firewall that was tightly configured becomes progressively more permissive through rule accumulation rather than deliberate policy changes. 

A quarterly rule review against the current asset inventory catches this drift. Any rule referencing an IP address or device that no longer exists should be removed. Any rule that was added for a temporary purpose should be reviewed for continued necessity. 

 What Does a Well-Deployed Industrial Firewall Architecture Look like? 

A mid-size discrete manufacturer with three production lines, a central SCADA system, and two remote satellite facilities runs the following architecture:   

•       IT/OT boundary: An industrial firewall at the DMZ between the corporate LAN and the plant OT network. The SCADA historian sits in the DMZ — it can pull data from the OT network and push reports to the corporate LAN, but it can't be used as a pivot point between the two. 

•       OT zone segmentation: A second firewall separates the SCADA server zone from the field device zone. Rules permit the SCADA system to poll PLCs on specific Modbus addresses; the PLCs cannot initiate any traffic toward the SCADA zone. 

•       Safety system isolation: The safety instrumented system (SIS) network runs on a physically separate cable plant. A data diode — not a firewall — provides one-way data flow out of the SIS network for monitoring. No traffic flows in. 

•       Remote site connections: Each satellite facility has an industrial gateway with firewall capability at the site, plus a firewall at the main site terminating the VPN tunnel. Remote access to remote site OT systems goes through a jump server in the DMZ, not directly through the tunnel. 

This architecture took 18 months to implement fully, starting with the IT/OT boundary and working inward. The phased approach let production continue throughout and allowed the team to build OT network knowledge before writing fine-grained zone rules.  

Industrial Firewall Deployment Checklist 

Use this as a pre-deployment and audit framework. Adapt to your specific environment, protocols, and risk tolerance. 

Architecture and Placement: 

1.    IT/OT boundary firewall in DMZ configuration — no direct IT-to-OT traffic 

2.    Zone firewalls between SCADA/DCS, field devices, engineering workstations, and SIS as appropriate 

3.    Remote site firewalls at both ends of the WAN connections 

4.    SIS network isolated — data diode or air gap rather than firewall where possible 

Hardware Selection: 

5.    Temperature rating appropriate for installation location 

6.    Power input compatible with plant DC bus (24V or 48V typically) 

7.    DIN-rail form factor for panel installation 

8.    OT protocol support validated for protocols in use (Modbus, DNP3, EtherNet/IP, PROFINET, etc.) 

9.    Industrial-rated cable plant — locking connectors, fiber for long or noisy runs 

Rule Configuration: 

10.  Communication baseline documented before rules are written 

11.  Default-deny policy applied 

12.  Protocol-aware allow rules (not just port-based) where the firewall supports DPI 

13.  Legacy OT protocols handled — stateful inspection disabled or vendor-confirmed compatible 

14.  All traffic logged; denied traffic alerts configured 

Ongoing Management: 

15.  Change management process documented and followed for all rule changes 

16.  Quarterly rule review against current asset inventory 

17.  Firewall firmware on patch schedule — changes scheduled during maintenance windows 

18.  Firewall configuration backed up and version-controlled 

19.  Annual firewall audit, including traffic baseline review 

Building Resilient Industrial Networks 

Reliable industrial security depends on more than firewall rules and network segmentation. The underlying physical infrastructure must be designed to support continuous operation in demanding environments. From industrial Ethernet and fiber connectivity to wireless networking and ruggedized connectivity solutions, L-com helps organizations build resilient industrial networks that support security, reliability, and long-term operational performance. 

Frequently Asked Questions (FAQs) 

What is an industrial firewall? 

An industrial firewall is a network security device built for operational technology (OT) environments — manufacturing plants, substations, water treatment facilities, and similar industrial settings. It controls traffic between network zones in the OT environment, enforcing rules about which systems can communicate with which other systems, using which protocols, in which direction. 

What is the Purdue Model, and how does it relate to firewall placement? 

The Purdue Model (also called the Purdue Reference Model or PERA) is a layered architecture for ICS/SCADA network design that defines five levels: field devices (Level 1), control systems (Level 2), supervisory systems (Level 3), manufacturing operations (Level 4), and enterprise systems (Level 5).  

Can you use a next-generation firewall (NGFW) in an OT environment? 

Yes, with caveats. Next-generation firewalls add application awareness, user identification, and intrusion prevention to stateful packet inspection. In OT environments, the application-layer inspection capabilities are valuable — being able to distinguish between Modbus read and write commands, for example. The challenge is that many NGFWs are designed for IT environments and lack the hardware ruggedness, DIN-rail form factor, and OT protocol support that industrial deployments require.    

What happens if an OT firewall is misconfigured? 

The consequences range from minor to severe, depending on what the misconfiguration blocks. A rule that inadvertently blocks traffic to a non-critical HMI creates an operational nuisance. A rule that blocks communication to a PLC controlling a critical process can stop production. A rule that blocks the safety instrumented system can disable safety interlocks — potentially creating a hazardous condition.