IEC 62443 Explained: A Practical Guide to Industrial Cybersecurity Standards

IEC 62443 is the international family of standards for the cybersecurity of industrial automation and control systems. If you operate a plant, a substation, a water utility, a pipeline, or any facility that depends on PLCs, SCADA, DCS, or safety systems, this is the standard your security program should be built around.

That’s the short version. The longer version is the one most articles skip — what’s actually inside the series, how the parts fit together, what the security levels mean, and how to use the standard without drowning in documents.

This guide walks through it from the ground up. By the end you’ll know what IEC 62443 covers, where it came from, who it’s written for, and how to start applying it. If you also need to understand how this fits with an enterprise information security management system, the ISMS guide is the companion piece — the two standards are designed to work together.

What is IEC 62443?

IEC 62443 is a series of standards — not a single document. The full series defines requirements and processes for designing, deploying, operating, and maintaining secure industrial automation and control systems (IACS) throughout their lifecycle.

The series is published jointly by two organizations that almost always agree:

• IEC — the International Electrotechnical Commission, based in Geneva, which publishes the international editions as IEC 62443-x-y.
• ISA — the International Society of Automation, based in the United States, which publishes identical American editions as ANSI/ISA-62443-x-y.

The technical content is identical. You’ll see both names used, often together as ISA/IEC 62443. The standard has been recognized by the United Nations, UNECE, and NATO, and in 2021 the IEC formally accepted it as a horizontal standard — meaning sector-specific standards in other industries must use IEC 62443 as their cybersecurity foundation.

A short history matters here, because the standard’s design reflects where it came from. In 2002, ISA established the ISA99 committee to develop industrial cybersecurity standards. The first documents were published as ISA99 in 2007. Around 2010, ISA strengthened its relationship with IEC, and the standards were renumbered as IEC 62443. IEC Technical Committee 65 Working Group 10 now maintains the series jointly with ISA99. That joint heritage is why you see two numbering schemes for the same content.

The series has been actively revised in recent years. ANSI/ISA-62443-2-1-2024, the updated standard for security program requirements at asset owner sites, was published in January 2025. ISA-TR62443-2-2-2025 followed in December 2025, providing guidance on day-to-day security protection schemes. The standard is not frozen — it’s a living framework.

Why a separate standard for industrial systems?

This is the first question every IT-trained security professional asks: why isn’t ISO/IEC 27001 enough?

The short answer is that industrial environments break some of the assumptions that information security standards quietly rely on. A few specific examples:

• A patch that needs a reboot is routine on a laptop. On a PLC controlling a turbine, a reboot might mean a production shutdown — or a safety event.
• Antivirus software is standard on a corporate workstation. On a control room operator station, the same antivirus might lock up an HMI just as an alarm fires.
• Screen locking on idle is good IT hygiene. In a refinery control room, a locked screen when the operator needs to acknowledge an alarm in five seconds is itself a safety risk.
• Pushing network traffic for routine backups is invisible in an office network. On a control network, that same traffic can delay a safety message and cause real harm.

The deeper issue is the priority order. In IT, the typical priority is confidentiality, integrity, availability — protect data first. In OT, that often flips to availability, integrity, confidentiality — keep the process running first, because a stopped process can hurt people, the environment, and the business in ways that a data leak cannot.

ISO 27001 was written for the IT world. IEC 62443 was written for the OT world. The two are not competitors. They are designed for different jobs, and most organizations end up running both. The ISMS handles the corporate side. IEC 62443 handles the plant floor.

How the IEC 62443 series is structured

The series is organized into four groups, numbered 1 through 4. Each group has multiple parts. This is the cleanest way to picture the whole family:

Group 1 — General. Foundational concepts, terminology, and models that everything else builds on.

• IEC 62443-1-1 — Terminology, concepts, and models. The dictionary of the series. Defines what IACS, zones, conduits, security levels, and foundational requirements mean.
• IEC 62443-1-2 — Master glossary of terms (in development).
• IEC 62443-1-3 — System security compliance metrics (in development).
• IEC 62443-1-4 — IACS security lifecycle and use cases.
• IEC 62443-1-5 — Scheme for IACS protection levels.

