OT network segmentation: how to separate PLCs, HMIs, SCADA and maintenance access

In many industrial sites, the OT network starts flat. A single broadcast domain connecting PLCs, HMIs, SCADA servers, engineering workstations, printers, office PCs, and sometimes even the guest Wi-Fi. When everything works, nobody thinks about it. When something goes wrong, the problem spreads everywhere.

OT network segmentation exists to contain that risk: separating traffic flows, reducing the attack surface, limiting lateral movement, and creating conditions where a problem in one area does not automatically escalate into a plant-wide shutdown. It is not about locking everything down, but about designing communication that is strictly necessary and verifiable between different parts of the infrastructure.

Why a flat network is a real problem

A flat OT network is not just a theoretical risk. The practical consequences show up in several ways:

• Ransomware entering through an office workstation reaches SCADA servers with no barriers
• A broadcast storm caused by a faulty device disrupts PLC-to-HMI communication
• An external maintenance technician connected to the network can see the entire infrastructure, not just the machine they are working on
• An unauthorised network scan can disturb PLCs and embedded devices that do not tolerate unexpected traffic
• There is no way to trace who communicates with what, because everything sits in the same segment

Under these conditions, any incident — whether cyber-related or purely operational — can expand without control. And incident response becomes far more complicated, because there are no clear boundaries between zones.

The zone and conduit model from IEC 62443

The IEC 62443 standard introduces a straightforward but effective concept: divide the infrastructure into zones (groups of assets with similar security requirements) connected by conduits (controlled communication channels between zones).

Each zone has a Security Level reflecting the risk and criticality of the assets it contains. Conduits between zones must ensure that traffic is limited to what is necessary and that security policies are consistent with the required levels.

In practice, this translates into a set of architectural decisions:

• Separating the IT network from the OT network with a clear boundary, typically an industrial DMZ
• Dividing the OT network into functional zones: control, supervision, engineering, maintenance
• Defining explicit rules for every flow that crosses a zone boundary
• Using firewalls or filtering devices at the transit points between zones

The zone and conduit model does not prescribe a specific topology. It adapts to different architectures: industrial buses, switched Ethernet, redundant rings, star topologies. The central point is the separation logic, not the technology used to implement it.

How to identify zones in a real plant

Defining zones on paper is fairly intuitive. Doing it on a plant that already exists, with legacy constraints, existing cabling and equipment that cannot be powered down, is a different matter.

A pragmatic approach starts with these questions:

Which groups of assets share the same operational function?

The PLCs on a production line, the remote I/O modules, the drives and associated sensors typically belong to the same control zone. The HMIs operating that line may sit in the same zone or in a separate supervision zone, depending on the architecture and the acceptable level of risk.

Which assets have different security requirements?

A SCADA server collecting data from multiple lines has a different risk profile than a single PLC. An engineering workstation running TIA Portal, Studio 5000 or other development software holds elevated privileges and the ability to modify the process: it deserves a dedicated zone or at least specific access rules.

Which communication flows are strictly necessary?

The PLC needs to communicate with its HMI. The HMI may need to reach the SCADA server. The SCADA server may feed a historian in the DMZ. But the PLC does not need Internet access, and the procurement department PC does not need to reach the PLC. Mapping the necessary flows is the first step toward defining conduits.

Where are the remote access and maintenance entry points?

The points where external maintainers connect, where VPNs terminate, where remote support tools are used: these are natural zone boundaries. Maintenance access should never reach the control zone directly without passing through a mediation point.

Reference architecture: levels and traffic separation

A reasonably mature OT segmentation architecture, inspired by the Purdue/ISA-95 models and IEC 62443 recommendations, is structured across multiple levels. It is not the only possible architecture, but it is a well-established reference.

The guiding principle is that communication flows down for queries and up for data collection, but it should never cross levels without a control point. In particular, no IT system should communicate directly with the control level (level 1) without passing through at least the DMZ and level 3.

The industrial DMZ: what belongs there and what does not

The industrial DMZ is the exchange point between the IT world and the OT world. It is not just a firewall: it is a separate zone with dedicated services that prevent direct contact between the two networks.

The DMZ may host:

• Mirror historian — a replica of the historical database that IT can query without accessing the actual SCADA server
• Jump host — a controlled workstation through which maintainers connect to the OT network, with session logging and strong authentication
• Patch and update server — a local repository from which OT systems pull updates without a direct Internet connection
• Application gateways — services that transfer data between IT and OT in a unidirectional or tightly controlled manner

What should not be in the DMZ: the active SCADA server, engineering workstations, production databases, PLC management consoles. These belong on the OT side and should be protected accordingly.

A common mistake is setting up a DMZ on paper but then opening firewall rules so broadly that the separation becomes ineffective. The DMZ only works if the traversal rules are restrictive and documented.

Separating PLCs, HMIs and SCADA: practical choices

Within the OT network, the separation between PLCs, HMIs and SCADA depends on plant complexity, the number of production lines, process criticality and the existing network topology.

Small plants with simple architectures

In a small plant — two or three lines, a dozen PLCs, a handful of HMIs — VLAN-based segmentation with a firewall or a layer-3 managed switch may be sufficient. The minimum objective is to separate at least:

