Ask ten OT engineers to sketch the zones and conduits of their own plant and you will get ten different drawings. Some will be Purdue levels with boxes around them. Some will be a VLAN map. A few will be a firewall rule export pasted into Visio. Every one of them will be partly right, and that is exactly the problem.

Zones and conduits are the most quoted idea in IEC 62443 and probably the least consistently applied. The definitions fit on a sticky note. The hard part is deciding where the boundaries go, what each boundary has to enforce, and how to write it down so an auditor, an operations manager and a firewall admin all read it the same way.

This Blog skips the theory-only tour. After a short recap of the rules, we work through four industrial examples (a discrete manufacturing plant, a water utility with remote sites, a process facility with a safety instrumented system, and a remote access scenario that causes trouble in nearly every sector). Each one shows the zones, the conduits, a realistic target security level (SL-T) and the controls that go with it. If you are a CISO, an OT security lead or an engineer who has to defend a segmentation design in front of the board, this is written for you.

What are zones and conduits in IEC 62443?

A zone is a grouping of logical or physical assets that share the same security requirements. A conduit is the controlled communication path between zones, and it carries its own security requirements too. That is the short answer, and it is the answer to put on a slide.

The longer answer matters because of one word: shared. Assets sit in the same zone because the same level of protection suits all of them, not because they happen to live on the same switch or the same floor. A zone can be physical (everything inside a locked substation building), logical (all safety controllers regardless of location), or a mix. And no traffic is supposed to move between zones except through a conduit that has been defined, justified and secured.

The modelling rules people get wrong

The ISA Global Cybersecurity Alliance, which sits close to the ISA99 committee that wrote the standard, publishes a useful set of modelling rules. These are the ones that cause the most confusion in practice:

• A zone can contain sub-zones. A Level 2 control zone can be split into a safety sub-zone and a motion-control sub-zone without breaking the model.

• A conduit cannot contain sub-conduits. If you find yourself nesting conduits, you probably have two conduits that should be documented separately.

• Assets talk to the outside world only through conduits. If a device has a path that is not in your conduit list (a cellular modem, a forgotten serial link, a USB port used for updates), your model is incomplete.

• One asset, one zone, many conduits. A single PLC belongs to one zone but can terminate ten or more conduits: to its HMI, to a peer PLC, to a historian, to an engineering workstation, to a vendor tool.

• A conduit is not only a network. It can be a single Ethernet cable, a set of VLANs and firewall rules, a serial line, a wireless link, or even a removable-media procedure. If data can cross, it is a conduit.

Where zones and conduits sit in the IEC 62443 series

One reason teams stumble is that the concept is spread over several documents. Here is the map:

• IEC 62443-1-1 defines the terminology and the seven foundational requirements.

• IEC 62443-2-1 covers the asset owner's security management programme, which is where governance and change control for your zone model live.

• IEC 62443-3-2 (Security risk assessment for system design, published June 2020) is the document that tells you how to partition a system into zones and conduits.

• IEC 62443-3-3 (System security requirements and security levels) lists the technical requirements a system must meet to reach a given security level.

• IEC 62443-4-1 and 4-2 cover the secure development lifecycle and the technical requirements for individual components, such as a PLC or a managed switch.

IEC's own catalogue summarises 62443-3-2 as the part that establishes requirements for defining the system under consideration (SUC), partitioning it into zones and conduits, assessing risk for each, setting a target security level for each, and documenting the resulting security requirements. Notice the order. Partitioning comes before the detailed risk assessment, and the result of the assessment can send you back to repartition. The catalogue also lists a stability date of 2027 for the current edition, so a review cycle is on the horizon and it is worth keeping an eye on.

The 62443-3-2 workflow, translated into plain steps

The standard breaks the work into seven zone and conduit requirements (ZCR 1 to ZCR 7). Most published guides stop at "identify, group, assign levels". In practice the workflow looks like this:

Security levels: the number attached to every zone and conduit

Each zone and conduit gets a target security level, written SL-T. The standard defines four levels above "no specific requirements", and they describe the type of adversary the zone should withstand:

Three abbreviations trip people up, so fix them in your head early. SL-T is the target you set for a zone or conduit. SL-C is the capability a component or system can deliver when configured correctly (a property of the product). SL-A is the level you actually achieved once it is installed and operated. A purchase order that says "SL 3 firewall" gives you an SL-C claim. It does not give you an SL-A. Your SL-A depends on configuration, rule hygiene, monitoring and the people who run the thing.

Under 62443-3-3, security capability is organised around seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. For conduit design, the restricted data flow family is the centre of gravity. SR 5.1 (network segmentation) and SR 5.2 (zone boundary protection) are the ones you will cite most often, and SR 5.2 includes enhancements for deny-by-default, island mode and fail-close behaviour.

Example 1: A discrete manufacturing plant

Take a mid-sized automotive component plant with three production lines, a plant-level MES, a historian, and a corporate network that wants production data. The usual starting point is a flat network with a firewall at the edge and a few VLANs that were never meant as security boundaries. Here is a zone model that works without a full rebuild.