Group 2 — Policies and Procedures. What asset owners and service providers must do at the organizational level.

• IEC 62443-2-1 — Security program requirements for IACS asset owners. The updated 2024 edition focuses on what a plant operator’s security program must include, organized into Security Program Elements (SPEs), with a maturity model for evaluating compliance.
• IEC 62443-2-2 — IACS security protection scheme. The 2025 technical report provides a risk-based approach for day-to-day security actions, combining technical controls, process maturity, and accountability.
• IEC 62443-2-3 — Patch management in the IACS environment. Practical guidance on the patching problem that nearly every plant struggles with.
• IEC 62443-2-4 — Security program requirements for IACS service providers. What integrators, maintenance contractors, and service vendors must offer their customers.

Group 3 — System. Requirements at the level of the integrated control system.

• IEC 62443-3-1 — Security technologies for IACS. A survey of available technologies — firewalls, IDS, authentication, encryption — applied to industrial contexts.
• IEC 62443-3-2 — Security risk assessment for system design. How to partition a system into zones and conduits, assess risk, and assign target security levels.
• IEC 62443-3-3 — System security requirements and security levels. The technical heart of the standard. Defines 100+ specific control system requirements, grouped under the seven foundational requirements and four security levels.

Group 4 — Component. Requirements at the level of individual products.

• IEC 62443-4-1 — Secure product development lifecycle requirements. What product suppliers must do when designing and building secure components — secure-by-design, threat modeling, security testing, vulnerability handling.
• IEC 62443-4-2 — Technical security requirements for IACS components. Specific requirements for embedded devices (like PLCs), network devices (like industrial switches), host devices (like SCADA servers), and application software.

You don’t need to know every part by heart. What matters is the principle: the standard is layered. Components (Group 4) plug into systems (Group 3), which are governed by organizational policies and procedures (Group 2), all anchored on shared definitions (Group 1). A mature implementation references parts from all four groups.

Four stakeholders, one shared responsibility

A founding principle of IEC 62443 is that industrial cybersecurity is a shared responsibility. The standard names four distinct stakeholder groups, and assigns each one specific obligations:

Asset owners. The end users — the company that owns and operates the plant, the utility, the refinery. They are ultimately accountable for secure operation of the IACS. Their main reference is IEC 62443-2-1.

System integrators. The companies that design, install, configure, and commission the control systems. They take components from suppliers and build them into working solutions for an asset owner. Their main references are IEC 62443-2-4 and IEC 62443-3-3.

Product suppliers. The manufacturers who build the actual components — PLCs, drives, SCADA software, industrial switches, HMI panels, safety controllers. They must apply secure development lifecycle practices and build components that meet defined security capabilities. Their main references are IEC 62443-4-1 and IEC 62443-4-2.

Service providers. The maintenance contractors, support vendors, and managed service providers who keep the IACS running after commissioning. They operate under IEC 62443-2-4 as well.

This four-way model matters because it solves a real problem. An asset owner can’t single-handedly secure an industrial system if the PLCs they’re installing have hardcoded passwords, the integrator builds a flat network, and the support contractor uses a shared admin account. Each stakeholder has to do their part. The standard makes those parts explicit and testable.

What counts as an IACS?

IEC 62443 applies to industrial automation and control systems — but the standard takes a broad view of what that means. The scope explicitly includes:

• DCS (Distributed Control Systems) in process industries — chemicals, refining, pharmaceuticals, food and beverage.
• SCADA systems for geographically dispersed operations — pipelines, electric grids, water and wastewater networks.
• PLCs (Programmable Logic Controllers) on discrete manufacturing lines.
• Safety Instrumented Systems (SIS) protecting against catastrophic events.
• RTUs (Remote Terminal Units), IEDs (Intelligent Electronic Devices), and field instrumentation.
• HMIs (Human-Machine Interfaces), engineering workstations, and historians.
• Industrial networks, including the field-level, control-level, and operations-level networks.
• Associated business systems where they directly affect or interface with the control system — MES, production scheduling, work management.

