The Wrong Starting Point
Most industrial cybersecurity programmes begin with a technology question: which security product should we install on the OT network? This is the wrong starting point. Before any technology selection is made, the zone architecture must be defined — and zone architecture is primarily an operational question, not a technical one.
IEC 62443 provides the framework: security zones are groups of assets with common security requirements, and conduits are communication paths between zones. Defining zones requires answering the question: which assets have the same operational trust requirements and the same consequences if compromised? The answer is determined by operational function, not by network topology.
Zone Design Principles
The fundamental principle of IEC 62443 zone design is that security level requirements (SL1 through SL4) are assigned to zones based on the consequence of a security failure. An SL1 zone requires basic protection against unintentional errors. An SL4 zone requires protection against sophisticated, state-actor-level attacks.
In practice, most industrial environments operate with three to five zones: a safety instrumented systems zone (typically SL3 or SL4), a process control zone (SL2-SL3), a supervisory/SCADA zone (SL2), an operations network zone (SL1-SL2), and an enterprise zone (SL1). The exact zoning depends on operational function and consequence analysis — not on what IEC 62443 recommends abstractly.
Conduit Specifications
Conduits — the communication paths between zones — are where zone architecture decisions become engineering specifications. Each conduit requires a defined communication protocol, a defined data flow direction (unidirectional or bidirectional), a defined list of permitted communication pairs, and a defined security control (firewall, data diode, protocol gateway, or encrypted tunnel).
The most common conduit design failure is over-permissiveness: conduits are specified with broader access rules than the operational use case requires, because it is easier to open access than to explain why it is restricted. Over-permissive conduits are the principal attack vector in documented industrial cyber incidents. The operating principle should be: define the minimum communication required for the operational function, then specify the conduit to permit exactly that and nothing more.
The Operational Constraints
Industrial OT environments impose constraints on cybersecurity implementation that enterprise IT environments do not. Change control in operational environments is managed against production schedules — security patches cannot be applied on a standard IT patch cycle if that cycle requires rebooting a process control system during production. Remote access requirements for vendor support have availability characteristics that standard enterprise VPN solutions may not meet. Encryption overhead on time-critical control traffic may violate process control timing requirements.
These constraints are not reasons to avoid security measures. They are reasons to design security measures that work within operational constraints rather than import IT security policies wholesale. An IEC 62443 implementation that is operationally unworkable will be worked around by the operational team — which is worse than no security measure at all.
The Organisational Question
The technical architecture of IEC 62443 zone design is well-defined. The organisational question is less well-addressed in the standard: who owns the security of the OT network? In most industrial organisations, IT security teams have the security expertise and OT operations teams have the operational expertise. Neither has both. The IEC 62443 implementation programme requires explicit agreement on responsibilities — which team owns which zone, who approves conduit rule changes, who responds to security events. These agreements must be reached before the technical implementation begins, not during it.