Key takeaways
- IEC 62443 is a phased program, not a one-night switch-over.
- You cannot protect what you cannot see — start with an asset inventory.
- Zones and conduits are the core idea: group assets, control the traffic between them.
- Monitor before you enforce — learn normal traffic before blocking anything.
- Apply changes inside maintenance windows with a tested rollback.
Why “without breaking production” is the real constraint
OT networks were built for availability and determinism, not for security patches mid-shift. A control that drops a single Modbus or OPC-UA packet at the wrong moment can stop a line. So the goal is not maximum security on day one; it is steadily raising the security posture without ever surprising the process. IEC 62443 is designed for exactly this: it is risk-based, layered and incremental.
The implementation sequence
Follow the order below. Each step makes the next one safe.
- Inventory the assets. Identify every PLC, HMI, drive, gateway, historian and engineering workstation, with firmware versions and communication paths. Passive discovery first, so you don’t perturb the network.
- Define zones and conduits. Group assets by function and criticality into zones; define the conduits (the controlled connections) between them. This is the heart of IEC 62443.
- Assess risk and set target SL. Assign each zone a target security level based on consequence, not convenience.
- Monitor before controls. Deploy passive monitoring to baseline normal traffic, then alert on deviation — learn before you block.
- Apply least-privilege access. Role-based access, named accounts, no shared engineering logins, and segmented remote access.
- Enforce in maintenance windows. Introduce firewalls/segmentation and tightened rules during planned downtime, one zone at a time, with rollback ready.
Zones, conduits and security levels
| Concept | What it is | Practical example |
|---|---|---|
| Zone | A grouping of assets sharing security requirements | A cell’s PLCs and HMIs as one zone |
| Conduit | The controlled communication path between zones | Firewalled link from cell zone to the historian zone |
| Security Level (SL) | Target protection strength for a zone (SL 1–4) | SL 2 for a standard cell, higher for safety-critical |
| Least privilege | Access limited to what a role strictly needs | Operators read; engineers write; no shared admin |
Monitor before you control
The most common way to “break production” is to enforce a rule before you understand normal traffic. Start in listen-only mode. Capture which devices talk to which, on what protocols and at what cadence, for long enough to cover a full production cycle. Only when you can describe normal with confidence should you turn a monitoring rule into a blocking rule — and even then, one conduit at a time.
Make every change reversible
Each enforcement step needs a tested rollback: a saved configuration, a known-good firewall ruleset, and a defined “abort” criterion the maintenance team agrees on before the window opens. If a change misbehaves, you revert in minutes, not hours.
Common mistakes that do break production
The teams that stop a line while “improving security” tend to repeat the same few errors. Avoid them deliberately.
- Active scanning on a live OT network. IT-style aggressive scans can knock fragile PLCs offline. Use passive discovery first.
- Enforcing before baselining. Blocking traffic you never observed in monitor mode is how legitimate machine-to-machine flows get cut.
- Big-bang segmentation. Introducing every firewall rule at once leaves you no clean way to tell which change caused a fault. Go one conduit at a time.
- No rollback agreed in advance. Without a tested revert and a defined abort criterion, a misbehaving rule becomes an outage instead of a non-event.
- Shared engineering logins left in place. They defeat least privilege and erase the audit trail the standard expects.
Where a platform fits
IEC 62443 demands identity, access control and an audit trail on the OT side — exactly the controls that are painful to hand-wire device by device. A governed platform supplies device identity, role-based access and a tamper-evident audit trail consistently across the fleet, so your zones and conduits are enforced by configuration rather than by tribal knowledge. That also makes the next audit far cheaper, because evidence is generated continuously instead of reconstructed. For how this connects to scaling a deployment, see the IIoT pilot-to-scale guide; for the data-path standards underneath, see OPC-UA vs MQTT in OT.
Where Fundamentum fits
IEC 62443 demands device identity, role-based access and an audit trail on the OT side — painful to hand-wire device by device. Fundamentum, our Canadian IoT platform, supplies one governed control plane that enforces those controls by configuration across the whole plant, with a SOC 2 Type II audit trail that makes the next audit cheaper, so scaling from one cell to the whole site is configuration, not re-engineering. See the platform →
Frequently asked questions
What are zones and conduits in IEC 62443?
A zone is a grouping of assets that share security requirements — for example a cell’s PLCs and HMIs. A conduit is the controlled communication path between zones, such as a firewalled link from the cell to the historian. Segmenting into zones and controlling the conduits between them is the core of the standard.
How do I avoid stopping production during implementation?
Work in order and never enforce blindly. Inventory passively, baseline normal traffic in monitor-only mode, then apply segmentation and rules one zone at a time inside planned maintenance windows, each with a tested rollback. OT networks are availability-first, so a single dropped OPC-UA packet at the wrong moment can stop a line — incremental change is the safeguard.
Why monitor before applying controls?
Because enforcing a rule before you understand normal traffic is the most common way to break production. Start in listen-only mode, capture which devices talk to which and how often across a full production cycle, and only convert a monitoring rule into a blocking rule once you can describe normal with confidence.
What is a Security Level (SL)?
A Security Level (SL 1 to 4) is the target protection strength assigned to a zone, set by the consequence of compromise rather than by convenience. A standard cell might target SL 2; a safety-critical zone targets higher. Setting target SLs first lets you prioritise controls where they matter most.
Where does least-privilege access fit?
Least privilege limits each role to exactly what it needs: operators read, engineers write, no shared admin or engineering logins, and segmented remote access. It is one of the highest-value, lowest-disruption steps because it tightens security without touching the control logic itself.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
