IEC 62443 in Practice: Segmenting an OT Network Without Breaking It

The zone-and-conduit model explained for engineers who need to implement it on a live plant floor, not just read about it.

IEC 62443 gets cited constantly in security audits and almost as constantly misunderstood as a checklist rather than an architecture. The standard's real contribution is the zone-and-conduit model — a way of thinking about network segmentation that maps cleanly onto how plant floors are already physically organized.

What IEC 62443 actually asks for

The standard doesn't mandate specific products or vendors. It asks you to group assets into zones based on shared security requirements and criticality, then explicitly define and control every conduit — every communication path — between those zones. The goal is that a compromise in one zone doesn't automatically propagate to another.

The standard defines security levels (SL 0 through SL 4) describing the sophistication of attacker a zone is designed to resist, from no specific protection (SL 0) up to protection against sophisticated, well-resourced attackers (SL 4). Most plant floor basic control zones target SL 1 or SL 2 in practice; SL 3/4 is typically reserved for critical infrastructure with nation-state threat models.

Defining zones on a real plant floor

In nearly every plant we've segmented, four zones cover the architecture cleanly:

• Enterprise zone: corporate IT, email, ERP — standard IT security practices apply.
• DMZ: the buffer layer where data legitimately needs to cross from OT to IT — historian replication, MES data feeds, vendor remote access gateways. Nothing in the DMZ initiates connections into the control zones below it.
• Supervisory zone: SCADA servers, HMI clients, engineering workstations.
• Basic control zone: PLCs, RTUs, drives, field I/O — the layer where a fault has the most immediate physical consequence.

Some facilities split basic control further into per-line or per-cell zones, particularly where one production line's compromise shouldn't be able to reach another line's controllers. This is worth the extra complexity in any plant where lines run genuinely independent processes.

Conduits and the firewall question

Every conduit between zones should be explicit, documented, and minimal — only the specific ports and protocols actually required, not a general allow-all between subnets. In practice this means an industrial firewall (not just a managed switch with VLANs) sitting at each zone boundary, with rules that someone can actually audit in an afternoon rather than thousands of historical entries nobody remembers adding.

Migrating a live network without downtime

You cannot segment a running plant floor in one cutover without real risk. The approach that's worked reliably across our projects:

1. Passive discovery first: mirror traffic to a monitoring appliance for two to four weeks to map actual communication patterns before writing a single firewall rule.
2. Shadow-mode firewall deployment: install the firewall hardware in log-only mode, alongside the existing flat network, so you can validate the rule set against real traffic without blocking anything yet.
3. Phased cutover by zone: migrate one zone boundary at a time, during a planned maintenance window, with a rollback plan if something legitimate gets blocked.
4. Post-cutover monitoring: run in active mode with verbose logging for at least a full production cycle (including any monthly or quarterly processes) before considering the migration complete.

Common implementation mistakes

Segmentation done well is invisible to operations — production doesn't notice it happened. Segmentation done as a rushed compliance checkbox usually breaks something during the first changeover or firmware update, which is exactly the scenario that gets a security initiative quietly abandoned.