• The control network (PLCs, remote I/O, drives) from the supervision network (HMIs, SCADA)
• Engineering traffic from production traffic
• Maintenance access from the rest of the OT network

Even with limited resources, this separation significantly reduces risk. A problem on the engineering workstation does not directly impact the control bus. An external maintenance technician only sees the segment they are authorised to access.

Complex plants with multiple lines and cells

In larger plants, segmentation should be done by production cell or functional zone. Each cell has its own control network, and communication between cells passes through controlled points. The SCADA server may communicate with multiple cells, but each cell should have no visibility into the others.

This approach limits the blast radius: if one cell is compromised, the others continue to operate. Incident response can focus on a defined perimeter rather than the entire network.

Legacy networks

On plants that are 15 or 20 years old, it is common to find PLCs connected to unmanaged switches, networks without VLANs, protocols that do not support authentication, and topologies that have grown by accretion. In these cases, full segmentation may require significant effort, and it is rarely feasible all at once.

A gradual approach works better:

1. Insert a firewall or managed switch at the IT/OT boundary, even with initially permissive rules, to gain visibility into traffic flows
2. Isolate remote maintenance access and engineering workstations first
3. Progressively separate the most critical lines into dedicated VLANs
4. Tighten firewall rules as you understand the actual traffic

Segmentation on legacy plants will never be as clean as on a greenfield site. But even partial separation is better than no separation at all.

Managing maintenance access

Maintenance is one of the most critical concerns in a segmented OT network. The maintenance technician — whether internal or external — needs access to PLCs, HMIs, drives and network configurations. They need to upload firmware, change parameters and run diagnostics. This access is essential for operations, but it also represents a risk vector if left ungoverned.

Physical access on site

When a maintainer is on site with their laptop, the entry point to the OT network must be controlled. Some reasonable practices:

• Dedicated maintenance network ports on VLANs separate from the control traffic
• Port authentication (802.1X) or, alternatively, manual port enablement by the plant operator
• Traffic restrictions: the maintenance laptop reaches only the PLC it needs to work on, not the entire network
• Connection and session logging

On plants where 802.1X is not practical — due to switch limitations, device constraints or time pressures — even a maintenance VLAN with controlled access is a significant improvement over direct access to the production network.

Vendor remote access

Machine vendors, integrators and external maintenance providers connect remotely for diagnostics, updates and support. This access should pass through a mediation point, typically a jump host or a remote support portal in the DMZ.

The baseline rules:

• Remote access should not be permanent. Each session must be approved, with a defined time window
• Strong authentication (MFA) for VPN connections or the access portal
• Session limited to the network segment and assets the vendor needs to work on
• Session recording or at minimum connection/disconnection event logging
• Periodic review of vendor accounts: deactivation of those no longer needed

Many documented OT incidents trace back to a remote access left open, with shared credentials or no expiry. Segmentation alone is not enough if the remote entry point is not governed.

Engineering workstations

Engineering workstations are the most powerful systems on the OT network: they hold development software, PLC projects, the ability to upload firmware and modify control logic. Separating them from production traffic is one of the most effective measures available.

In practice, this means:

• A dedicated VLAN for engineering workstations, with access rules to the control level restricted to the necessary protocols (e.g. TIA Portal communication to Siemens PLCs on specific ports)
• No direct Internet access from engineering workstations
• No use of engineering workstations for email, web browsing or office tasks
• Regular backup of projects and configurations

In many plants, engineering workstations are still general-purpose PCs with access to everything. Separating them is an intervention with real impact on risk reduction, even without overhauling the rest of the network.

OT firewalls: what to expect and what not to

A firewall between OT zones does not work like a traditional IT firewall. In industrial environments, traffic is often more predictable — specific protocols, regular flows, stable connections — but the constraints are different.

Factors to consider when selecting and positioning an OT firewall:

• Latency — some industrial protocols (Profinet, EtherNet/IP with CIP, Modbus TCP) are latency-sensitive. The firewall must be sized to avoid introducing delays that affect the control cycle
• Industrial protocols — a firewall that only filters by IP and port is not sufficient for protocols like S7comm, OPC UA or Modbus TCP. Firewalls with industrial DPI (Deep Packet Inspection) can inspect payloads and apply application-level rules, but they must be tested on the actual plant
• Deployment mode — in many cases, the firewall is deployed in transparent (bridge) mode to avoid changing the existing IP addressing, which reduces the impact on the plant
• Failover — a firewall failure must not stop production. Fail-open mode (allowing traffic through on failure) and hardware redundancy should be evaluated case by case, balancing security and operational continuity
• Management and logging — the OT firewall management console should sit in the DMZ or at level 3, not on the IT network. Logs must be collected and stored in a way that supports troubleshooting and auditing

Not every plant needs a firewall with industrial DPI. For many architectures, a well-configured stateful firewall with tightly defined rules, combined with properly configured VLANs, already provides a meaningful level of protection.

VLANs: useful but not sufficient

VLANs are the most common mechanism for segmenting industrial networks. They are relatively easy to implement on managed switches, require no additional hardware and allow broadcast domain separation.

