Zones and conduits are the core organizing model of the IEC 62443 family of industrial cybersecurity standards - a formal, standards-based way to group assets into security zones and to control the traffic that flows between them through defined conduits. Where general segmentation is a good practice, zones and conduits give it a rigorous framework with security requirements and design steps attached. This guide explains what a zone is, what a conduit is, how the two structure an OT network, and how the model relates to the broader idea of segmentation.
Zones and Conduits in one line: In the IEC 62443 standards, a zone is a grouping of assets that share common security requirements, and a conduit is a defined communication path that carries traffic between zones and is itself secured and controlled. The model works by assigning every asset to a zone, requiring that any communication between zones pass through an explicit conduit, and setting security expectations for each zone and conduit based on the risk to what it protects. It is the standards-based framework that turns the general practice of segmentation into a structured, requirement-driven design.
A zone in the IEC 62443 sense is a logical or physical grouping of assets that belong together because they share the same security needs. Assets are placed in the same zone when they have a similar level of criticality, trust, and required protection, and are separated into different zones when they do not. The point of drawing zone boundaries is that everything inside a zone can be treated as sharing a common security posture, while everything crossing between zones is treated as needing scrutiny. A safety system, a supervisory network, and an enterprise system would typically belong to different zones because their security requirements differ sharply.
A conduit is the controlled pathway through which zones communicate. Rather than letting zones talk to each other freely, the model requires that any inter-zone communication travel through a defined conduit, which is itself a managed and secured element with its own requirements. A conduit groups the communications between zones so that they can be protected, monitored, and restricted as a unit - it is the guarded doorway between rooms, not just the absence of a wall. Traffic that does not belong in a conduit is not supposed to cross between zones at all.
The power of the model is that it forces every asset and every cross-boundary flow to be accounted for. Each asset must live in a zone; each inter-zone flow must travel through a conduit; and each zone and conduit carries security requirements matched to what it protects. This turns a vague sense that 'the control network should be separated' into a concrete map of which assets are grouped, which flows are permitted, and what protection each boundary must provide - a structure you can review, audit, and hold a design against.
Designing with zones and conduits starts by partitioning the system under consideration into zones according to risk and function, then identifying every communication path that must cross zone boundaries and defining a conduit for each. The result is an explicit architecture: a set of zones, the assets in each, the conduits between them, and the traffic each conduit is allowed to carry. Anything not represented as a conduit is, by design, not permitted to cross - which makes the deny-by-default posture a structural property rather than a matter of remembering to write a firewall rule.
The model pairs naturally with a risk-based approach to how strongly each zone and conduit must be protected. A zone containing safety-critical control assets warrants stronger protection than a zone of general business systems, and the conduit connecting a high-trust zone to a lower-trust one must be secured to bridge that gap safely. This lets effort be concentrated where the consequences are greatest, rather than spread uniformly, and it gives a defensible rationale for why a particular boundary is hardened the way it is.
Because the zone-and-conduit structure is explicit, it also becomes the basis for ongoing governance. New assets have to be assigned to a zone, which forces a decision about their security requirements. New communication paths have to be expressed as conduits, which forces a decision about whether and how they should be allowed. This discipline resists the slow drift toward a flat, everything-talks-to-everything network, because adding an unmanaged path is no longer a quiet change but a visible violation of the documented model.
Zones and conduits are the standards-based framework that sits behind the general practice of segmentation. Segmentation is the broad idea of dividing a network into isolated parts; the zone-and-conduit model is the formal method for doing so with defined groupings, controlled pathways, and risk-matched requirements. An operation can segment its network informally, but applying the IEC 62443 model gives that segmentation a rigorous, auditable structure and a common vocabulary shared with the wider industry.
Cloud SCADA fits into this structure as a set of zones connected by carefully defined conduits. Field control assets form their own zone or zones; the supervisory and monitoring functions form another; and the path that carries telemetry from the field to a cloud platform is a conduit that must be secured and controlled. When a platform such as Merobix collects data over device-initiated outbound connections, that conduit is shaped so traffic flows outward from the field zone to the cloud without opening an inbound path into the control zone - a conduit design that respects the higher trust required inside the field zone.
For oil and gas operators, thinking in zones and conduits clarifies what is often a messy, grown-over-time network. Mapping which assets belong to which zone and which conduits legitimately connect them exposes flows that should not exist and boundaries that were never really enforced. It also makes the security case for a monitoring architecture explicit: the field control zone stays tightly protected, the conduit to the cloud is defined and controlled, and the whole arrangement can be reasoned about against a recognized standard rather than defended by ad hoc rules.
A zone is a grouping of assets that share common security requirements, such as all the devices in a control network that need the same level of protection. A conduit is the defined, secured communication path that carries traffic between zones. In short, zones are the protected groupings and conduits are the controlled doorways between them, and any communication crossing from one zone to another is supposed to travel through a conduit.
Segmentation is the general practice of dividing a network into isolated parts, while zones and conduits are the IEC 62443 standards-based framework for doing that with defined groupings, controlled pathways, and risk-matched security requirements. The zone-and-conduit model turns informal segmentation into a rigorous, auditable structure: every asset must belong to a zone, every inter-zone flow must pass through a conduit, and each carries protection matched to its risk.
Forcing inter-zone traffic through defined conduits means every cross-boundary flow is accounted for, secured, and monitored as a managed element, and anything not represented as a conduit is not permitted to cross at all. This makes deny-by-default a structural property of the design rather than something you have to remember to configure, and it resists the slow drift toward a flat network where everything can talk to everything else.
Primary references from the standards bodies and regulators that define this topic:
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.