IEC 62443

What IEC 62443 is

IEC 62443 — often written ISA/IEC 62443 — is a series of international standards for the cybersecurity of industrial automation and control systems (IACS). It is developed jointly by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC). Where general standards such as ISO/IEC 27001 describe how to manage information security in any organization, 62443 is written for the physical world: it assumes systems that must keep running, devices with limited resources, and consequences for safety and the environment.

Three ideas run through the whole series:

• Shared responsibility. Security depends on the asset owner, the integrator and the supplier, and each gets its own requirements.
• Zones and conduits. Instead of securing every device individually, group devices into zones and control the paths between them.
• Risk-based levels. Not every zone needs the same protection; a security level expresses how strong an attacker a zone must withstand.

62443 is a standard, not a law. Regulations such as NIS2 require risk-based measures without prescribing a framework; 62443 is one of the most common ways to structure those measures in OT (see Certification and regulation below).

The structure of the series

The parts are numbered by group. The first digit tells you who the part is mainly for: the 2-x parts are about an organization's program, the 3-x parts about a whole system, the 4-x parts about individual products. The most-used parts are:

The series keeps growing. Recent additions include IEC PAS 62443-2-2:2025 (a security protection scheme) and IEC PAS 62443-1-6:2025 (applying 62443 to the Industrial Internet of Things); a PAS (Publicly Available Specification) is a pre-standard document. Editions differ per part and between the ISA and IEC versions, so always check which edition a contract or audit refers to.

Roles: who does what

62443 assigns requirements to roles rather than to job titles. One company can play several roles: a utility that builds its own substation automation is both asset owner and integrator.

• The asset owner is the organization that owns and operates the industrial system and is accountable for its risk — for example, a transmission system operator running substations. It defines the security program (2-1), decides which risk is acceptable, and sets the target security levels (3-2).
• The system integrator designs, builds, commissions and often maintains the system for the asset owner, combining products from several suppliers. In the standard this is one kind of service provider (2-4); maintenance providers are the other kind. The integrator designs the system so that it meets the requirements of 3-3.
• The product supplier develops and supports the components — controllers, protection relays, switches, HMI software. It follows a secure development lifecycle (4-1) and builds products that meet the component requirements (4-2).

Zones and conduits in depth

A zone is a group of assets that share the same security requirements; a conduit is a group of communication channels between zones that shares security requirements of its own. Both terms, and how they relate to the levels of the Purdue model, are introduced in The Purdue Model and OT Architecture. Here is how they are used in practice.

Drawing zones

Assets go into the same zone when they have similar:

• Criticality and consequence: what happens if they are compromised. A safety instrumented system belongs in its own zone, separate from basic control.
• Function: control, supervision, engineering, data exchange with IT.
• Location and ownership: one substation, one control center; equipment managed by one team or vendor.
• Technology and lifetime: a group of legacy devices that cannot meet the requirements of the rest may need its own zone with stronger protection at its boundary.

Every zone has a clear boundary, and anything that enters it — including a technician's laptop or a USB stick — enters through a defined conduit or procedure. Wireless links count too.

Defining conduits

A conduit is more than a cable or a firewall: it covers all channels between two zones and the security measures on them, such as firewalls, data diodes, VPN encryption and the allowed protocols. Good practice is to have as few conduits as possible, to document every one, and to treat remote access as a conduit in its own right. For a fictional transmission system operator, a first zoning might look like this:

The levels in this table are illustrative; real values come from the risk assessment described below. Protocols such as IEC 60870-5-104 are explained in Industrial Protocols.

The seven foundational requirements

The technical requirements of 62443 are grouped under seven foundational requirements (FRs). Each FR is a security goal; 62443-3-3 breaks them down into system requirements (SRs), and 62443-4-2 into component requirements (CRs), with requirement enhancements (REs) that are added at higher security levels.

Note the order compared with office IT: confidentiality is just one of seven, and three FRs (system integrity, restricted data flow, resource availability) are directly about keeping the process correct and running. The reasons are explained in OT Security Fundamentals.

Security levels

A security level (SL) in IEC 62443 expresses how strong an attacker a zone, conduit or component must be able to withstand. It is a measure of protection against a type of threat, not a score for how "good" a system is.

The same scale is used in three ways:

• Target (SL-T): the level a zone or conduit should reach, set by the asset owner from the risk assessment.
• Capability (SL-C): the level a component or system can reach when properly configured, as delivered by the supplier or integrator.
• Achieved (SL-A): the level the zone actually reaches in operation, as installed, configured and maintained.

Design is the art of making SL-A meet SL-T: choose components whose SL-C is high enough, or add compensating countermeasures (for example, a firewall at the zone boundary) where a component falls short. SL-A can also decay: a shared password created during a night shift, or a firewall rule left open after a project, lowers it without anyone noticing.

A security level is really a vector of seven values, one per foundational requirement. A zone with mostly public measurement data may need SL 1 for data confidentiality but SL 3 for integrity and availability.

A gap analysis in Python

Comparing SL-T with SL-A per foundational requirement shows where a zone falls short. The sketch below does this for two illustrative zones, using short names for the FRs in the table above.

