OT Network Segmentation for Brownfield Plants

An illustrative scenario, typical of what we see in brownfield plants rather than a description of any one site.

An engineering manager at a mid-sized food and beverage plant opens the cyber insurance renewal questionnaire and stops at one question: “Is the operational technology network segmented from the enterprise network? Attach the zone diagram and firewall rulebase.” The honest answer is “partially.” The plant runs a single VLAN carrying PLCs, HMIs, engineering laptops, the MES and a vendor jump box an integrator installed in 2014. There is no zone diagram. The firewall rulebase belongs to IT and has not been reviewed in three years.

This guide is for that position. OT network segmentation in a brownfield plant is not a product purchase. It is a phased program, grounded in the Purdue Model and IEC 62443 zones and conduits, executed on live equipment without dropping production. Below: what segmentation means in practice, where the Purdue Model bends on a twenty-year-old site, how zones and conduits become a real zone map, where the industrial DMZ belongs, when to use VLANs, firewalls or physical separation, how remote access fits, the six-phase migration that keeps the line running, and the pitfalls that sink these projects.

What OT Network Segmentation Means in Practice

OT network segmentation divides the plant network into zones of shared function and risk, then controls how data moves between those zones through defined conduits. The conduits are enforced by firewalls, by managed switches configured with VLANs, or by physical separation. A segmented plant network has a zone diagram, a firewall rulebase and a written policy that names what can talk to what. A flat network has none of those.

The priorities differ from enterprise IT. In a corporate network, confidentiality usually leads, then integrity, then availability. In OT, availability leads, integrity follows and confidentiality comes third. The inversion rules out certain controls. An IT team might accept a 30-second authentication delay on a server. A controls engineer cannot accept a 30-second delay on a command to a packaging line. Segmentation designs that ignore this fail at the first production incident.

Brownfield sites make the work harder for reasons that do not show up in vendor slides. Older PLCs and network modules do not tolerate the broadcast load a modern enterprise switch absorbs without effect. Protocols older than authentication (serial DNP3, Modbus, unauthenticated CIP) still carry production traffic. OEM support contracts often assume a specific network topology, and some vendors push back hard when their equipment is moved behind a firewall they did not specify. These constraints are why a segmentation design that takes weeks on a greenfield pilot takes nine to eighteen months to implement on a running plant.

The stakes are not theoretical. Incident-response firms that publish ICS annual reviews consistently name flat or poorly segmented networks among the most common findings, and US government guidance on defending operational technology, such as the joint CISA, FBI, EPA and DOE primary mitigations published in May 2025, lists segmenting critical systems and a demilitarized zone between OT and the enterprise among its core recommendations. Insurance carriers know both, and the cyber questionnaire is often where a plant first sees the gap between what it has and what the market now expects. In our OT network assessments, segmentation is also an uptime measure: the same flat network that lets an attacker move freely lets a broadcast storm or a looped switch take down every line at once.

The Purdue Model Applied to a Brownfield Site

Almost every OT segmentation conversation uses the Purdue Enterprise Reference Architecture as its vocabulary. Vendors, integrators, auditors and insurers all reach for Purdue levels when discussing where systems sit and how they connect:

• Level 0: the physical process (tanks, conveyors, packaging lines, instruments)
• Level 1: basic control (PLCs, RTUs, safety controllers)
• Level 2: supervisory control (HMIs, SCADA, engineering workstations)
• Level 3: site operations (MES, historian, batch management)
• Level 3.5: the industrial DMZ
• Levels 4 and 5: the enterprise business network and beyond

Mapping a real plant to these levels is where the first surprises appear. A ControlLogix sits at Level 1. A FactoryTalk View SE server and an engineering laptop running Studio 5000 sit at Level 2. A historian and the MES sit at Level 3. So far, so textbook. Then the documentation drifts. The “Level 3” MES pulls tags directly from a Level 1 PLC over EtherNet/IP, because that is how the original integrator wired it. A vendor jump box has a static route to the Level 2 engineering workstations, because the OEM’s remote-diagnostics tool needed it. A maintenance laptop that lives on the business network was allowed onto a Level 1 VLAN so a technician could troubleshoot from the office. None of these paths appear on the architecture diagram, because the diagram was drawn from intent and the plant was built from necessity.

