IEC 62443 security zones are logical groupings of assets with similar security requirements and risk profiles. IT network segments and VLANs are implementation mechanisms. They are related, but they are not the same thing and rarely map 1:1 in brownfield industrial environments.
What an IEC 62443 zone actually is
Under IEC 62443, a zone is defined by:
- Common security requirements (e.g., SL 1 vs SL 3)
- Similar risk exposure and impact if compromised
- Functional roles (e.g., safety systems, basic control, historian)
- Trust level and required degree of isolation
Zones are therefore an abstract, risk- and function-based construct. They exist before you decide how to implement them in IP addressing, VLANs, firewalls, or ACLs.
How zones relate to IP subnets and VLANs
Network segments and VLANs are common ways to enforce separation between zones, but the relationship is flexible:
- 1 zone ↔ many VLANs / subnets: A safety zone might span several VLANs (e.g., geographically separate units) that share identical security requirements and policies.
- Many zones ↔ 1 VLAN / subnet: In legacy plants, different systems with different risk levels may coexist in one flat VLAN, but you can still logically define multiple zones inside it and enforce separation with host firewalls, ACLs, or gateway devices.
- Nested/logical zones inside a segment: A DMZ or jump host segment might host assets that support multiple zones, separated by firewall rules and strict access policies, not by VLAN alone.
In a greenfield design, you will often align “one major zone per subnet or VLAN” for simplicity and traceability. In brownfield environments, especially with long qualification cycles, you frequently end up with zones that do not neatly align with existing network boundaries.
Conduits vs VLANs and routing
IEC 62443 defines conduits as controlled communication paths between zones. In implementation terms, conduits usually map to:
- Firewall rulesets and security policies between IP networks
- Access control lists on routers and layer 3 switches
- VPNs, jump hosts, or application proxies between trust levels
A conduit is about the policy set and trust boundary, not the specific technology. A single physical link or trunk carrying multiple VLANs might include traffic for several conduits; equally, a single logical conduit (e.g., OT-to-historian traffic) might be implemented by several paths and devices.
Practical patterns in regulated, brownfield plants
In real industrial environments you will commonly see:
- Legacy flat OT networks: One large VLAN or subnet spanning many controllers and HMIs, where you define zones conceptually first and then progressively enforce isolation through firewalls, switch ACLs, and endpoint controls during upgrades.
- Segmented core, flat cells: Each production line or cell sits in its own VLAN, but that VLAN still contains multiple logical zones (basic control, safety, engineering workstations). Here, you often introduce internal firewalls, access controls, or strict host hardening to separate zones.
- Shared infrastructure zones: Historians, jump servers, antivirus servers, and backup systems may serve several zones. They often live in their own zone (e.g., OT services zone) with defined conduits to production zones and to the IT network.
In aerospace and other highly regulated sectors, fully refactoring the network to make zones perfectly align with VLANs is often not feasible due to:
- Validation and qualification burden for critical systems
- Downtime constraints on high-utilization assets
- Integration complexity with existing MES/ERP/QMS stacks
- Long lifecycles of PLCs, safety systems, and test stands
As a result, you typically layer zoning on top of existing segments, then converge gradually as equipment is refreshed.
Key design and documentation considerations
When relating zones to network segments and VLANs, it is important to:
- Start with the logical zone model: Define zones based on risk, function, and security requirements before deciding on VLAN boundaries.
- Create an explicit mapping: Maintain diagrams and configuration references that show how each zone maps to subnets, VLAN IDs, firewall interfaces, and conduits. This is critical for traceability and audits.
- Be clear about shared segments: Where multiple zones share a VLAN or subnet, document the compensating controls (host firewalls, ACLs, jump hosts, strict hardening) and their limits.
- Align with change control and validation: Changes to VLANs, routing, or firewall rules that affect zones should follow formal change control, with impact assessment on validated systems and associated documentation.
- Plan for stepwise migration: For legacy OT networks, define a roadmap to progressively align critical zones with dedicated VLANs or network segments as assets are replaced or revalidated.
Typical pitfalls
Common mistakes when equating zones with VLANs include:
- Assuming “one VLAN = one zone” without verifying that all assets in the VLAN share the same security level and risk profile.
- Relying solely on VLANs for security, without proper L3/L4 controls, monitoring, and hardening.
- Ignoring non-IP paths (serial, fieldbus, vendor remote access tools) that create cross-zone connections outside VLAN boundaries.
- Failing to update zone-to-VLAN mapping when network changes are made, breaking traceability for audits and incident response.
How this plays with IT/OT coexistence
In mixed IT/OT environments, you will usually end up with:
- Distinct IEC 62443 zones for enterprise IT, DMZ/bridge, and multiple OT levels (e.g., site, area, cell)
- Multiple IT subnets and VLANs mapping into a single high-level “IT zone” from an OT perspective
- Dedicated conduits between IT and specific OT zones, implemented as firewall policies, application proxies, or tightly controlled data diodes
The key is to treat VLANs and network segments as tools used to implement the zone and conduit model, not as the model itself. The zone definition should remain stable even if you later refactor the underlying network, as long as the security characteristics and trust boundaries are preserved.
