Best Practices for Industrial Firewall Deployment

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

Industrial firewalls play a critical role in protecting operational technology (OT) and industrial control system (ICS) networks, but successful deployments require more than simply installing a security appliance. Unlike enterprise environments, industrial networks prioritize continuous availability, deterministic communications, and support for specialized protocols such as Modbus TCP, EtherNet/IP, DNP3, and PROFINET.  

Effective industrial firewall deployment requires thoughtful placement, carefully designed security policies, and a network architecture that protects critical systems without disrupting operations. This guide explores best practices for deploying industrial firewalls, common implementation mistakes, and the physical infrastructure considerations that help support reliable industrial cybersecurity. 

Key Takeaways 

• Industrial firewalls are necessary but not sufficient for OT security: a firewall deployed on a network where EMI-induced data corruption or surge damage can reach connected equipment will have its logical controls undercut by physical events that bypass rule sets entirely. 

• Placement matters as much as configuration. A next-generation firewall at the IT/OT perimeter addresses a different threat model than a zone-to-zone firewall between control and field, or an inline device-level firewall protecting a single PLC. Most manufacturing environments need more than one placement. 

• ICS protocol rule design requires a deny-by-default base policy with explicit allows for specific source IPs, destination IPs, and — for Modbus and DNP3 — specific function codes. Subnet-wide allows are the most common industrial firewall misconfiguration. 

• The industrial DMZ is the architectural pattern that resolves the data sharing problem: a historian or OPC-UA server in the DMZ can share data with enterprise systems without exposing OT devices directly to IT-side threats. 

Why is industrial firewall deployment different from enterprise firewall deployment? 

Enterprise firewalls are configured with two assumptions: traffic protocols are standard TCP/IP applications, and a disruption to the firewall can be addressed by a network engineer within minutes. Neither assumption holds in OT environments. 

Industrial control networks carry protocols — Modbus TCP, EtherNet/IP, DNP3, PROFINET — that most enterprise next-generation firewalls don't understand at the packet level without a specific OT module. An enterprise firewall configured to allow TCP 502 (Modbus) will pass any packet on that port, including malicious Modbus write-commands that should only come from specific SCADA hosts. Without function-code-level inspection, the firewall is half blind to the most dangerous OT traffic. 

The operational availability constraint changes firewall management fundamentally. A firewall rule change in an enterprise network that breaks an application is an IT incident. A firewall rule change in an OT network that blocks a PLC poll from its SCADA server is a production stoppage. This means OT firewall changes require change management, maintenance windows, and rollback plans that enterprise firewall teams rarely need.  

Where should industrial firewalls be deployed?Where should industrial firewalls be deployed? 

Industrial firewall placement is not a binary choice between inside and outside the OT network. Most environments need firewalls in multiple positions, each addressing a different threat model. The four standard placements are: 

Perimeter firewall (IT/OT boundary)Perimeter firewall (IT/OT boundary) 

The perimeter firewall sits between the enterprise network and the industrial DMZ. It enforces the boundary between IT-side threats and the OT environment as a whole. Rules at this position are primarily about data sharing: what can the historian share with enterprise analytics, what can the MES query from OT systems, and what vendor access paths are permitted? 

Protocol inspection at the perimeter focuses on IT-to-OT data exchange protocols: OPC-UA, HTTPS, and historian replication traffic. Deep packet inspection of low-level OT protocols (Modbus, Ethernet/IP) is less relevant here — those protocols shouldn't be reaching the perimeter in a correctly segmented network. 

Zone-to-zone firewall (intra-OT)Zone-to-zone firewall (intra-OT) 

Zone-to-zone firewalls sit within the OT environment between different functional zones — typically between the control zone (SCADA, HMIs) and the field zone (PLCs, RTUs, sensors). This is where OT-protocol deep packet inspection is most valuable. 

A zone-to-zone firewall configured with Modbus function code inspection can allow read commands (function codes 01, 02, 03, 04) from the SCADA server to specific PLCs while blocking write commands (function codes 05, 06, 15, 16) from any source that isn't an authorized engineering workstation. This is the difference between a firewall that allows Modbus traffic and a firewall that understands it. 