This is the central truth of brownfield segmentation: the target architecture is not useful until the team documents the architecture the plant actually runs. Passive traffic capture at each level, an asset inventory reconciled against that capture, and a protocol inventory (EtherNet/IP, PROFINET, Modbus TCP, S7comm, OPC UA and the OEM protocols a plant accumulates over twenty years) are the real prerequisites. The protocol mix matters because each protocol has different firewall inspection support, different broadcast behaviour and different tolerance for the latency a segmentation device adds. Current-state documentation is the most skipped step, and the largest single cause of overruns.

Where the Purdue Model strains is the assumption that data flows level by level. Modern architectures cross levels directly: a PLC publishing to a cloud historian, an analytics service writing setpoints back to an HMI. The levels still work as categories for reasoning about trust and function; the strict hierarchy does not. NIST SP 800-82 Revision 3 handles this by offering the Purdue model, ISA-95 levels and a three-tier IIoT architecture as alternative ways to organise segments, with a DMZ as the enforcement boundary between them. Its firewall guidance is the practical rule: permit connections only between adjacent levels, so Level 4 devices never talk directly to Level 2, 1 or 0, and make outbound rules from the control network as strict as inbound ones. For how those levels map onto a whole small or medium plant, from the switch backbone and VLANs down to machine networks, see our OT network architecture design guide.

IEC 62443 Zones and Conduits: The Vocabulary Auditors Use

Where Purdue gives a mental map, IEC 62443 gives a design framework and the language the auditor uses. The ISA/IEC 62443 series defines the zone and conduit model, security levels SL 1 to SL 4, and the risk assessment that turns a zone map into target security levels.

A zone groups assets that share the same security requirements, trust level and operational function. A conduit is the controlled communication path between two zones. The firewall is not the zone; it enforces the conduit.

IEC 62443-3-3 defines four security levels. SL 1 protects against casual or accidental violation. SL 2 protects against intentional violation by simple means with low resources and generic skills. SL 3 protects against sophisticated means with moderate resources and ICS-specific skills. SL 4 protects against sophisticated means with extended resources and high motivation. Many brownfield plants set SL 2 as the baseline, target SL 3 for safety systems and critical utilities, and document the residual risk for anything that cannot reach its target within the budget.

A defensible brownfield zone design commonly looks like this:

• Safety zone. Independent of every control zone. Safety logic solvers and safety I/O. Connected to control zones only through a tightly audited conduit, or not at all.
• A control zone per production line or area. PLCs, HMIs and local supervisory systems for one logical area. Conduits to site operations pass through a firewall that understands the industrial protocols.
• Site-operations zone. MES, historian, batch management and the engineering workstations that span several control zones.
• Industrial DMZ. Level 3.5. Jump hosts, historian replicas, patch repositories and any service a business-side consumer would otherwise reach into Level 3 to use.
• Enterprise conduit. The path from the DMZ to the business network, denied by default and permitting only the specific services the DMZ exposes.

The IEC 62443-3-2 risk assessment drives the security-level targets. It is a written document: each zone, the threats against it, the tolerable consequences, the existing controls, and the gap between current and target level. It is the document the auditor asks for by name.

A common trap is treating IEC 62443 as a certification goal. Certification is worth discussing for specific sites in regulated industries. For most brownfield manufacturers, the value of 62443 is the design vocabulary and the risk assessment, not the certificate. A plant with a defensible zone diagram, a conduit inventory, a zone risk assessment and firewall rules that enforce the conduits is ahead of most of its peers, certified or not.

Where the Industrial DMZ Sits and Why

