How to Design an Industrial Network That Actually Protects Your Plant Floor

Most manufacturers have a firewall on their internet connection. Many have antivirus on their office computers. And almost all of them have a plant floor that's directly connected to that same network — or worse, connected to the internet with nothing in between.

Industrial network design isn't just an IT topic. It's an operational risk topic. A flat network — one where an engineer's laptop, the accounting server, and a PLC controlling a 480V drive are all reachable from each other — is one phishing email away from a production shutdown.

This article explains the principles behind secure industrial network design, the Purdue Model that frames it, and what practical segmentation actually looks like in a manufacturing environment.

The Purdue Model: A Framework Built for Industrial Environments

The Purdue Enterprise Reference Architecture — developed in the 1990s and still the dominant framework for industrial network design — divides control system networks into five zones, each representing a different function and security posture:

The key insight of the Purdue Model is that traffic should be controlled and inspected at every boundary, and that Levels 0–2 should be as isolated from higher levels as possible. The IDMZ is not optional — it's where you break the direct path between your corporate network and your PLCs.

Why Flat Networks Are the #1 OT Security Risk

In a flat network, everything can reach everything. Your PLC can be pinged from the CFO's laptop. Your SCADA server shares a subnet with the HR system. There are no internal firewalls, no segmentation, no inspection of traffic between zones.

This design — still extremely common in manufacturing — creates several critical risks:

• Lateral movement: When ransomware hits any device on a flat network, it can propagate to every other device. There's nothing stopping it from reaching your PLCs.
• Unauthorized access: Any device on the network can attempt to communicate with your control systems — including vendor laptops, employee phones that join the WiFi, and any compromised endpoint.
• No visibility: Without segmentation, you can't monitor what's talking to your PLCs, detect anomalous communications, or identify compromised devices before they reach critical systems.
• Compliance exposure: Standards like IEC 62443 and NIST CSF explicitly require network segmentation. A flat architecture is a direct gap against these frameworks.

Core Design Principles for OT Network Security

1. Segmentation and Zone Definition

Start by mapping your environment to the Purdue Model. Identify which devices belong to which level, and define the boundaries between zones. This doesn't have to happen all at once — prioritize segmenting Level 1/2 from everything else first.

Use managed switches with VLANs to create logical separation at a minimum. For true security, put firewalls at zone boundaries that inspect and log traffic crossing the boundary.

2. The Industrial DMZ

The IDMZ is where data transfer between IT and OT happens in a controlled way. Rather than allowing your ERP system to query your historian directly, data flows from the historian to a server in the IDMZ, where IT systems can retrieve it without ever having a direct connection to Level 2.

Common technologies in an IDMZ include data diodes, secure file transfer servers, and application-layer proxies. Firewalls on both sides of the IDMZ enforce that traffic moves only in the intended direction.

3. Firewall Rules: Default Deny

OT firewalls should operate on a default-deny principle: unless a connection is explicitly permitted by a rule, it's blocked. This is the opposite of how many corporate networks are configured, where broad permit rules are layered with exceptions.

Document every rule. Know why each connection is permitted, who approved it, and when it was last reviewed. Firewall rule sprawl — hundreds of undocumented rules accumulated over years — is one of the most common findings in OT security assessments.

4. Remote Access

Direct VPN access to OT networks is one of the most common attack vectors. The better approach is a dedicated OT remote access solution that provides jump-server functionality: remote users authenticate to a secure gateway, access is logged, sessions are recorded, and the remote user never has a direct IP route to PLC-level devices.

Multi-factor authentication on all remote access is non-negotiable. A vendor's VPN credentials getting phished should not result in direct access to your control systems.

5. Asset Inventory

You can't protect what you don't know about. A complete OT asset inventory — every PLC, HMI, switch, workstation, and field device — is the foundation of everything else. Without it, you don't know your attack surface, you can't monitor for anomalies, and you can't prioritize remediation.

Passive network monitoring tools (Claroty, Dragos, Armis) can build an asset inventory by listening to network traffic without actively scanning — important in OT environments where active scanning can disrupt sensitive devices.

These are the same principles we apply in every OT cybersecurity assessment and segmentation project we run, adapted to each facility's existing network and production schedule.

Practical Starting Points

A full Purdue Model implementation isn't built in a day. For manufacturers just beginning this work, a practical sequence is:

• Step 1: Inventory your OT assets and map network topology as it actually exists today
• Step 2: Identify and document all connections between OT and IT networks
• Step 3: Install a next-generation firewall (FortiGate or equivalent) at the IT/OT boundary
• Step 4: Implement VLAN segmentation to separate Level 1/2 from Level 3 and above
• Step 5: Establish an IDMZ for historian and ERP integration
• Step 6: Deploy passive monitoring for ongoing visibility and anomaly detection
• Step 7: Formalize remote access through a dedicated OT remote access gateway

Each step meaningfully reduces risk, even before the next one is complete.

The Bottom Line

Industrial network security isn't about buying a product — it's about designing a network architecture where control systems are isolated, traffic is inspected, and access is controlled. The Purdue Model provides a proven framework for doing that without disrupting operations.

The goal isn't perfection on day one. It's making your plant progressively harder to compromise, with clear visibility into what's happening on your network so you can detect and respond when something goes wrong.