OT Network Segmentation: Best Practices for ICS and SCADA Security

OT network segmentation is one of the highest-impact controls you can implement in an industrial environment, but it is also one of the easiest to get wrong. Most critical infrastructure networks evolved over decades, with flat Layer 2 domains, vendor remote access exceptions, and “temporary” routes that never got removed. The result is predictable: a compromise in IT, an engineering workstation, or a remote access path becomes a fast lateral movement problem in OT.

This guide focuses on practical industrial network segmentation that reduces blast radius while respecting uptime and safety constraints. We will use IEC 62443 zones and conduits as the organizing model, then translate that model into implementable network and firewall policies, including microsegmentation in OT where it makes sense. We will also cover how to validate segmentation realistically without touching production systems, using approaches like digital twins and simulated attack-path validation discussed in How Digital Twins Enable Safe, Comprehensive OT Security Testing and why this matters compared to traditional approaches in Why Traditional OT Security Assessments Risk Production Downtime. For broader context, see the Complete Guide to OT Security: Protecting Industrial Control Systems.

What OT network segmentation means (and what it is not)

Definition: OT network segmentation is the design and enforcement of communication boundaries between industrial assets and functions, so that only required traffic flows are allowed between defined security zones. In practice, segmentation combines network architecture (VLANs, routing domains), enforcement points (firewalls, layer-3 switches with ACLs, data diodes, remote access gateways), and policy (which hosts, ports, and protocols are permitted).

Segmentation is not just VLANs. VLANs without Layer 3 controls are primarily an organizational tool. Segmentation is also not “air gapping,” which is rarely complete in modern operations due to remote support, patch distribution, historians, and engineering workflows.

The goal is to constrain lateral movement and reduce the chance that a single foothold becomes a safety, reliability, or production incident. Done well, segmentation also improves manageability by clarifying ownership and dependencies: what must talk to what, and why.

Why segmentation is different in OT than in IT

Industrial control systems have constraints that change how you design and deploy segmentation:

Availability and safety are dominant. Security controls must not introduce unpredictable latency or packet loss, especially for time-sensitive control traffic and safety systems.
Protocol behavior is atypical. Many ICS protocols are chatty, unauthenticated, and sensitive to inspection or resets. Firewall timeouts and deep packet inspection can break things if tuned incorrectly.
Asset lifecycles are long. You may be segmenting legacy PLCs and Windows hosts that cannot be upgraded or patched quickly.
Operational reality matters. Engineers need to program PLCs, vendors need remote access, and data must flow to historians and MES. Segmentation that ignores these workflows will be bypassed.

Because of these factors, “industrial network segmentation” should be treated as a risk engineering exercise, not a generic network hardening checklist.

Use IEC 62443 zones and conduits to structure the architecture

IEC 62443 zones and conduits is a practical way to turn a messy OT network into an understandable security model.

Zones: Group assets with similar security requirements and similar consequence of compromise. Common OT zones include:

Safety instrumented system (SIS) zone
Basic process control system (BPCS) control zone (PLCs/DCS controllers)
HMI and operator workstation zone
Engineering workstation and tooling zone
OT DMZ (services that broker OT and IT data)
Vendor remote access zone
Site services zone (backup, patch staging, time servers)

Conduits: The controlled communication paths between zones. A conduit should have explicit enforcement points and a documented set of allowed flows.

Key design principle: define zones around function and consequence, not just IP ranges. For example, engineering workstations often need broader access than HMIs, so they should be separated even if they sit in the same control room.

If you already have an “OT network architecture” diagram, reframe it into zones and conduits, then use that model to drive firewall policy, routing decisions, and remote access patterns.

OT segmentation best practices you can implement without breaking operations

The following practices are consistently effective in real plants and substations.

Build an OT DMZ that is more than a VLAN

Place brokers and integration services in an OT DMZ and terminate IT to OT communications there. Typical DMZ components include historians (or historian replicas), jump hosts, file transfer services, patch staging, and monitoring collectors. Avoid direct IT to control-zone routing.
Separate engineering from operations

Engineering workstations are high-risk because they handle project files, firmware tools, USB media, and vendor utilities. Put them in a dedicated zone and require controlled pathways to controllers. If feasible, require a jump workflow into the engineering zone rather than allowing ad-hoc access from general OT.
Use “deny by default” at zone boundaries, then add explicit allow rules

Start with default deny for inter-zone traffic at the firewall or L3 boundary. Then build allow rules based on documented dependencies: source, destination, ports, and, where possible, application identifiers.
Make remote access a designed conduit, not an exception

Vendor access should terminate in a remote access zone (or a dedicated gateway in the OT DMZ) with strong authentication, session recording where possible, and time-bound access approvals. Avoid inbound access directly to HMIs or engineering workstations.
Prefer simple, robust controls over fragile inspection

In many ICS environments, a well-tuned stateful firewall with strict allowlists is safer than complex deep inspection that may mis-handle proprietary protocols. Where inspection adds value, test it carefully and tune timeouts and session limits.
Treat wireless, cellular, and temporary networks as separate zones

These paths often bypass your intended conduits. Segment them, restrict routes, and monitor aggressively.
Do not forget management planes

Switch management, hypervisors, backup interfaces, and out-of-band access should be isolated. A flat management network becomes a pivot point.

These practices align closely with “ics network segmentation” and “scada network segmentation” objectives: reduce lateral movement, preserve determinism, and make data paths intentional.

Microsegmentation in OT: where it helps and where it hurts