Level 3.5 exists because the alternative is worse. Without an industrial DMZ, either Level 3 systems reach directly into the business network or business systems reach directly into Level 3. The DMZ is the broker zone that lets both sides exchange the data they need without a direct conduit between them.

What belongs in the DMZ is whatever translates between the plant and the business. Historian replicas are the most common resident: business users query a replica rather than the production historian. Patch repositories sit there, because Level 2 and Level 3 systems should not reach out to the internet for updates; they pull from a local server validated against the OEM-approved patch list. Antivirus management consoles, remote-access jump hosts, and gateways that expose specific OT data to IT consumers (an OPC UA gateway, an API in front of the historian) also belong in the DMZ.

What does not belong matters as much. Domain controllers shared with the enterprise do not; the safer pattern is a separate OT Active Directory forest with a one-way trust, or none. Engineering workstations do not, because they need to reach Levels 1 and 2 to do their job. Nothing in the DMZ should open outbound internet connections except through a policy-enforced proxy.

For a plant with no DMZ today, two retrofit patterns are both valid. A pair of firewalls in a screened-subnet arrangement (one between Level 3 and the DMZ, one between the DMZ and the business network) gives defense in depth at both boundaries. A single modern firewall with dedicated DMZ interfaces and strict per-interface policy is faster to deploy and works well for small and mid-sized sites. NIST SP 800-82 Revision 2 drew both arrangements (a firewall with a DMZ, and paired firewalls); Revision 3 is less prescriptive about the arrangement and focuses on the DMZ’s role as an enforcement boundary between segments.

For the few plants where even a well-built DMZ is not enough, unidirectional gateways (data diodes from vendors such as Waterfall Security or Owl Cyber Defense) let data flow out of OT and physically prevent anything flowing in. They cost more than a firewall, constrain the architecture to one-way flows, and are the right answer only when the threat model justifies them.

VLAN, Firewall and Physical Segmentation: When to Use Each

VLANs, firewalls and physical separation do different jobs. Confusing their strengths is the most common reason a design passes a peer review on paper and fails a penetration test.

VLANs work at Layer 2 of the OSI model. They separate broadcast domains on a shared switch fabric. They are cheap: most managed industrial switches support them at no extra cost, and configuring them is a switch-level task. They are right for separating functions that share infrastructure but should not see each other’s broadcasts: controller-to-I/O traffic from HMI traffic, engineering workstations from operator stations, vendor devices from everything else. On their own, VLANs are not a security boundary. VLAN hopping, trunk misconfiguration and a device plugged into the wrong access port all break them. A design that stops at VLANs is not segmented in the sense an auditor means. It also depends on managed switches; a plant still full of unmanaged switches has that problem to solve first.

Firewalls work at Layer 3 and above. Stateful inspection blocks traffic that does not match a permitted session. OT-aware firewalls (from Fortinet, Palo Alto Networks, Cisco, Hirschmann Tofino and Moxa, among others) also inspect industrial protocols such as CIP, Modbus TCP, S7comm, DNP3 and OPC UA, so the policy can tell a permitted read from an unauthorized write. Firewalls are the real trust boundary between zones. The rules are written deliberately, reviewed by the controls engineer and the security engineer together, and validated against captured traffic before the firewall goes into the production path.

Physical separation means two networks that share no switch, no cable path and no routing. It is cheap in capital and expensive to operate, because there is more infrastructure to patch, monitor and audit. It is right for safety networks that must not be routable, for some standalone validated systems in regulated industries, and for any zone where the cost of a firewall misconfiguration exceeds the cost of the extra hardware.

The three side by side:

	VLANs	Firewalls	Physical separation
