IEC 62443 explained in brief: it is a series of international standards for the security of industrial automation and control systems (IACS). An IACS is more than devices. It is the people, hardware, software and policies that run an industrial process. The series grew out of the ISA99 committee of the International Society of Automation (ISA) and is published by the International Electrotechnical Commission (IEC), which is why it is often written ISA/IEC 62443. This guide explains how the series is organized, who does what, zones and conduits, and security levels.

What IEC 62443 is for

ISA says the series defines requirements and processes for implementing and maintaining electronically secure IACS, bridging operations and IT, and process safety and cybersecurity. It applies wherever IACS are used: manufacturing and processing plants, utilities such as electricity, gas and water, pipelines, and increasingly building automation, medical systems and transportation.

The difference from office IT is what is at stake. ISA's white paper says an IACS must meet integrity, performance and availability requirements, because losing operational continuity can mean an explosion, a blackout or an incorrect formula or dose of a life-saving medicine. The 62443 requirements are therefore designed not to prevent or disrupt safe operation.

62443 is meant to be used together with ISO/IEC 27001 (the standard for an information security management system, or ISMS). ISA's white paper of June 2025 says 62443 includes no requirements for an ISMS, but the first requirement of Part 2-1 is that the IACS security program is coordinated with any established ISMS. The two standards complement each other, with 62443 adding the details specific to OT (operational technology: systems and devices that monitor or control physical things).

How the series is organized

The IEC groups the parts of the series into four clusters:

  • General (Part 1): concepts, terminology and models common to the whole series, including the seven foundational requirements (Part 1-1)
  • Policies and procedures (Part 2): what people and organizations must do: the asset owner's security program (2-1), a rating of protection (2-2), patch management (2-3) and requirements for service providers (2-4)
  • System (Part 3): technical requirements and risk assessment at system level: security technologies (3-1), risk assessment using zones and conduits (3-2), and system requirements with security levels (3-3)
  • Component (Part 4): the secure product development life cycle (4-1) and technical requirements for each component of a system, such as control devices, host computers, network devices and software (4-2)

Not every part is a full standard. ISA's list also includes technical reports, for example Parts 2-2 and 2-3. The same list gives the edition years, for example Part 2-1 in 2024, Parts 4-1 and 4-2 in 2018, and Part 3-3 in 2013. The parts are updated at different times, so check the current edition on ISA's page or the IEC webstore before citing or buying.

Who does what: the roles in the standard

The series assigns responsibilities by role. ISA calls shared responsibility a founding principle of the standards. A role is not necessarily an organization: one organization can hold several roles, and one role can be split across several organizations. The ISASecure guide says that even when work is delegated, accountability for the control system stays with the asset owner.

The principal roles are:

  • Asset owner: operates the control system and is accountable for it, for example a plant owner. Part 2-1 sets the requirements for its security program
  • Product supplier: makes and supports hardware or software products, both control systems and components. Uses Part 4-1 as the development framework and builds security capabilities according to Parts 3-3 and 4-2
  • System integrator (integration service provider): designs, installs, configures, tests, commissions and hands over the system at a particular plant. May also help partition zones and perform the risk assessment. Uses Part 2-4 and Part 3-2
  • Maintenance service provider: supports the system in operation. Uses Part 2-4
INFOGRAPHIC
Which parts each role uses
One plant's control system
final accountability stays with the asset owner
Asset owner
operates and is accountable, Part 2-1
Product supplier
builds and supports products, Parts 4-1, 3-3, 4-2
System integrator
designs, installs, hands over, Parts 2-4 and 3-2
Maintenance provider
supports it in operation, Part 2-4

For the asset owner, this division of roles is a basis for writing security requirements into contracts with suppliers and service providers. ISA's white paper says an asset owner may require third-party certification to the relevant parts, both for service providers and for product purchases.

Zones and conduits

Part 3-2 asks you to partition the system under consideration into zones and conduits. A zone is a grouping of logical or physical assets based on risk or other criteria such as criticality, operational function, location, required access or responsible organization. A conduit is a logical grouping of communication channels that share common security requirements and connect two or more zones. The aim is to put assets with similar security characteristics under common requirements, and to limit how far a successful attack can spread.

Part 3-2 requires or recommends separating the following assets, as ISA's guide summarizes it:

  • Must be separated (shall): business assets from control system assets, and the assets of safety systems (systems that protect people and the environment from harm)
  • Should be separated (should): temporarily connected devices, wireless devices, and devices connected over external networks

Partitioning into zones is part of the risk assessment in Part 3-2. It starts by identifying the system under consideration, doing an initial risk assessment, and partitioning into zones and conduits. If the initial risk exceeds what is tolerable, a detailed assessment follows. The security requirements are then documented and the asset owner approves them. Part 3-2 does not prescribe a specific risk assessment method. The asset owner must choose one consistent with the organization's own risk methodology.

INFOGRAPHIC
From a whole system to zones and target levels
1
Identify the system
the scope being assessed
2
Initial risk assessment
a first view of the risk
3
Partition into zones and conduits
group assets with common requirements
4
Detailed assessment
only if initial risk is not tolerable
5
Document requirements and SL-T
in the cybersecurity requirements specification
6
Asset owner approval
the accountable party signs off

