Reading IEC 62443 as a Device Maker: Zones, Conduits and Security Levels

IEC 62443 is often described as an industrial cybersecurity standard, which is accurate and unhelpful. It is a series covering three different roles — asset owner, system integrator and product manufacturer — and most of the confusion around it comes from people reading the parts written for somebody else's job.

If you build devices, the parts addressed to you concern how you develop and what your product can do. Everything about operating a plant, segmenting a live network, or maintaining a security programme belongs to the asset owner, and reading those first produces the impression of an impossibly broad obligation. Narrowing to the manufacturer parts makes the scope tractable.

The distinction between Maturity Levels and Security Levels is the one worth internalising early because they certify different things. A Maturity Level certifies your development process — that you have a defined secure development lifecycle, that you handle vulnerabilities through a process rather than through whoever notices, that the process is documented and followed. A Security Level certifies what a product or system can actually do. A vendor can have an excellent process and a product that is deliberately simple, and those are separate claims that customers will ask for separately.

The four Security Levels are best read as a description of who you are defending against rather than as a quality ranking. SL 1 addresses casual or accidental misuse. SL 2 addresses a deliberate attacker with simple means and low motivation. SL 3 assumes sophisticated means and specific intent. SL 4 assumes extended resources and high motivation — a state-level adversary. Claiming a level is claiming your device holds up against that class of attacker, and the honest question during design is which one your customers actually face.

Zones and conduits are the architectural concept that most changes how a device gets specified. A zone groups assets with the same security requirements; a conduit is the controlled path between zones. The consequence for a product is that your device will be placed inside a zone and expected to communicate only through defined conduits, so a device that opens outbound connections to arbitrary internet endpoints for telemetry is awkward to place. Designing so that all communication goes through a configurable, documented set of endpoints and protocols is what makes a product easy for an integrator to deploy.

The practical starting point is not the standard but your customer's tender documents. The requirements that matter commercially are the ones being asked for now, and they are usually a specific Security Level for a specific product category, plus evidence of a secure development process. That tells you which subset to work on first, which is a far better guide than trying to absorb a multi-part standard in order.