# Compare target (SL-T) and achieved (SL-A) security levels per
# foundational requirement (FR1-FR7) for two zones.
FRS = ["FR1 Identification", "FR2 Use control", "FR3 Integrity",
       "FR4 Confidentiality", "FR5 Data flow", "FR6 Response", "FR7 Availability"]

zones = {
    "Substation control": {"target": [3, 3, 3, 2, 3, 2, 3],
                           "achieved": [2, 3, 2, 2, 3, 1, 3]},
    "Control-center DMZ": {"target": [2, 2, 2, 2, 3, 2, 2],
                           "achieved": [3, 2, 2, 1, 3, 2, 2]},
}

for name, sl in zones.items():
    print(f"Zone: {name}")
    gaps = 0
    for fr, target, achieved in zip(FRS, sl["target"], sl["achieved"]):
        if achieved < target:
            gaps += 1
            print(f"  {fr:<20} SL-T {target}  SL-A {achieved}  gap {target - achieved}")
    print(f"  {gaps} of {len(FRS)} requirements below target")

Zone: Substation control
  FR1 Identification   SL-T 3  SL-A 2  gap 1
  FR3 Integrity        SL-T 3  SL-A 2  gap 1
  FR6 Response         SL-T 2  SL-A 1  gap 1
  3 of 7 requirements below target
Zone: Control-center DMZ
  FR4 Confidentiality  SL-T 2  SL-A 1  gap 1
  1 of 7 requirements below target

In the DMZ, FR1 is above target (3 against 2). That does not compensate for the confidentiality gap: each requirement is assessed on its own. The substation gaps point to concrete work — individual accounts (FR1), integrity checks of controller programs (FR3) and monitoring (FR6) — or to compensating measures at the zone boundary if the devices themselves cannot do better.

Risk assessment for system design (62443-3-2)

Part 3-2 describes how an asset owner gets from "here is our system" to "here are its zones, conduits and target levels". It organizes this as a sequence of requirements; in outline the flow is:

1. Identify the system under consideration: its boundary, assets and access points, including connections to IT and to vendors.
2. Initial risk assessment: a high-level view of the worst-case consequences if the system were compromised — for safety, the environment, supply and finances.
3. Partition into zones and conduits, as described above.
4. Compare with tolerable risk: if the initial risk is already acceptable, the detailed step is not needed.
5. Detailed risk assessment per zone and conduit: threats, vulnerabilities, likelihood and consequence, existing countermeasures, and the resulting target security level.
6. Document the cybersecurity requirements, assumptions and constraints, so integrators and suppliers know what they must deliver.
7. Asset owner approval: the owner accepts the result and the remaining risk.

The general vocabulary of risk (threat, vulnerability, likelihood, impact, residual risk) is explained in Threats, Vulnerabilities and Risk. What is specific to OT is the weight of physical consequences: the existing process hazard analysis and the safety engineers are essential inputs.

Secure development and component requirements (4-1 and 4-2)

The 4-x parts are written for product suppliers. The secure development lifecycle (IEC 62443-4-1) sets requirements for the process a supplier uses to develop and maintain products. It groups them into eight practices:

1. Security management — the overall program, roles and training.
2. Specification of security requirements — including the threats the product must resist.
3. Secure by design — threat modeling and defense in depth in the architecture.
4. Secure implementation — secure coding rules and code review.
5. Security verification and validation testing — including vulnerability and penetration testing.
6. Management of security-related issues — handling vulnerability reports from customers and researchers.
7. Security update management — testing and delivering patches, and telling customers about them.
8. Security guidelines — documentation for customers on how to install, harden and operate the product securely.

Part 4-2 then states what a component must technically be able to do, per foundational requirement and security level. It distinguishes four component types: software applications, embedded devices (such as PLCs and relays), host devices (such as servers and workstations) and network devices (such as switches and firewalls). A component's result is its capability level (SL-C), which the integrator uses when designing zones.

For an asset owner, the practical value is in practices 6 to 8: a supplier that has a vulnerability-handling process, delivers tested updates, and documents secure configuration makes every later step of OT patching and hardening easier.

Certification and regulation

Product and process certification

Products, development processes and systems can be assessed against 62443 by independent certification bodies. The best-known program is ISASecure, run by the ISA Security Compliance Institute, which has certification schemes for development processes, components and systems; IEC's own conformity assessment system (IECEE) also offers 62443 certification. The schemes, their names and their scope change over time, so check the scheme owner's current documentation before relying on a certificate — and check exactly what was certified: a certified development process does not make every product certified, and a certified component says nothing about how it is configured in your plant.

Certificates for people

ISA's ISA/IEC 62443 Cybersecurity Certificate Program has four certificates, each requiring a training course and an exam: Cybersecurity Fundamentals Specialist (course IC32), Risk Assessment Specialist (IC33), Design Specialist (IC34) and Maintenance Specialist (IC37). The last three require the first. Holders of all four are recognized as ISA/IEC 62443 Cybersecurity Experts. ISA calls these certificates, not certifications, and as of 2026 lists the program among the credentials that do not require renewal. GIAC's GICSP (Global Industrial Cyber Security Professional) also covers 62443 concepts.

Relation to regulation

62443 itself is voluntary, but it maps well onto obligations that are not:

Details, dates and supervisors are on OT Regulation; the general NIS2 background is in Governance, Frameworks and Compliance.