The IEC officially accepted IEC 62443 as a horizontal standard in 2021. In practice that means it now also gets applied beyond traditional process and discrete manufacturing — into building automation, medical devices, transportation systems, and IIoT environments. If it controls or monitors a physical process, IEC 62443 is the cybersecurity reference.

The zones and conduits model

This is the architectural concept at the heart of IEC 62443. Most industrial security failures trace back to a control network that is either too flat (no segmentation) or too connected to the corporate network (lateral movement from IT into OT). Zones and conduits give you a structured way to fix both problems.

A zone is a grouping of logical or physical assets that share common security requirements. Zones are defined by what the assets do, what they’re worth, and what would happen if they were compromised — not by how the network is wired. A typical industrial site might have zones like:

• A safety zone containing safety instrumented systems
• A control zone containing the DCS controllers and HMIs
• A supervisory zone containing engineering workstations and historians
• A site DMZ for data exchange with corporate IT
• A corporate zone for business systems

A conduit is a logical grouping of communication channels that connect two or more zones. A conduit is not just a cable — it’s the entire communication path along with the protections applied to it. Conduits have their own security requirements, separate from the zones they connect.

The model gives you three things at once. First, a clear boundary for risk assessment — instead of trying to assess a flat network, you assess each zone and each conduit separately. Second, a clear boundary for security controls — every zone has defined entry and exit points where you can place firewalls, monitoring, and access control. Third, containment — if an attacker gets into one zone, properly designed zones and conduits stop them from spreading easily.

In practice, mapping your existing network to a zones-and-conduits architecture is one of the highest-value activities in a 62443 project. Most legacy industrial networks were not designed this way, and the gap analysis usually reveals immediate, actionable problems.

The seven Foundational Requirements

IEC 62443-3-3 organizes all of its technical control system requirements under seven Foundational Requirements (FRs). Every security control in an industrial system maps back to one of these. Knowing the seven by heart is a useful shortcut for anyone working with the standard.

FR 1 — Identification and Authentication Control (IAC). Establish the identity of any entity (human, software process, or device) requesting access to the control system, and verify that identity before allowing access. The full scope includes role-based access, account management, password policies, authenticator strength, and unsuccessful login attempts.

FR 2 — Use Control (UC). Once an entity is authenticated, control what it is allowed to do. Enforce assigned privileges, control wireless and portable device use, lock sessions on inactivity, and produce auditable records of actions.

FR 3 — System Integrity (SI). Protect the integrity of the control system against unauthorized changes. Includes communication integrity, malicious code protection, software and information integrity, security functionality verification, input validation, error handling, and session integrity.

FR 4 — Data Confidentiality (DC). Protect the confidentiality of information at rest, in transit, and in use. Includes information confidentiality, cryptographic protection, and protection of confidential information during read/maintenance access. Often a lower priority in OT than in IT, but still required.

FR 5 — Restricted Data Flow (RDF). Segment the control system into zones and conduits, and control the flow of information between them. This is where the zones and conduits model becomes concrete technical requirements — network segmentation, zone boundary protection, and partitioning of safety functions.

FR 6 — Timely Response to Events (TRE). Detect security events, log them, monitor them, and respond fast enough to limit consequences. Covers audit log management, continuous monitoring, intrusion detection, and incident response readiness.

FR 7 — Resource Availability (RA). Ensure the control system continues to function in the presence of denial-of-service attempts or component failures. Covers backup and restoration, emergency power, network and security configuration management, least functionality, and protection against resource exhaustion.

If you’re already familiar with NIST CSF or ISO 27001 controls, you’ll recognize many of the concepts here. What makes the seven FRs distinct is the OT framing — every requirement is written with continuous operation, real-time response, and safety implications in mind.

The four Security Levels

IEC 62443 uses a four-level scale to express how strong the security needs to be in a specific zone, conduit, or component. The levels are defined by who you’re trying to defend against — the attacker’s resources, skills, and motivation. From IEC 62443-3-3:

• Security Level 1 (SL 1). Protect against casual or coincidental violation. Someone who stumbles into a system and accidentally causes harm, or who tries the obvious attack without any real effort.
• Security Level 2 (SL 2). Protect against intentional violation using simple means, low resources, generic skills, and low motivation. A typical opportunistic attacker — a curious insider, a script kiddie, a generic malware infection.
• Security Level 3 (SL 3). Protect against intentional violation using sophisticated means, moderate resources, IACS-specific skills, and moderate motivation. An attacker who knows what they’re doing in industrial systems and has the tools to act on it. Most critical infrastructure operators target SL 3.
• Security Level 4 (SL 4). Protect against intentional violation using sophisticated means, extended resources, IACS-specific skills, and high motivation. Nation-state actors and equivalent. Reserved for the most critical national infrastructure and high-consequence systems.

The standard also distinguishes between three different uses of the security level concept, which trips up newcomers:

• SL-T (Target Security Level) — the level the asset owner decides a zone or conduit needs, based on risk assessment.
• SL-A (Achieved Security Level) — the level a zone or conduit actually has after implementation, audit, and time-related degradation.
• SL-C (Capability Security Level) — the level a component or countermeasure is capable of supporting, regardless of how it’s deployed.

In a well-designed system, SL-A ≥ SL-T, and the components selected have SL-C values that allow the system to reach its SL-T. The mismatch between these three is where most real-world gaps live. A PLC certified as SL-C 3 deployed without proper authentication is delivering SL-A 1.

IEC 62443 certification

Unlike ISO 27001, where the standards body itself defines a single certification scheme, IEC 62443 is certified through independent conformity assessment programs. The dominant one is ISASecure, operated by the ISA Security Compliance Institute, a subsidiary of ISA.

ISASecure offers four main certification tracks today:

• Security Development Lifecycle Assurance (SDLA) — certifies a product supplier’s development practices against IEC 62443-4-1.
• Component Security Assurance (CSA) — certifies a specific component (embedded device, host device, network device, or application) against IEC 62443-4-2 and 4-1. The certificate states the SL-C the component achieves.
• System Security Assurance (SSA) — certifies an integrated system (DCS, SCADA, etc.) against IEC 62443-3-3.
• Automation and Control System Security Assurance (ACSSA) — a newer scheme, launching from late 2025 onward, designed to assess and certify operational control systems at asset owner sites. This is significant because it’s the first certification aimed at the operating plant, not the product or the system as supplied.

For asset owners, certification is rarely the goal. The point is more often the leverage you get over your supply chain — requiring ISASecure-certified components and SDLA-certified suppliers in your procurement contracts is a fast way to raise the floor on your industrial cybersecurity without managing every detail yourself.

How to implement IEC 62443: a working roadmap

There is no single mandatory path. The standard explicitly says it is implementation-independent. But the order most successful projects follow looks like this.

Step 1 — Sponsor and scope. Get senior management commitment and a defined scope. Most projects start with a single site or a defined production area, not everything at once.

Step 2 — Inventory the IACS. Walk the plant. Document every controller, every workstation, every network device, every protocol in use. The inventory will reveal assets nobody had on a list. For each asset, capture its function, its owner, its support status, and its known vulnerabilities.

Step 3 — Define zones and conduits. Group assets by function and risk profile, not by network layout. Identify every communication path between zones — those are the conduits. Document what data flows on each conduit and what protocol it uses.

Step 4 — Run the high-level risk assessment. For each zone and conduit, identify what could go wrong and what the consequences would be. In OT, consequences are scored against Health, Safety, and Environmental (HSE) impact as well as financial impact. The output is a target security level (SL-T) for each zone and conduit.

Step 5 — Run the detailed risk assessment per IEC 62443-3-2. Now go deeper. For each zone and conduit, identify specific threats, specific vulnerabilities, and existing protections. Calculate residual risk. Adjust the SL-T if needed.