Inline (device-level) firewallInline (device-level) firewall 

Inline firewalls protect a single device or cell — typically a safety instrumented system, a critical PLC, or a production cell that needs isolation from the rest of the control network. They are installed physically in-line between the device and its network switch port. 

The Triton/TRISIS attack on a Saudi petrochemical facility in 2017 targeted safety instrumented systems that were reachable from the process control network. An inline firewall with a deny-by-default policy on the safety system's network interface would have blocked the lateral movement path that attack used.Ethernet surge protectors are typically co-located with inline firewalls on the same DIN rail, since the inline position means the device is at a field-level exposure point where surge protection is needed regardless. 

Remote access gatewayRemote access gateway 

A remote access gateway is a specialized firewall or VPN concentrator positioned at the DMZ boundary specifically to handle vendor and remote operator access. Sessions terminate at the gateway — vendors never get direct network access to OT devices. The gateway authenticates, logs, and forwards only the specific traffic types allowed by its policy. 

The most common misconfiguration at this position is allowing too-broad destination access: a vendor who should only reach the HMI for one production line gets access to the entire control zone subnet. Remote access policies should be scoped to specific destination IPs, specific ports, and specific time windows. 

 How should ICS firewall rules be designed? 

Industrial firewall rule design starts from a single principle: deny by default, then add explicit allows for documented, necessary traffic only. This is the opposite of how most OT networks were originally configured — where devices were allowed to communicate freely and rules were added to block specific threats. 

A deny-by-default base policy combined with a traffic baseline — a documented map of every legitimate communication flow in the network — produces rule sets that are both specific and auditable. The traffic baseline is built from passive traffic analysis before any rule is written; tools like Dragos, Claroty, and Nozomi Networks generate this baseline automatically by monitoring OT protocols. 

Rule-set template for a manufacturing control zoneRule-set template for a manufacturing control zone 

The table below shows a 10-rule template for a firewall between a control zone and an industrial DMZ. Rules are ordered by specificity — more specific rules first, default deny last. Adapt IP addresses and protocol versions to your environment. 

ICS protocol-specific rule considerationsICS protocol-specific rule considerations 

Modbus TCP (port 502)Modbus TCP (port 502) 

A subnet-wide allow on TCP 502 is one of the most dangerous industrial firewall misconfigurations. Any device on the allowed subnet — compromised or not — can send any Modbus function code to any PLC on the destination subnet. The correct rule scopes to specific source IPs (the SCADA server and authorized engineering workstations) and specific destination IPs (specific PLCs, not a subnet). For firewalls that support Modbus deep packet inspection, add function code filtering: read commands (01–04) from SCADA hosts, write commands (05–06, 15–16) only from engineering workstations with change-controlled access. 

DNP3 (TCP/UDP port 20000)DNP3 (TCP/UDP port 20000) 

DNP3 is used primarily in utilities — power, water, oil, and gas — for communication between control systems and remote outstations. Like Modbus, it has no native authentication. DNP3 deep packet inspection allows filtering by application-layer function code (Direct Operate, Select-Operate, Read, Write) in addition to IP source and destination. Unsolicited responses — DNP3 messages sent from an outstation to the master without a preceding poll request — should be evaluated carefully; in some architectures, they're expected; in others, they're anomalous and should trigger an alert. 

EtherNet/IP (TCP 44818, UDP 2222)Ethernets/IP (TCP 44818, UDP 2222) 

EtherNet/IP is the dominant protocol in Rockwell Automation environments and is common across many manufacturing verticals. It uses two ports: TCP 44818 for explicit messaging (command/response) and UDP 2222 for implicit messaging (continuous I/O data). A firewall that blocks UDP 2222 while allowing TCP 44818 will break real-time I/O communication between a controller and its I/O modules — a production-stopping misconfiguration that is not immediately obvious from the rule. Test EtherNet/IP rules in a staging environment before applying them to live production systems. 