Works at	Layer 2: broadcast domains on a shared switch fabric	Layer 3 and above: stateful sessions, and industrial protocols on OT-aware products	No shared switch, cable path or routing
Capital cost	Low: a configuration task on managed switches	Hardware, plus rule design, review and validation	Low in capital
Operating cost	Low	Rule reviews, validation against captured traffic	High: more infrastructure to patch, monitor and audit
Security boundary?	No. VLAN hopping, trunk errors and a wrong access port break it	Yes: the real trust boundary between zones	Yes, the strongest
Use it for	Separating functions inside a zone: controller-to-I/O from HMI traffic, engineering from operator stations, vendor devices from everything else	Enforcing every conduit between zones	Safety networks that must not be routable, some validated systems, zones where a firewall error costs more than extra hardware
Fails when	It is the only control, or the plant still runs unmanaged switches	It does not understand the protocol it filters, or rules are not reviewed	The budget for patching, monitoring and audit was never planned

A mature brownfield design uses all three. Inside a control zone, VLANs separate functional traffic. Between the control zone and site operations, a protocol-aware firewall enforces the conduit. Around the safety zone, physical separation or a one-way gateway is the boundary. The design document names which tool enforces each conduit and why. On Rockwell sites, our page on Stratix switching and segmentation covers the switch side in more depth.

The practical rule: a firewall that does not understand the industrial protocol it filters is not enforcing a meaningful policy for that protocol. A generic firewall between a PLC and an HMI can allow or deny TCP port 44818 (EtherNet/IP) as a whole. It cannot tell a permitted Logix read from an unauthorized Logix write.

Remote Access in a Segmented OT Design

Remote access is where most segmentation designs leak. A rulebase that is strict at the enterprise boundary but permissive for a vendor’s always-on VPN is not segmented from an attacker’s point of view. Current-state discovery in a brownfield plant routinely turns up remote-access paths that IT did not know about, OT had forgotten, or an OEM installed under a support contract nobody rereads. Settle the remote-access design before the firewalls go into production.

The foundational rule is absolute: no direct remote access from the internet to any OT asset. Every remote session enters through a jump host in the industrial DMZ, authenticates with multi-factor authentication, is authorized for a specific asset and time window, and is recorded.

Patterns that hold up under audit. A Remote Desktop Services or Citrix tier in the DMZ with MFA, per-session access and recording covers general engineering and vendor use. Dedicated OT remote-access products (Claroty Secure Remote Access, Cyolo, BeyondTrust Privileged Remote Access, Xona and others) add what matters at scale: just-in-time approvals, searchable session recordings, credential injection so shared passwords never leave the vault, and vendor workflows that let a plant approve a two-hour window without the vendor ever holding the credentials.

Patterns that fail audits. TeamViewer or AnyDesk on a controls workstation for convenience. Vendor VPN clients on an OEM appliance with credentials shared across a support team. Site-to-site tunnels to a vendor data centre, opened for one project and never closed. Passwords in spreadsheets. Temporary firewall holes for a commissioning vendor that became permanent.

OEM support contracts deserve their own attention. Many assume direct connectivity to the vendor’s equipment, and the assumption is often written into the contract. Renegotiating remote access through the plant’s jump host can take months, so start before the segmentation project, not after. When an OEM refuses, the options are to change vendors at the next refresh, pay for a support tier that accepts jump-host access, or accept documented residual risk and monitor the vendor’s sessions closely.

The audit artifacts are not optional: a written remote-access policy, the list of authorized users and vendors with the assets each can reach, session recordings retained to a defined period, a quarterly access review that removes vendors without active contracts, and a break-glass procedure for emergencies.

Phased Migration from a Flat Network

A brownfield plant cannot go from flat to fully segmented in one change window. The migration is a program, and the order matters. Six phases, in sequence, keep production running and give the team a defined rollback at every step.

Phase 1: Document the current state. Asset inventory reconciled against passive traffic capture at every level. Protocol inventory. Existing firewall rules exported and reviewed. Remote-access paths mapped. Done is one document that answers what is on the network, what talks to what, and how it is reached from outside. Typically 4 to 8 weeks. Passive, so no rollback is needed.