Microsegmentation in OT can mean host-based controls (agent-based) or network-enforced segmentation at a fine granularity (per cell, line, or asset group). It can provide strong containment, but it must match operational maturity.

Where microsegmentation helps:

High-consequence assets or lines where containment is critical
Standardized cells with repeatable designs (packaging lines, skids)
Environments with stable traffic patterns and good asset inventory

Where it can hurt:

Highly dynamic maintenance workflows or frequent reconfiguration
Legacy endpoints that cannot run agents and rely on broad connectivity
Sites without clear ownership for rule lifecycle management

Practical approach: start with macro zones and well-defined conduits, then add microsegmentation around crown-jewel assets and common attack pivots (engineering stations, domain services in OT, remote access endpoints). If you cannot explain who will maintain the rules and how exceptions get approved, the design will degrade over time.

OT firewall best practices for zones and conduits

Firewalls are usually the primary enforcement mechanism for industrial network security zones. A few design choices matter more than brand selection:

Policy design

Write rules in terms of zones, not individual IPs, when feasible. Use object groups for maintainability.
Constrain by destination first. “Any to PLC subnet” is usually too broad.
Prefer one-way patterns where possible (OT to IT via replication), and tightly control inbound.

State and timeouts

Tune session timeouts for ICS protocols. Default TCP timeouts can cause unexpected behavior.
Be careful with aggressive IPS features that may reset sessions.

High availability

Design for fail-safe behavior that aligns with process risk. In some cases, fail-open may be selected for safety, but it must be a conscious decision with compensating controls.

Logging and evidence

Ensure you can export rule hit counts and logs. Segmentation that cannot be measured is hard to improve.

Change control

Integrate firewall changes into operations: planned windows, rollback procedures, and validation tests.

These are “ot firewall best practices” specifically tuned for OT realities: stable allowlists, minimal surprise, measurable enforcement, and controlled change.

A step-by-step methodology to design and validate segmentation

Use the following framework to go from concept to enforceable, testable segmentation.

Step 1: Identify crown jewels and worst-case consequences

Define the assets and functions whose compromise would create safety risk, environmental impact, or major production loss: SIS, controller networks, recipe management, batch control, etc.

Step 2: Build a zone map aligned to operations

Draft zones around function and consequence: operations, engineering, controllers, safety, DMZ, remote access, site services. Keep it understandable for both OT and network teams.

Step 3: Document required conduits as “minimum viable flows”

For each conduit, list the minimum set of required communications. For example: HMI zone to controller zone on required ports; engineering zone to controller zone during maintenance only; OT historian replication to IT.

Step 4: Implement enforcement points incrementally

Start at the highest-value boundaries: IT to OT via DMZ, remote access into OT, and engineering to control. Use staged rollouts and narrow scopes.

Step 5: Validate with attack-path thinking, not just connectivity tests

Connectivity tests confirm production still works. Security validation confirms an attacker cannot pivot.

Can a compromised HMI reach engineering tools?
Can a vendor session pivot into other cells?
Can IT credentials reach OT domain services?

This is where many programs stall, because validating attack paths safely is hard on production systems. Frenos focuses on validating segmentation and attack paths using realistic simulated testing without touching production, using approaches described in Platform 3.0 Simulated OT Penetration Testing for Industrial Environments and grounding the work in OT testing considerations discussed in OT Penetration Testing for ICS & SCADA.

Step 6: Operationalize: monitor, measure, and refine

Track rule usage and remove unused permissions
Detect new routes and unmanaged conduits
Re-validate after major changes (new line, new vendor access method, new firewall policy)

Segmentation is not a one-time project. Treat it as a control that needs continuous verification.

FAQs

Will OT network segmentation disrupt production?

It can if deployed without staged change control and validation. The risk is highest when rules are built from assumptions instead of observed dependencies. A safer approach is incremental enforcement at key boundaries (OT DMZ, remote access, engineering to control) with pre-change baselining, clear rollback, and validation that includes both process functionality checks and security-focused attack-path tests.

Is segmentation better than a traditional OT pentest?

They solve different problems. Segmentation reduces the likelihood and impact of lateral movement by design. A pentest can demonstrate exploitability and identify pathways that your segmentation should block. The most effective approach is to use realistic attack-path validation to prove that segmentation actually contains a compromise, ideally without requiring intrusive testing on production systems.

How long does an OT segmentation project take?

Initial high-value segmentation improvements can often be implemented in phases, starting with the OT DMZ and remote access conduits, then moving deeper into cell and area segmentation. Timelines depend on network complexity, change windows, and the quality of existing diagrams and asset inventory. Expect iterative cycles: design, implement, validate, refine.

Do we need perfect asset inventory and data to start?

No, but you do need enough information to define zones and the most critical conduits. Start with crown jewels, key user workflows (operations, engineering, vendors), and major data paths (historian, MES, patching). Where data is incomplete, document assumptions and prioritize targeted collection to increase confidence before enforcing strict rules.

What is the difference between IEC 62443 zones and conduits and VLANs?

Zones and conduits are a security model that describes trust boundaries and controlled communications based on function and risk. VLANs are a network mechanism that can help implement that model, but VLANs alone do not enforce policy. The enforcement comes from routed boundaries, firewalls, ACLs, and controlled remote access paths that implement the conduits.

Call to Action

OT network segmentation works when it is designed around real operational workflows, enforced at clear boundaries, and validated against realistic attack paths. If you want to confirm that your current zones, conduits, and firewall rules actually contain compromise without putting production at risk, request an OT Security Assessment with Frenos.

OT Network Segmentation: A Practical Guide for ICS and SCADA Environments