What is an industrial DMZ, and why does it matter for firewall design? 

An industrial DMZ (Demilitarized Zone) is a network segment bracketed by two firewalls — one facing the OT environment and one facing the enterprise network — that hosts systems needing visibility into both worlds without either side having direct access to the other. 

The practical problem the DMZ solves: manufacturing operations need production data in enterprise systems for ERP integration, quality management, and analytics. Without a DMZ, the choices are bad: either the historian is on the OT network and accessible from the enterprise, which exposes OT to IT-side compromise, or the historian is on the enterprise network and can directly query PLCs, which exposes OT to IT-side threats in the other direction. 

The DMZ resolves this by hosting the historian, OPC-UA servers, and protocol gateways in a zone where neither the OT firewall nor the IT firewall has to allow direct access between OT devices and enterprise systems. 

What belongs in an industrial DMZ?What belongs in an industrial DMZ? 

•        Process data historian: collects time-series data from SCADA; enterprise analytics pull from it, not from SCADA directly 

•       OPC-UA server: translates OT protocols to web-friendly OPC-UA; enterprise applications connect to this, not to PLCs 

•       Jump server (bastion host): all remote access to OT systems terminates here; no direct OT device connections from outside 

•       Antivirus/patch management server: updates for OT workstations served from DMZ, not from enterprise-connected update servers 

•       Protocol gateway / data diode: for environments where one-way data flow is required — sends data from OT to enterprise with no return path 

 The OT-side firewall in the DMZ should carry OT-aware rules: specific OT protocols from specific source IPs to specific DMZ hosts, with function code filtered where supported. The enterprise-side firewall carries standard IT rules: HTTPS, database replication, and API calls to specific DMZ services. The two rule sets differ because the two threat models differ. 

Why does physical layer integrity affect firewall effectiveness?Why does physical layer integrity affect firewall effectiveness? 

A firewall inspects packets. If the physical infrastructure delivering those packets is damaged or electrically compromised, the firewall's rules may be enforced on corrupted data, or the firewall may fail and fail open, passing all traffic rather than denying by default. 

Two physical-layer failure modes directly affect firewall behavior in industrial environments. 

EMI-induced data corruptionEMI-induced data corruption 

Manufacturing environments generate electromagnetic interference from motors, variable frequency drives, welding equipment, and high-voltage bus systems. EMI on unshielded copper Ethernet cables produces CRC errors, packet loss, and, in severe cases, bit-flipping that corrupts packet headers. A firewall receiving corrupted packets may fail to match them against rules correctly, log anomalous traffic that isn't actually suspicious, or trigger false-positive alerts that desensitize operators to genuine events. 

On the practical operations side, intermittent EMI-induced packet loss looks identical in firewall logs to port scan behavior: repeated connection attempts, partial packet exchanges, and high error rates on specific ports. Teams investigating what looks like reconnaissance may be looking at a bad cable run near a drive. That ambiguity slows incident response and burns analyst time. 

Shielded cable on all copper runs in EMI-heavy areas reduces this noise floor. Fiber uplinks at zone boundaries eliminate it — there is no electromagnetic coupling path across a fiber link. For inline and zone-to-zone firewall positions where cable runs cross EMI sources,Ethernet surge protectors on all copper ports add a transient protection layer that shielding alone doesn't provide. 

Surge damage and fail-open behaviorSurge damage and fail-open behavior 

Voltage transients from lightning, switching events, and motor startups can damage switch and firewall ports. Port damage typically degrades gradually, with intermittent connectivity, then permanent failure. A firewall port that fails in a degraded state may pass traffic it would otherwise inspect and block, or it may generate error conditions that cause the firewall to fail open (pass all traffic) rather than fail closed (deny all traffic). 

The fail-open risk is particularly important for inline firewalls at field device positions, where surge exposure is highest. An inline firewall withoutEthernet surge protection on its field-facing port is a single transient event away from losing the protection it provides. Surge protectors installed on every copper port that terminates at a field device or runs to an outdoor location are a prerequisite for reliable inline firewall operation in industrial environments. 