Now the conduits. This is the part most documents leave vague, and it is where the real security work happens:

What this design gets right. Splitting Level 2 into one zone per line is the single biggest improvement. When ransomware or a misconfigured laptop lands in Line 2, lateral movement into Line 1 now has to cross a conduit that somebody designed, monitors and owns. A flat "Level 2" zone gives you no such friction.

Example 2: A water utility with remote pump stations

Water and wastewater operators have a different shape of problem. One treatment plant, a central SCADA system, and a dozen or more unmanned remote sites connected over cellular or radio. The remote sites are small, numerous and physically exposed. Their budgets are small too.

The interesting design decision is the remote site template. Rather than modelling twelve zones and twelve conduits, you define one zone type and one conduit type, then record which sites instantiate them and any deviations. This is how 62443 stays workable for estates with hundreds of small sites.

The conduit nobody can see: the carrier network

The conduit from a remote site to central SCADA runs over a network you do not own. Treat the carrier as untrusted and secure the conduit end to end:

1. Use a private APN or equivalent so site modems are not reachable from the public internet.

2. Encrypt the link with IPsec or an equivalent tunnel, which supports the communication integrity and confidentiality requirements (SR 3.1 and SR 4.1) of 62443-3-3.

3. Terminate at a head-end firewall in its own conduit boundary, with rules that allow only the SCADA front-end to poll remote devices on the specific protocol in use.

4. Where the protocol supports it, enable authentication at the protocol layer as well, so a compromised tunnel does not equal full command authority.

5. Log and alert on any new device, new source address or new function code appearing on the conduit.

In February 2021, an operator at the water treatment plant in Oldsmar, Florida, watched a remote access session move his cursor and try to raise the sodium hydroxide setpoint to a harmful level. The operator noticed and reversed it. The lesson for zone design is less about that single event and more about the pattern: a remote access conduit that reaches process control with little friction means a single stolen credential can sit one click away from a physical consequence. Which brings us to the next example.

Example 3: A process facility with a safety instrumented system

Oil and gas, chemicals and power plants all share a structure worth studying: a basic process control system (BPCS), a safety instrumented system (SIS), a fire and gas system, and a growing number of vendor packages such as compressors and turbines with their own controllers.

IEC 62443-3-2 explicitly calls for separating certain asset groups when you partition the SUC. Safety-related systems are the clearest case, along with devices that connect through untrusted networks and equipment that gets connected only temporarily. Following that, a sensible zone structure is:

• BPCS zone (SL-T 2 or 3): distributed control system controllers, operator stations, historian interface.

• SIS zone (SL-T 3): logic solvers, safety I/O, and the SIS engineering workstation in a sub-zone of its own.

•  Fire and gas zone (SL-T 3): detectors, controllers, panels.

•   Package unit zones (SL-T 2): one per vendor skid, because vendor support access differs for each.

•  Process DMZ (SL-T 3): the broker between the process networks and the rest of the site.

The conduit that deserves the most attention is BPCS to SIS. Operators need to see SIS status on their screens, so some data has to cross. But writing to the SIS from the BPCS side should be impossible by design, not just disallowed by policy. A common approach is a read-only gateway or a one-way link for status data, combined with a physical key switch or hardware mode control on the SIS controllers so that program changes need someone standing at the cabinet.

The Triton malware incident at a Middle East petrochemical facility in 2017 is the textbook reminder. The attackers reached the SIS engineering workstation and then the safety controllers. Where an SIS engineering station can be reached from the wider control network, the safety layer stops being independent of the thing it is meant to protect.

Example 4: Remote access, the conduit every sector gets wrong

Remote access shows up in every example above, and it deserves its own treatment because it so often becomes the weakest conduit in an otherwise careful design. Vendors need to support equipment. Engineers want to fix things from home. Managed service providers want a standing tunnel.

Under zones and conduits thinking, remote access is not a tool. It is a conduit class with a defined path, defined endpoints and defined controls. A defensible design has these properties:

• Terminates in the DMZ. Remote users never land directly in a control zone. They authenticate to a gateway or jump host in the industrial DMZ, and the onward session is a second, separate conduit.

• Multi-factor authentication on the first hop, with identities that are individual and attributable. Shared vendor accounts fail this immediately.

• Approval and time limits. The session is enabled for a task and a window, then closed. Persistent tunnels are an exception that needs an owner and an expiry date.

• Session recording and monitoring on the second hop, because that is the one that touches the process.

• Protocol and target restrictions. Remote desktop to a named engineering workstation, not network-layer access to a whole VLAN.

• A clear kill switch. Operations staff must be able to cut the conduit without raising an IT ticket.

SR 1.13 in 62443-3-3 (access via untrusted networks) and the restricted data flow requirements give you the standard's vocabulary for all of this. The practical test is simple: could an attacker with one stolen vendor password reach a controller? If the honest answer is yes, the conduit is not finished.

How to choose SL-T without guessing

