IEC 62443-3-2 is aimed at asset owners and integrators, not at device manufacturers. If you build components, you work with 62443-4-1 and 4-2. Nevertheless, this standard is worth a look — for a very practical reason: your customers use it to make the decisions from which your requirements arise.
The System under Consideration
It starts with a delimitation: what exactly is being considered? The System under Consideration (SUC) is described via its architecture and asset inventory. What does not belong to it is named just as deliberately as what does.
This delimitation is not a formality. Without it, every later discussion negotiates a different subject, and risk statements become incomparable.
The Process in Seven Steps
The standard describes the risk assessment as a sequence of seven requirements, the Zone and Conduit Requirements:
| Step | Content | Result |
|---|---|---|
| ZCR 1 | Identify the SUC | Architecture, asset inventory |
| ZCR 2 | Initial risk assessment | Rough risk picture of the critical processes |
| ZCR 3 | Partition into zones and conduits | Structure with trust boundaries |
| ZCR 4 | Compare with tolerable risk | Decision on how to proceed |
| ZCR 5 | Detailed risk assessment | Assessed risks per zone/conduit |
| ZCR 6 | Cybersecurity Requirements Specification | Derivable requirements |
| ZCR 7 | Approval | Documented, approved state |
Two steps deserve particular attention.
ZCR 3 — the partitioning principle. Zones are not formed along the network topology and not along the org chart. The overarching criterion is explicitly the risk assessment itself: assets with comparable protection needs belong together. A conduit is the controlled communication path between two zones — and because it crosses the trust boundary, it is the place where protective measures take effect.
ZCR 4 — the uncomfortable question. Does the initial risk exceed the tolerable risk? This can only be answered if it has been defined beforehand what counts as tolerable. It is precisely this definition that is missing from most of the analyses we come across. Without it, the entire subsequent prioritization is a matter of taste — and cannot be defended in an audit.
Security Level: Three Letters, Three Meanings
In communication between asset owners and manufacturers, three variants of the Security Level appear that are regularly confused:
- SL-T (Target) — the level aimed for in a zone. The result of the asset owner's risk assessment.
- SL-C (Capability) — the level a component or system is capable of when properly configured. This is the statement about your product.
- SL-A (Achieved) — the level actually achieved in the specific deployment.
The difference has consequences. A customer asks about SL-T for their zone. You can only credibly talk about SL-C — what your device can do. Whether this becomes SL-A in the field depends on integration, configuration and operation, i.e. on factors outside your control. Anyone who does not keep this distinction clean in quotations and documentation regularly promises more than they can deliver.
Why This Determines Your Requirements
The chain is short: the asset owner's risk assessment yields an SL-T per zone. The SL-T yields the requirements for the components in that zone — and those are found in IEC 62443-4-2, organized by the seven Foundational Requirements.
That establishes the connection: what is decided in 62443-3-2 as a zone decision arrives at your desk as a list of requirements. Anyone who understands where this list comes from can do two things that are difficult without that understanding — justify why a requirement does not apply to their own product, and recognize when a customer demands something that the zone, not the device, should actually provide.
The Practical Benefit for Manufacturers
You take three things away from this standard, even though it is not addressed to you:
Your customers' language. Thinking in zones, conduits and SL-T lets you negotiate requirements as an equal instead of working through requirement lists.
The boundary of your responsibility. Some risks are addressed by the zone, not the device. Separating these cleanly protects against excessive commitments — and is at the same time a mark of quality in the documentation.
The template for your own analysis. The sequence from ZCR 1 to 7 is a good framework even when the object of study is not a plant segment but your product: delimit, assess roughly, structure, check against a threshold, deepen, derive requirements, approve.
Sources
This article was originally published in German on the Alsensio Cybersecurity Hub.