Phase 2: Design the target state. Zone map, conduit inventory, security-level targets from the risk assessment, firewall rule skeleton, VLAN plan, remote-access design and change-management plan, reviewed by controls engineering, operations, IT security and the plant manager. Done is a design package signed by the people who will live with it. Typically 6 to 10 weeks.

Phase 3: Build the industrial DMZ in parallel. Firewalls, switches, jump hosts, historian replica and patch repository, stood up without cutting anything over. The DMZ runs empty, then populated, then validated with test traffic. Typically 8 to 12 weeks. Rollback: decommission it; production never routed through it.

Phase 4: Move services into the DMZ one at a time. Historian replica first, because it is read-only from the business side and trivial to roll back. Then the patch repository, the jump host and the antivirus console. Each move is its own change with a named owner and a rollback plan. Done is every business-side consumer pulling from the DMZ instead of reaching into Level 3. Typically 8 to 16 weeks. Rollback: re-enable the direct path.

Phase 5: Firewall the conduits between control zones and site operations. Protocol-aware firewalls go in one control zone at a time, usually during planned downtime, with a rollback of under 30 minutes if a cutover breaks something unexpected. Done is a rulebase enforcing the Level 2 to Level 3 conduits with protocol inspection active. Typically 6 to 16 weeks across all zones. Rollback: a pre-staged bypass back to the previous topology.

Phase 6: VLAN-segment inside the control zones. The riskiest phase, because it touches the switch fabric PLCs and HMIs depend on. One zone at a time, during a shutdown, with every PLC and HMI checked against its new VLAN assignment before the window. Done is Level 1 and Level 2 traffic separated, with VLAN hopping tested and blocked. Typically 8 to 20 weeks across all zones. Rollback: restore the pre-change switch configuration. Engineering laptops need new addressing to reach the re-segmented devices; our guide to connecting a laptop to a plant floor device covers the static-IP basics technicians will use on the day.

The six phases at a glance:

Phase	Done when	Typical duration	Production risk and rollback
1. Document the current state	One document answers what is on the network, what talks to what, and how it is reached from outside	4 to 8 weeks	None: passive, no rollback needed
2. Design the target state	The design package is signed by the people who will live with it	6 to 10 weeks	None: paper only
3. Build the DMZ in parallel	The DMZ is populated and validated with test traffic	8 to 12 weeks	Low: production never routed through it; decommission to roll back
4. Move services into the DMZ	Every business-side consumer pulls from the DMZ instead of reaching into Level 3	8 to 16 weeks	Low: one service at a time; re-enable the direct path
5. Firewall control-zone conduits	The rulebase enforces Level 2 to Level 3 conduits with protocol inspection active	6 to 16 weeks	Moderate: planned downtime per zone; pre-staged bypass, under 30 minutes
6. VLAN-segment inside control zones	Level 1 and Level 2 traffic separated, VLAN hopping tested and blocked	8 to 20 weeks	Highest: shutdown per zone; restore the pre-change switch configuration

Two rules govern the whole sequence. No engineering changes during a migration window: no PLC code changes, no HMI edits, no recipe adjustments. Segment first, change later. Mixing the two produces incidents nobody can attribute, and those are the incidents that get a segmentation program cancelled. Operations holds the veto: the production manager can cancel a cutover on the day if the plant cannot absorb the risk. That authority keeps the program credible over a long execution.

End to end, a single-site program typically runs 9 to 18 months from Phase 1 to the last cutover. The limiting factor is rarely engineering capacity. It is coordination with operations and the availability of shutdown windows. Cost depends on plant size, vendor mix, the condition of the existing network and how much the plant’s own staff can carry. The cheapest way to get a real number is to finish Phase 1, because the current-state document is what the design and the bill of materials are priced from. For the topology and resilience requirements a segmentation program has to respect alongside the security controls, see what a modern plant network requires.

Common Pitfalls in OT Network Segmentation

