IEC 62443, Industrial Automation and Control Systems Security.
IEC 62443 is the IEC and ISA standard series for the security of industrial automation and control systems, developed by the ISA99 committee and published jointly as ISA/IEC 62443. It gives an operating company a shared language for partitioning a plant into zones and conduits, assigning a security level to each, and defining what an asset owner, system integrator, product supplier, and service provider each must deliver so a control system is protected without redesigning the process itself.
What IEC 62443, Industrial Automation and Control Systems Security means.
IEC 62443 exists because a control system built to run a process safely and reliably is not automatically built to resist a deliberate intrusion, and retrofitting security plant-wide, after the fact, is far more expensive than designing it in. The series, developed by the ISA99 committee and published jointly by the IEC and ISA, breaks the problem into pieces that match how a project is actually staffed: general concepts and terminology, requirements for the operating company that owns and runs the system, requirements for the engineering team that designs and integrates it, and requirements for the vendors who build the products that go into it. Rather than one blanket security level for a whole plant, it starts from an asset inventory, groups equipment into zones that share a security requirement, and defines the conduits, the communication paths between those zones, so that a system integrator can show which requirement applies where and an auditor can check the design against a documented boundary rather than a plant-wide assumption.
What the standard covers.
IEC 62443 is the joint IEC and ISA standard series for the security of industrial automation and control systems, developed by the ISA99 committee. It does not replace a control system's process design, and it does not tell an engineer how to size a relief valve or verify a safety instrumented function; it addresses a separate question, how the system that runs the process is protected against unauthorized access, tampering, and disruption. The series is organized in parts rather than one document, because the people who own a plant, the team that integrates its control system, and the vendors who supply its products all need different things from it. A controls engineer meets it most often through the asset owner's security program, through the zone and conduit model used at the design stage, and through the security level a client specifies for a package of equipment.
Zones and conduits, the core concept.
The series groups a facility's assets into zones, and it groups the communication paths between those zones into conduits. A zone is not necessarily a room or a cabinet; it is a set of assets that share a security requirement, such as every controller running the basic process control system, or every workstation an engineer uses to configure it. A conduit is what carries traffic between two zones, a network segment, a serial link, a removable-media procedure, and it is the conduit that a security requirement is actually enforced against, since that is where traffic can be inspected, filtered, or blocked. Grouping equipment this way lets a design assign different requirements to different parts of the same plant instead of applying one blanket rule everywhere, and it gives an auditor a documented boundary to check rather than a plant-wide assumption.
Security levels: target, achieved, and capability.
A security level, SL, describes how resistant a zone or a conduit is meant to be, on a scale from SL 1, protection against casual violation, to SL 4, protection against a well-resourced, motivated attacker, above a baseline SL 0. The series separates three uses of the same number. The target security level, SL-T, is what the asset owner decides a zone needs, set from a risk assessment. The achieved security level, SL-A, is what the as-built system actually delivers once verified against the target. The capability security level, SL-C, is what a product can support out of the box, before it is configured into a system. A component's SL-C does not guarantee its zone's SL-A; the achieved level depends on configuration, integration, and maintenance.
The roles the series addresses.
IEC 62443 is written around four roles rather than one audience. The asset owner is the operating company that runs the facility and carries responsibility for the security program across its life; 62443-2-1 sets out what that program has to cover. The system integrator designs and assembles the control system for a specific project, reading the parts covering risk assessment and system-level requirements, 62443-3-2 and 62443-3-3, to turn the asset owner's target security levels into a partitioned zone and conduit design. The product supplier builds the components, controllers, workstations, network equipment, that go into that design, following the parts addressing secure product development and component-level technical requirements, 62443-4-1 and 62443-4-2. A service provider commissions, maintains, or supports the system after handover, addressed separately from the asset owner's own program. No single role reads the whole series end to end.
Why an accurate asset inventory comes first.
Every zone and conduit decision starts from knowing what is actually on the system, and that lands on the same documents a controls engineer already produces. The instrument index and the I/O list name every field device and every signal a controller reads or drives; the network and architecture drawings show every controller, workstation, historian, and switch, and how they connect. Without that inventory a zone boundary is a guess rather than a documented grouping. IEC 62443 does not decide how a plant separates its safety instrumented system from its basic process control system; that separation is an IEC 61511 requirement already in place. What IEC 62443 adds is a security layer on top, treating the SIS and the BPCS as zones in their own right and defining the conduit between them as one more boundary to document.
IEC 62443 roles and the parts each reads
The four roles the series addresses, and the family of parts written for each. Only part numbers clearly assigned to a role are named here.
| Role | Family of parts it primarily reads | What that part covers, in general terms |
|---|---|---|
| Asset owner | 62443-2-1 | The security program the operating company runs across the life of the facility |
| System integrator | 62443-3-2 and 62443-3-3 | The zone and conduit risk assessment used to partition the system, and the security requirements assigned to the resulting design |
| Product supplier | 62443-4-1 and 62443-4-2 | The secure development process a supplier follows, and the technical requirements a component must meet |
| Service provider | Addressed in a separate part of the series | Requirements for commissioning, maintenance, and support after handover, distinct from the asset owner's own program |
Zones, conduits, and security levels
The core vocabulary of the system-level parts, one line each.
| Term | Definition | Defined in |
|---|---|---|
| Zone | A grouping of assets that share the same security requirements | 62443-3-2 |
| Conduit | The communication path connecting two zones, itself assessed and protected | 62443-3-2 |
| Security level, SL 1 to SL 4 | The capability of a zone or conduit to resist a defined class of adversary, above a baseline SL 0 | 62443-3-3 |
Common questions
What IEC 62443 covers compared with IEC 61511.
Is IEC 62443 a certification.
What is a zone and a conduit in IEC 62443.
What do SL-T, SL-A, and SL-C mean.
Who is responsible for what under IEC 62443.
What does a zone assessment need from the controls engineering team.
Run it on your drawings.
Upload a drawing set, get every document populated and classified, export to the format your team uses.