What are the most common industrial firewall deployment mistakes? 

Subnet-wide protocol allows for host-specific rules instead.Subnet-wide protocol allows for host-specific rules instead. 

"Allow TCP 502 from the control zone subnet to the field zone subnet" is a common rule that provides almost no security. Any compromised device in the control zone can send any Modbus command to any device in the field zone. The correct rule is "Allow TCP 502 from the SCADA server IP to the PLC subnet" — and ideally, with function code filtering, "Allow Modbus read function codes from the SCADA server IP to specific PLC IPs." The effort to write specific rules pays off the first time an attacker or malware compromises a device in the allowed source subnet. 

Skipping traffic analysis and breaking production on cutoverSkipping traffic analysis and breaking production on cutover 

The most operationally costly deployment mistake is applying a deny-by-default policy without first documenting all legitimate traffic flows. At cutover, legitimate OT communication is blocked, production stops, and the team spends hours identifying which rule is missing. This happens because OT traffic is complex and poorly documented: many facilities don't have accurate records of which PLCs communicate with which SCADA components on which ports. Passive traffic analysis for two to four weeks before writing any rules prevents this. Dragos, Claroty, and Nozomi all provide this capability as part of their OT monitoring platforms. 

Treating the firewall as a set-and-forget controlTreating the firewall as a set-and-forget control 

Industrial firewall rule sets accumulate technical debt faster than most network teams expect. An integrator adds a temporary rule for commissioning, and it stays permanently. A vendor requires a new protocol port, and an exception is added without removing the old rule. A production expansion adds devices to subnets covered by overly broad rules that were written before the expansion. Within two years, the rule set often bears little resemblance to the original design. 

Quarterly rule set reviews — removing expired exceptions, tightening overly broad rules, and validating that every allow rule still corresponds to a documented communication requirement — are operational maintenance that most OT teams don't schedule. Without it, the firewall gradually reverts toward permissive. 

No out-of-band management pathNo out-of-band management path 

A firewall managed through the same network it protects creates a recovery problem: if a misconfiguration blocks management traffic, the firewall can only be recovered with physical access. In a remote or minimally staffed facility, that means driving to the site. Out-of-band management — a dedicated management port on a separate VLAN or a cellular backup connection for remote access — allows policy correction without physical access and is worth the additional setup complexity. 

Industrial Firewall Deployment Checklist 

This 20-item checklist covers the deployment sequence from pre-installation discovery through ongoing operations. Follow the phases in order — pre-deploy discovery before configuration prevents the production-stopping cutover failures described above. 

1. Complete traffic analysis before writing firewall rules. (Pre-deployment) 
   Use passive traffic capture tools such as Dragos, Claroty, or Nozomi Networks to map all OT protocol flows.  

1. Ensure the asset inventory is current. (Pre-deployment) 
   Document every device within the deployment scope, including its IP address, protocol, and function.  

1. Document the network zone design according to the IEC 62443 zone-and-conduit model. (Pre-deployment) 
   Finalize the architecture on paper before making any cabling or configuration changes.  

1. Verify that the firewall supports OT protocol deep packet inspection (DPI). (Pre-deployment) 
   Confirm support for protocols such as Modbus, Ethernet/IP, and DNP3, as not all next-generation firewalls include OT modules.  

1. Install fiber uplinks at the IT/OT boundary. (Physical Deployment) 
   Verify galvanic isolation and test the media converter pair before cutover.  

1. Install Ethernet surge protectors on all field-device copper ports connected to the firewall. (Physical Deployment) 
   Protect every external copper run with inline surge protection.  

1. Secure the firewall and network switch inside a locked industrial enclosure. (Physical Deployment) 
   Connect the enclosure's tamper switch to the alarm system to prevent unauthorized physical access.  

1. Verify grounding and bonding for all metal enclosures and cable shields. (Physical Deployment) 
   Ensure compliance with IEC 61643-11 requirements.  

1. Change all default firewall management credentials. (Configuration) 
   Replace factory-default usernames and passwords before deployment.  