The article Zero Trust for OT: Adapting It Without Disrupting the Plant already shows how zones and conduits support blocking all communication by default, so this guide does not repeat it. NIST SP 800-82 Rev. 3 adds a related practice: set firewall rules to permit connections only between adjacent levels, tiers or zones, and consider making outbound rules from the control network as strict as inbound rules.

Security levels and the seven foundational requirements

A security level (SL), as ISA defines it, is a measure of confidence that a system, zone or conduit is free from vulnerabilities and functions as intended. Part 3-3 describes levels 1 to 4 by the attacker's means, resources, skills and motivation.

Levels 1 to 4 mean protection against the following violations:

  • SL 1: casual or coincidental violation
  • SL 2: intentional violation using simple means, low resources, generic skills and low motivation
  • SL 3: intentional violation using sophisticated means, moderate resources, IACS-specific skills and moderate motivation
  • SL 4: intentional violation using sophisticated means, extended resources, IACS-specific skills and high motivation

The series uses three kinds of security level, which are often confused:

  • SL-T (target): the level wanted for a zone or conduit in a particular plant. It comes from the risk assessment and is documented in the cybersecurity requirements specification. It is used to select products and design extra measures during integration
  • SL-C (capability): the level a system or component can provide when properly integrated and configured, without additional compensating measures
  • SL-A (achieved): the actual security level of the zones and conduits, measured after commissioning and in operation
INFOGRAPHIC
How SL-T, SL-C and SL-A connect
01
SL-T: the target
from risk assessment
02
SL-C: capability
what the product can do
03
SL-A: achieved
measured in operation

ISASecure is a certification scheme for products based on ISA/IEC 62443, carried out by independent certification bodies. Examples of certificates are SDLA (the supplier's product development process, against Part 4-1), SSA (systems, against Part 3-3) and CSA (components, against Part 4-2). The ISASecure guide stresses that SSA and CSA certificates only show that a product reached a certain SL-C. The asset owner must add the policies, processes and skilled people needed to reach the intended SL-A.

Part 3-3 groups its technical system requirements under seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. The IEC says these seven are the foundation for the capability security levels (SL-C) of a control system.

A concrete requirement: remote access

A concrete example is remote access. ISA's white paper (June 2025) cites requirement NET 3 (secure remote access) of Part 2-1, which sits in the network and communication security group. The reason is that OT assets are often maintained from outside the plant by external service providers, so remote access must be strictly controlled to avoid creating unnecessary attack surface.

According to that paper, NET 3 requires asset owners to do three things:

  • Allow only authorized applications: only authorized remote access applications are permitted
  • Document the connections: authorized interactive remote connections are documented, including purpose, circumstances, encryption and authentication technologies, length of time, and the location and identity of the remote client device
  • Terminate idle sessions: remote access is ended after a period of inactivity

Common mistakes

  • Using IEC 62443 as a product checklist only: an IACS includes people and work processes, not only technology
  • Assuming a certified product gives the plant that level immediately: a certificate shows the product's SL-C, while the SL-A also needs the asset owner's policies, processes and people
  • Mixing up SL-T, SL-C and SL-A: the target, a product's capability and what was actually achieved are three different things
  • Setting one level for the whole plant: SL-T is set per zone and conduit from the risk assessment
  • Not separating business systems from control systems, or not separating safety systems: Part 3-2 says both must be separated
  • Thinking 62443 replaces the organization's security management: 62443 includes no ISMS requirements and asks for coordination with the existing ISMS
  • Citing an old edition without checking the current one: the parts have different edition years, for example Part 3-3 is the 2013 edition in ISA's list
  • Forgetting that integrators and maintenance providers have roles too: if the contract does not name them, accountability still stays with the asset owner

Start today

  • Identify who holds which role: asset owner, integrator, maintenance provider and product supplier for each system, including where one organization holds several roles
  • Partition zones, starting with the most critical process: separate business systems from control systems, and separate safety systems
  • Set an SL-T for each zone from the risk assessment: record the reasoning in the cybersecurity requirements specification
  • Put 62443 requirements into procurement: ask suppliers whether they develop to Part 4-1, which SL-C the product supports, and whether it has third-party certification
  • Align with the security management you already have: if the organization has an ISMS under ISO/IEC 27001, coordinate the OT security program with it
  • Close uncontrolled remote access: route it through authorized channels, document it, and end it when idle
  • Plan OT patching: see Patch Management Best Practice: Fast, Without Outages and Part 2-3

To see where your organization's security controls and policies stand, try the self-assessment.

Scope and accuracy

This guide is an introduction, not a substitute for the standards. The standards are paid documents, and this guide did not read the full text of every part. The information comes from ISA's series page, the ISASecure Quick Start Guide, ISA's white paper (June 2025), the IEC page that shows the four clusters, the free preview of IEC 62443-3-3:2013, and NIST SP 800-82 Rev. 3 (September 2023). The ISASecure guide is an older document (its file name suggests 2020) that summarizes Parts 3-2 and 3-3, so check the security level definitions against the current editions before using them formally.

References and further reading