Six mistakes recur. Naming them before the statement of work is cheaper than rediscovering them inside it.

Designing the target before documenting the current state. The most expensive segmentation projects are the ones that find unknown Level 1 devices after the rulebase is written. Phase 1 is the cheapest work in the program, and skipping it is the most common reason budgets overrun.

Treating VLANs as a security boundary. A VLAN-only design looks defensible on a diagram and fails a penetration test. VLANs separate traffic. Firewalls are the boundary.

Skipping the DMZ to save budget. The DMZ removes every direct IT-to-OT and OT-to-IT path. Plants that skip it usually spend more on point solutions later, and it is the part of the design auditors and insurers weigh most.

Leaving remote access until after the firewalls. Every program finds remote paths the rulebase did not account for. Retrofitting remote access afterwards means temporary holes that become permanent, or a rushed vendor migration. Design it in Phase 2 and build it with the DMZ in Phase 3.

Running cutovers without operations in the room. Changes that surprise operations on the day are the ones that get a program paused. Letting the plant own the change calendar is the cheapest control available.

Declaring victory at go-live. Segmentation is a posture, not a project. Rules drift, new devices appear, vendor arrangements change, and the design document is stale within months. A quarterly rulebase review, a regular asset-inventory reconciliation and an annual update of the zone risk assessment are the difference between a segmented plant and a plant that was segmented once.

Frequently Asked Questions About OT Network Segmentation

What is OT network segmentation?

OT network segmentation divides the plant network into zones of shared function and risk, and controls traffic between those zones through defined conduits. The practical tools are VLANs at Layer 2, firewalls at Layer 3 and above, and physical separation for the highest-risk assets. Most real brownfield designs use all three together.

What is the Purdue Model for ICS?

The Purdue Model is a hierarchical reference architecture that organizes industrial systems into levels, from Level 0 (the physical process) through Level 4 and 5 (enterprise), with the industrial DMZ at Level 3.5. It is the vocabulary most OT segmentation conversations use, even where real data flows no longer follow the strict top-down hierarchy.

What are zones and conduits in IEC 62443?

Zones group assets that share the same security requirements, trust level and operational function. Conduits are the controlled communication paths between zones. IEC 62443-3-3 defines security levels SL 1 through SL 4, and the risk assessment described in IEC 62443-3-2 sets the target level for each zone.

What is the difference between VLAN and firewall segmentation in OT?

VLAN segmentation separates traffic at Layer 2 on a shared switch fabric. It is cheap but is not a strong security boundary by itself. Firewall segmentation works at Layer 3 and above with stateful inspection and, in OT-aware products, inspection of industrial protocols. The firewall is the real trust boundary between zones. Most brownfield plants use both together.

How long does OT network segmentation take for a brownfield plant?

A single-site brownfield segmentation program typically runs 9 to 18 months from current-state documentation through the last cutover, with the riskiest phases tied to shutdown windows. The limiting factor is rarely engineering capacity. It is coordination with operations and the availability of shutdown windows.

Segmentation in a Brownfield Plant Is a Phased Program

The Purdue Model gives the vocabulary. IEC 62443 gives the design framework. NIST SP 800-82 gives the reference architecture. VLANs, firewalls and physical separation are the tools, the industrial DMZ is the pivot, and remote access is where designs leak if it is left for later. The six phases are the sequence that keeps the plant running while the segmentation gets built.

Brownfield segmentation always surfaces surprises the design missed, so plan for them. Take the six phases into the next insurance renewal and the next vendor scoping meeting, and the conversation moves from “do we have segmentation” to “which phase are we in.”

Phase 1 is where Joltek usually starts. Our fixed-scope OT network assessment documents the network as it actually runs, finds what threatens uptime, and ends with a zone-and-conduit segmentation plan and a prioritized remediation list, without selling you the hardware. Where the question is wider than the network, see IT/OT integration and our OT networks overview.