Step 6 — Apply system requirements from IEC 62443-3-3. For each SL-T, the standard tells you exactly which control system requirements (SRs) and requirement enhancements (REs) apply. This is the technical heart of the implementation. You’re working through a defined checklist, not making it up.

Step 7 — Apply component requirements from IEC 62443-4-2. For each asset that participates in delivering a control system requirement, verify the component’s SL-C is sufficient. Where it isn’t, apply compensating countermeasures — network segmentation around an unpatchable PLC, for example.

Step 8 — Build the security program around IEC 62443-2-1. Policies, procedures, roles, training, incident response, change management, patch management, configuration management, backup and restoration. The 2024 update organizes these into Security Program Elements (SPEs) with a maturity model — useful for self-assessment.

Step 9 — Operate, monitor, and improve. Continuous monitoring. Regular audits. Tabletop exercises. Incident review. The SL-A of any zone degrades over time as new vulnerabilities are discovered. The program has to keep pace.

Realistic timelines for a single site, from scoping to first useful state: 12 to 24 months. Reaching mature SL-T compliance across a multi-site operation: a multi-year program. Anyone selling a faster timeline is selling paper, not security.

Common mistakes in IEC 62443 projects

Patterns that show up across almost every industrial cybersecurity engagement:

Treating it like an IT project. Pushing standard IT controls onto OT without understanding the operational consequences. The patching example, the antivirus example, the screen-lock example — they all come back to this. OT engineers need to be in the room from day one.

Buying tools before doing the risk assessment. A shiny industrial firewall does not give you a security program. The risk assessment tells you what protection you need; the tools come after.

Skipping the inventory. You cannot protect what you don’t know exists. Every project that skips this step gets surprised six months in.

Ignoring the supply chain. Your integrator’s habits, your OEM’s default passwords, your service provider’s remote access — these are part of your risk surface. IEC 62443-2-4 exists for exactly this reason.

Underestimating asset lifespan. A PLC installed in 2008 is still running in 2026 at many sites. It probably can’t run modern crypto, can’t be patched, and uses a flat trust model. Compensating countermeasures — segmentation, monitoring, restricted access — are the realistic answer, not “upgrade everything.”

Confusing capability with achievement. A component certified as SL-C 3 does not give you a system at SL-A 3. The component has to be configured, deployed in the right architecture, and integrated with the right organizational controls. Certification is a starting point, not a finish line.

Treating compliance as the goal. A passed audit means you had defensible documentation the day the auditor visited. The actual security posture is what happens between audits.

ISO 27001, IEC 62443, and how they fit together

You’ll often see articles set up ISO 27001 and IEC 62443 as competitors. They are not. The two are explicitly designed to complement each other, and the latest revision of IEC 62443-2-1 even removes requirements that overlap with an ISMS to make the integration cleaner.

A practical division of responsibility:

• Use ISO/IEC 27001 to establish a corporate-wide information security management system that governs policies, governance, risk management, and organizational controls across the whole company.
• Use IEC 62443 to extend that framework into the OT environment with the specific technical and procedural requirements industrial systems need.

An organization with both ends up with a single security program that the IT team, the engineering team, and the plant operators can all stand behind. The handoff between the two is at the IT/OT boundary — typically the site DMZ — and the policies on either side are coordinated, not contradictory.

IEC 62443 frequently asked questions

The takeaway

IEC 62443 is not a single standard. It is a framework — a structured way to think about industrial cybersecurity across roles, lifecycles, and risk levels. The framework has been refined for more than twenty years, accepted by international bodies, and adopted across critical infrastructure worldwide.

What makes it useful is not that it tells you exactly what to do. Plenty of standards do that, badly. What makes IEC 62443 useful is that it gives the four parties that matter — asset owners, integrators, product suppliers, and service providers — a shared language to talk about risk, capability, and responsibility. When everyone is using the same definitions of zone, conduit, foundational requirement, and security level, security conversations stop being arguments about vocabulary and start being conversations about engineering.

That alone is worth the effort. The rest is execution.