However, VLANs alone are not a complete security measure:

• A VLAN separates traffic at layer 2, but without ACLs or a firewall at layer 3, inter-VLAN routing can undermine the separation
• If the switch is misconfigured (unprotected trunks, VLAN hopping), the separation is fragile
• VLANs do not provide traffic inspection: they cannot see what is inside the packets
• Without port authentication, anyone with physical access to a port can join a VLAN

Best practice is to use VLANs as the segmentation foundation and add controls at the transit points: firewalls between critical VLANs, ACLs on layer-3 switches, and explicit rules for inter-VLAN flows.

Industrial protocols and segmentation: real-world constraints

Not all industrial protocols behave the same way when it comes to segmentation. Some practical aspects that influence architectural decisions:

• Profinet — operates at layer 2 (Ethernet), so PLCs and Profinet remote I/O must be in the same VLAN or broadcast domain. Segmenting between a PLC and its Profinet I/O is not feasible without specific proxies or gateways
• EtherNet/IP — uses TCP/UDP over IP, so it can traverse routers and firewalls. Segmentation between controllers and EtherNet/IP devices is possible, but firewall rules must account for implicit ports and multicast traffic
• Modbus TCP — a straightforward protocol on TCP port 502, easily filterable. But it has no native authentication: anyone who can reach the port can read and write registers. Segmentation is especially important to limit who can communicate with Modbus devices
• OPC UA — supports native authentication and encryption, but correctly configuring certificates and trust stores is not trivial. Segmentation helps reduce the exposed surface even when OPC UA is properly configured
• OPC DA (DCOM) — requires dynamic ports and DCOM configurations that make firewall filtering complex. Where possible, migrating to OPC UA simplifies segmentation

Before segmenting, you need a map of the protocols in use and the actual communication flows. Without this map, the risk is cutting off communications that the process depends on.

Common segmentation mistakes

A realistic operational sequence

Segmenting an existing OT network is not a weekend project. It requires a gradual path that is compatible with operational continuity.

The mapping phase is the most important. Many segmentation projects fail because they start with firewall configuration without understanding the actual traffic flows. On plants with complex traffic patterns, a passive listening phase — using network analysis tools or mirror ports on switches — can reveal flows that nobody had documented.

How much to segment: balancing security and operability

Perfect segmentation does not exist. Or rather, it exists on paper, but in production it must contend with real-world constraints:

• Legacy devices that do not support VLAN tagging or have addressing limitations
• Limited downtime windows for network changes
• Maintenance staff who need rapid access during emergencies
• Integrators and vendors with specific connectivity requirements during commissioning
• Budget and resource constraints

The right level of segmentation depends on acceptable risk, process criticality and the ability to manage the added complexity. Overly granular segmentation that nobody can maintain is worse than simpler segmentation that is properly managed.

A practical criterion: every segmentation rule should have an owner who understands it, knows why it exists and knows how to change it when needed.

Documentation: the weak point of many projects

A segmented network without up-to-date documentation quickly becomes a problem. Firewall rules accumulate, VLANs multiply, exceptions become the norm, and after a few years nobody knows why certain rules exist.

The minimum documentation should include:

• An updated network diagram with zones, VLANs, firewalls and access points
• A table of permitted flows between zones, with protocol, ports and justification
• A list of firewall rules with creation date, purpose and owner
• A maintenance access register: who connects, to what, when
• A change management procedure for segmentation changes

Periodic rule review — at least every six months on critical plants — helps eliminate obsolete rules, verify that the segmentation still reflects the actual architecture and identify drift.

Segmentation and regulatory frameworks: IEC 62443, NIS2, NIST

Network segmentation is not just a best practice: it is explicitly or implicitly referenced by several frameworks and regulations relevant to the industrial sector.

• IEC 62443 — the zone and conduit concept underpins the entire security architecture of the standard. Part 62443-3-3 defines system requirements, including network separation and flow control
• NIS2 — the directive requires proportionate risk management measures, including technical network protection measures. Segmentation is one of the most tangible ways to demonstrate a structured approach to OT security
• NIST SP 800-82 Rev. 3 — the NIST OT security guide devotes considerable attention to segmentation, industrial firewalls and IT/OT network separation, with detailed architectural examples

None of these sources prescribes a single architecture. All converge on the need to separate, control flows and document decisions. The implementation detail depends on the specific context.

Our perspective

OT network segmentation is not a project you do once and forget. It is an ongoing process of understanding flows, defining boundaries and managing exceptions. Plants change, vendors are added, lines are modified, and the network must evolve accordingly.

The most common issue we see on existing plants is not the absence of firewalls or VLANs. It is the absence of a clear rationale behind the rules: why a particular flow is open, who requested it, when it was last reviewed. Without that discipline, even a well-designed architecture degrades over time.

The most useful segmentation is not the most complex one, but the one that the plant team can understand, manage and maintain over time.

Official resources and useful references

• ISA/IEC 62443 — Industrial automation and control systems security standards
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
• Directive (EU) 2022/2555 (NIS2) — official EUR-Lex text
• CISA — Industrial Control Systems
• ENISA — ICS/SCADA Security