Industrial network security architecture - segmentation, asset management and protection

Industrial networks were built in an era when the only threats were human error or equipment failure. Protocols such as Modbus, PROFINET, and EtherNet/IP were designed for reliability and speed, not security. Today these same networks connect to IT infrastructure, cloud services, and supplier systems - and the security architecture often fails to keep pace.

Designing a secure industrial network architecture rests on three pillars: segmentation, asset management, and active protection. Each is necessary; none is sufficient on its own. In practice, organizations that treat these pillars as separate projects lose the synergy between them - segmentation without inventory leads to faulty assumptions, and monitoring without segmentation generates noise in which real threats disappear.

The Purdue reference model - a starting point, not a destination

The Purdue Enterprise Reference Architecture (PERA) defines the hierarchy of layers in an industrial environment. Although created in the 1990s, it remains a useful conceptual tool - provided it is treated as a starting point for design, not a ready-made blueprint.

Level	Name	Example systems	Function
5	Enterprise Network	ERP, email, Internet	Business management
4	Business Planning	MES, scheduling	Production planning
3.5	DMZ	Historian proxy, jump host	IT-OT buffer
3	Site Operations	Historian, SCADA server	Plant management
2	Area Supervisory	HMI, engineering workstations	Process supervision
1	Basic Control	PLC, DCS, RTU	Control
0	Process	Sensors, actuators	Physical process

Level 3.5 (DMZ) is a critical element that either does not exist or is misconfigured in many organizations. A direct connection between the corporate network (levels 4-5) and control systems (levels 0-2) is one of the most common causes of OT incidents.

Limitations of the Purdue model in modern environments

The original model assumed all communication flows vertically - from level 0 to 5. Modern industrial networks break this assumption in several ways:

• IIoT platforms - level 0 sensors communicate directly with the cloud, bypassing intermediate layers
• Edge computing - data processing close to the physical process, in a layer Purdue does not define
• Remote vendor management - controller manufacturers connect directly to level 1 devices
• IT-OT convergence - MES and historian systems increasingly run in the cloud, not on dedicated on-site servers

Each of these scenarios must be explicitly defined in the security architecture - they cannot be dismissed because “the model does not account for them.”

Segmentation - zones and conduits per IEC 62443

Industrial network segmentation is not just VLAN division. IEC 62443 defines the concept of zones and conduits, which goes beyond traditional network segmentation:

Zone - a logical group of assets with common security requirements. A zone has an assigned Security Level Target (SL-T) specifying the required protection level.

Conduit - a controlled communication channel between zones. Every conduit should be explicitly defined, monitored, and filtered.

Zone design principles

1. Group assets with similar risk profiles - a PLC and its associated HMI in one zone, the historian in a separate one
2. Separate safety systems (SIS) - process safety systems belong in a dedicated zone with the highest SL-T
3. Isolate legacy systems - devices that cannot be updated require an additional protective layer
4. Minimize conduits - every cross-zone connection is a potential attack path
5. Define a Security Level Target per zone - not all zones need the same level of protection

Example segmentation for a manufacturing plant

A plant with three production lines and shared infrastructure:

• Zone 1: Production line A (PLC, HMI, I/O) - SL-T 2
• Zone 2: Production line B (PLC, HMI, I/O) - SL-T 2
• Zone 3: Production line C (PLC, HMI, I/O) - SL-T 2
• Zone 4: Safety Instrumented System (SIS) - SL-T 3
• Zone 5: OT network infrastructure (switches, firewall) - SL-T 2
• Zone 6: Engineering workstations - SL-T 2
• Zone 7: OT-IT DMZ (historian, jump host) - SL-T 2

Conduits: Zone 1-5 (control), Zone 6-1/2/3 (programming), Zone 7-IT (data).

Common segmentation mistakes

The most frequent issues we observe in practice:

• Paper-only segmentation - VLANs exist, but firewalls pass all traffic between them
• No intra-OT segmentation - one large “OT” segment instead of separating production lines
• Safety systems in the same zone as everything else - compromising one PLC provides a path to the SIS
• Shared engineering workstations - the same laptop used for PLC programming and email browsing

Asset management - you cannot protect what you do not know

Asset inventory is the foundation of every security architecture. In an industrial network, inventory includes not only IP and MAC addresses, but also:

• Device type and model (PLC, HMI, managed/unmanaged switch)
• Firmware and software version
• Network configuration (VLAN, IP address, mask, gateway)
• Communication relationships (who talks to whom, using which protocol)
• Business owner (who is responsible for the device)
• Vendor support status (end-of-life, end-of-support)
• Criticality to the production process

OT network inventory methods:

Active scanning (as in IT) is risky - it can cause controller failures. Preferred methods:

• Passive traffic monitoring - analysis of copied network traffic (mirror port, TAP) without interfering with communication
• OT protocol querying - tools like Tenable.ot can query controllers using their native protocol without disrupting operation
• Management system integration - import data from CMDB, engineering systems (TIA Portal, RSLogix)
• Manual inventory - physical plant walkthrough, especially for devices without network connectivity

From inventory to change management

Inventory is not a one-time project but the foundation of ongoing configuration management. Every change in the OT network - a new device, firmware update, network configuration change - should go through a controlled Management of Change process covering:

1. Security impact assessment
2. Approval by the zone owner
3. Documentation update (inventory, network diagrams)
4. Post-implementation verification

Industrial network protection

Industrial firewalling

A firewall at the OT zone boundary must understand industrial protocols. A traditional IT firewall sees Modbus TCP traffic as “connection on port 502” - it cannot distinguish a read command from a write command or validate register address ranges.

Industrial firewalls (e.g., Fortinet FortiGate with ICS modules, Palo Alto with OT support) offer deep packet inspection for industrial protocols - they can block specific commands, restrict access to particular PLC registers, and alert on OT traffic anomalies.

In addition to zone boundary firewalls, consider micro-segmentation using data diodes for the most critical connections. A data diode physically prevents return communication - data flows in one direction only, eliminating the entire class of attacks based on bidirectional communication.

Anomaly monitoring

In a stable OT network, the traffic profile is predictable. An OT-specific IDS can detect:

• New connections between devices that previously did not communicate
• Write commands to a PLC from a workstation that normally only reads
• Controller firmware changes outside maintenance windows
• Port scanning or ARP broadcasts at unusual frequencies
• Communication attempts to external addresses from the OT network
• Changes in PLC program logic

The key principle: OT monitoring must be passive. Active network probing (as in traditional vulnerability scanners) can cause controller failures and production downtime.

Physical and logical access control

OT network access control checklist:

• Unused switch ports - administratively shut down
• Port security on switches - MAC address limits per port
• 802.1X on engineering workstations
• Physical security of network cabinets (locks, access monitoring)
• Dedicated accounts for OT engineers (not shared)
• Multi-factor authentication on DMZ jump hosts
• Remote session recording for controller access
• Password policy for OT devices (yes, those defaults need changing)
• Separate engineering workstations for OT and IT (not the same laptop)
• Application whitelisting on HMI and engineering stations
• Removable media (USB) controls in OT zones

Reference architecture for remote access

Remote access to OT networks is a necessity (diagnostics, vendor support), but also one of the greatest risks. The secure ICS remote access architecture should provide:

1. Connection through a dedicated jump host in the DMZ
2. Multi-factor authentication
3. Session recording
4. Time-limited access (maintenance windows)
5. Approval of every session by OT personnel
6. Granular control - access to a specific device, not the entire network
7. Automatic disconnection after an idle period

Control system vendors often expect permanent, unrestricted remote access “just in case.” This approach creates a persistent attack vector. Every remote access session should be activated on demand, for a defined period, with full activity logging.

Implementation prioritization

Not every organization can deploy a complete security architecture simultaneously. A realistic sequence of actions:

1. Inventory - identify what you have and how it communicates (4-8 weeks)
2. IT-OT segmentation - deploy the DMZ and separate the corporate network from OT (2-4 months)
3. Remote access control - secure vendor and remote employee access (1-2 months)
4. Intra-OT segmentation - separate production lines, isolate SIS (3-6 months)
5. Monitoring - deploy OT-specific passive IDS (2-4 months)
6. Continuous improvement - regular audits, testing, policy updates

Each stage delivers measurable risk reduction. An organization that completes stage 2 is in a fundamentally better position than before the process started.

Connection to other OT security domains

Network security architecture is one element of a broader OT security program. Other key areas include vulnerability management, incident response, and application and controller configuration security. These domains reinforce each other - segmentation limits the impact of an unpatched vulnerability, monitoring accelerates incident detection, and inventory enables effective device lifecycle management.

Summary

Industrial network security architecture is not a one-off project - it is an ongoing process of adapting segmentation, monitoring, and access controls to a changing environment. Organizations that start with asset inventory, design segmentation in line with IEC 62443, and deploy OT-specific monitoring build resilience that works against both cyber threats and operational errors.

SEQRED supports organizations in designing and implementing industrial network security architectures - from auditing the current state to implementing segmentation and monitoring.

Sources

• IEC 62443-3-2: Security Risk Assessment for System Design - https://www.iec.ch/
• IEC 62443-3-3: System Security Requirements and Security Levels - https://www.iec.ch/
• NIST SP 800-82 Rev. 3: Guide to OT Security - https://csrc.nist.gov/pubs/sp/800/82/r3/final
• Purdue Enterprise Reference Architecture (ISA-95) - https://www.isa.org/
• CISA: Recommended Practices for ICS Security - https://www.cisa.gov/topics/industrial-control-systems
• SANS ICS: Network Security Monitoring in ICS Environments - https://www.sans.org/white-papers/