1. Place the management interface on an isolated VLAN. (Configuration) 
   Keep it inaccessible from both OT and IT production networks. Out-of-band management is recommended.  

1. Implement a deny-by-default security policy. (Configuration) 
   Block all traffic by default and explicitly allow only required communications.  

1. Limit OT protocol rules to specific source and destination IP addresses. (Configuration) 
   Avoid subnet-wide allow rules by permitting only documented SCADA-to-PLC communications.  

1. Enable Modbus function-code filtering. (Configuration) 
   Restrict each device to only the Modbus function codes it requires and block unauthorized write commands.  

1. Synchronize the firewall clock using NTP. (Configuration) 
   Accurate timestamps are essential for event correlation and forensic investigations.  

1. Configure Syslog forwarding to a centralized log collector. (Configuration) 
   Forward logs to a SIEM or centralized log management platform.  

1. Test the firewall during a scheduled maintenance window. (Testing) 
   Verify that all legitimate OT traffic continues to function after deployment.  

1. Perform a penetration test from the IT network. (Testing) 
   Confirm that OT devices cannot be accessed directly from the enterprise network.  

1. Validate OT protocol DPI using known-good and known-bad traffic samples. (Testing) 
   Ensure the firewall detects and alerts on unauthorized protocol activity.  

1. Review firewall policies every quarter. (Ongoing Maintenance) 
   Remove obsolete rules, audit exceptions, and tighten overly permissive policies.  

1. Monitor CISA ICS-CERT advisories for firewall vulnerabilities. (Ongoing Maintenance) 
   Keep the firewall updated, as it is a potential attack surface.  

Firewall configuration is half the job 

A correctly configured industrial firewall with OT-protocol DPI, a deny-by-default base policy, and function-code-level rules for Modbus and DNP3 is a strong control. It's also a control that depends on physical infrastructure that delivers uncorrupted packets and doesn't fail open under surge conditions. 

Ethernet surge protectors on all copper ports connected to field devices are the physical counterpart to the firewall's logical controls — they prevent the surge events that damage ports and degrade the physical reliability the firewall's software depends on. Fiber uplinks at zone boundaries provide galvanic isolation that protects the firewall from ground-path surge propagation on the network side. 

For the next layer: once firewall segmentation is in place,zero trust for OT networks covers how to extend identity-based access control beyond perimeter security to individual device and user trust verification. 

Building Secure Industrial Networks 

Effective industrial cybersecurity depends on more than firewall rules and network segmentation. Reliable protection begins with resilient network infrastructure that supports secure communications, deterministic performance, and continuous operation. From industrial Ethernet and fiber connectivity to ruggedized networking solutions for harsh environments, L-com helps organizations build the physical foundation that supports secure, reliable OT and ICS networks. 

Frequently Asked QuestionsFrequently Asked Questions 

Q1: What is an industrial firewall?Q1: What is an industrial firewall? 

A: An industrial firewall is a network security device designed for OT (Operational Technology) environments — manufacturing plants, utilities, oil and gas facilities, and other industrial control system networks. 

Q2: What OT protocols should an industrial firewall inspect?Q2: What OT protocols should an industrial firewall inspect? 

A: At minimum, an industrial firewall should support deep packet inspection for Modbus TCP (port 502), EtherNet/IP (TCP 44818, UDP 2222), and DNP3 (TCP/UDP 20000) — the three protocols that account for the majority of OT network traffic in manufacturing and utility environments.                  

Q3: What is the difference between a SCADA firewall and a regular firewall?Q3: What is the difference between a SCADA firewall and a regular firewall? 

A: A SCADA firewall is an industrial firewall deployed specifically at a position in the network where it inspects SCADA protocol traffic — typically between SCADA servers and the PLCs or RTUs they control. The key capability it needs that a regular firewall doesn't have is OT protocol deep packet inspection: the ability to parse Modbus, DNP3, or Ethernet/IP frames at the application layer and filter on function codes, memory addresses, or register ranges within those protocols.