Many teams set every zone to SL 2 "because it feels right", or every zone to SL 3 "to be safe". Both are shortcuts that undermine the point of the standard. A more defensible approach is to work through four questions for each zone and conduit:

1. What is the worst realistic consequence if this zone is manipulated or lost: injury, environmental release, regulatory breach, lost production, quality escape?

2. Who could plausibly attack it and how motivated are they? A water utility and a defence-related manufacturer do not face the same adversary.

3. What countermeasures already exist, and how well do they work in practice rather than on paper?

4. What residual risk is the asset owner willing to carry, and has someone with the authority to accept it actually signed?

As a working rule of thumb, a conduit should not be weaker than the most sensitive zone it terminates in. A cheap link into an SL 3 zone makes the zone an SL 3 in name only. When budgets force a compromise, record it as a risk acceptance, with an owner and a review date, instead of quietly lowering the number.

The zone and conduit register: what to document

A diagram is not documentation. Auditors, new engineers and incident responders need a register they can query. At a minimum, capture the following for every zone and conduit:

Eight mistakes that undermine zone and conduit projects

1. Treating Purdue levels as zones. The Purdue model is a useful first draft. It is not a risk-based zoning, and a single "Level 2" zone covering an entire plant is rarely justified by a risk assessment.

2. Giant zones. If one zone holds assets with very different consequences, it will be secured to the lowest common denominator or over-secured at great expense.

3. Conduits as allow-any rules. A firewall sitting between two zones with an any-to-any rule is a decoration, not a conduit.

4. Ignoring non-IP conduits. Serial links, wireless, USB sticks and laptops moving between zones all carry data. Put them in the model, or attackers will do it for you.

5. Confusing SL-C with SL-A. Buying a certified component does not make a zone secure. Configuration and operations decide that.

6. No owner, no change process. A model that nobody updates after a plant expansion goes stale within months.

7.  Designing in isolation from operations. If operators cannot explain the zones, they will find workarounds. A good test is whether the people who run the plant can describe the model without a long briefing.

8. Skipping the sign-off. Without ZCR 7 approval, risk acceptance is implicit, and implicit risk acceptance tends to surface after an incident.

Implementing zones and conduits in a live plant

Few teams get to design a plant from scratch. Most work on brownfield environments that cannot stop. A sequence that respects uptime:

1. Build the asset and flow inventory first. Passive network monitoring helps here because it observes real communication without touching controllers. Expect surprises.

2. Draft zones on paper, validate with operations, then agree the first three or four conduits to harden. Start with IT to OT and remote access, since they carry the highest exposure.

3. Deploy in monitor mode. Place the enforcement points, observe traffic for weeks, build the allow-list from what is genuinely required, then switch to blocking in planned windows.

4. Handle lateral zones last. Line-to-line and cell-level segmentation takes more engineering and is easier once the perimeter conduits are stable.

5. Measure and review. Track rule counts, exceptions, new devices and denied flows. Review the model after every significant change and at least once a year.

How Shieldworkz supports zone and conduit programmes

Zones and conduits succeed when architecture, visibility and operations move together. Shieldworkz works as a single partner across that chain: OT security assessments and 62443-aligned risk assessments to define zones, conduits and SL-T; platform capabilities for asset visibility and monitoring of conduit traffic; and services that carry the design through implementation and into day-to-day operation across SCADA, OT and IIoT environments. If you want a second pair of eyes on an existing segmentation design, or a structured way to start one, our team can help you scope it.

Frequently asked questions

1.What is the difference between a zone and a conduit in IEC 62443?

A zone groups assets that share security requirements. A conduit is the controlled communication path between zones. Zones describe what you protect; conduits describe how protected assets are allowed to talk.

2.How many zones should an industrial plant have?

There is no fixed number. The right count comes from the risk assessment. Small sites might have five or six zones, while a large process plant can have dozens. The test is whether each zone holds assets with similar consequence, access and lifecycle.

3.Is the Purdue model the same as zones and conduits?

No. Purdue is a reference architecture that organises functions into levels. Zones and conduits are risk-based and often cut across those levels. Purdue is a handy starting draft, and most mature designs split individual levels into several zones.

4.Which part of IEC 62443 covers zones and conduits?

IEC 62443-3-2 covers the method for partitioning a system and assessing risk. IEC 62443-3-3 provides the technical requirements and security levels, and IEC 62443-1-1 defines the concepts and foundational requirements.

5.What is the difference between SL-T, SL-C and SL-A?

SL-T is the target level you set for a zone or conduit. SL-C is what a product or system is capable of. SL-A is what you have actually achieved once everything is installed and operated.

6.Can zones and conduits be applied to an existing plant?

Yes. Most real projects are brownfield. Start with asset and traffic discovery, define zones around the highest-consequence assets, harden the IT to OT and remote access conduits first, and extend the model in stages.

Conclusion

The strength of zones and conduits is that they make segmentation a conversation about consequence rather than about network hardware. Start with the system boundary, group assets by what they do and what would happen if they failed, set a target level you can defend, and treat every conduit as something designed, owned and monitored. Do that, and the examples above stop being case studies and become templates for your own sites.