Most people meet IEC 62443 through a customer questionnaire, open the series, find a dozen documents, and quietly close it again. The series is not hard. It is organised by role, and nobody tells you that first.
Four audiences, not one
Before reading any part, decide which of these you are in the transaction at hand. Most organisations are more than one, and the parts that bind you differ:
- Asset owner — you operate the plant.
- Service provider — you integrate or maintain someone else’s automation.
- Product supplier — you build the components or systems others deploy.
- Compliance authority or customer — you are the one asking for the evidence.
The map
The series numbers by group. Once the grouping is visible the rest reads normally:
- 62443-1-x — concepts. Terminology and models. Read 1-1 once, mostly so the vocabulary in every other part stops being ambiguous.
- 62443-2-x — policies and procedures. 2-1 is the asset owner’s security programme. 2-4 is the requirements a service provider has to meet, and it is the part most often demanded of contractors.
- 62443-3-x — system level. 3-2 is risk assessment and the zone-and-conduit design method. 3-3 is the system security requirements and security levels — the part that turns architecture into testable requirements.
- 62443-4-x — product level. 4-1 is the secure development lifecycle a product supplier follows. 4-2 is the technical requirements for the components themselves.
Where to start, by role
Asset owner: 3-2 first, not 3-3. Until the plant is divided into zones and conduits with a stated target security level, requirements have nothing to attach to. Then 2-1 for the programme around it.
Service provider: 2-4, and read it as the checklist your customer will audit you against. Most of it is process evidence rather than technology.
Product supplier: 4-1 for how you develop, 4-2 for what the product must do. If the EU Cyber Resilience Act is on your horizon, 4-1 is doubly worth the effort — it produces much of what Annex I will ask for.
The three security levels people confuse
One distinction saves months of argument later. SL-T is the target you decide a zone needs. SL-C is the capability a product or system can deliver. SL-A is what the installation actually achieves once deployed and configured. A component with SL-C 3 in a zone with SL-T 2, misconfigured, can still achieve SL-A 1. Vendors sell capability; auditors measure achievement.
What certification does and does not prove
A 62443-4-1 certificate says your development process meets the standard. It does not say a given product is secure, and it never says your plant is. Likewise a certified component in an uncertified architecture buys you very little. The value of the series is that it makes those distinctions explicit — which is exactly why customers now ask for the specific part number rather than “are you 62443 compliant”.
We work across all four roles, and we sit on the standards committee. If you are trying to work out which part your customer actually means, that is usually a short conversation.