What Is IEC 62443? A Complete Guide to Industrial Cybersecurity

Industrial teams that wire cybersecurity into their requirements process get cleaner audits and a defensible record when a regulator, a customer, or an insurer comes asking. Adoption of IEC 62443 has picked up as information technology (IT) and operational technology (OT) networks converge. Where the two meet without a security model, the consequences show up on the plant floor as shutdowns and ransom demands.

Keeping what IEC 62443 requires true as the plant changes is harder than learning what it says. The zone diagram and the target security levels are both statements about a system that engineers keep modifying. One change to a controller has to reach every requirement, test, and zone record that depends on it. Otherwise the conformance record drifts away from the installed plant.

The series covers the full lifecycle of industrial automation and control systems (IACS), and it splits ownership across asset owners, system integrators, and product suppliers. Among the regulatory compliance and standards programs an industrial team runs, it is one of the harder ones to keep current. This guide covers how the series is structured, who owns which part of it, and how to keep IEC 62443 evidence current as engineering work continues.

What Is IEC 62443?

IEC 62443 is the international standard series for cybersecurity across the IACS lifecycle. The work began inside the International Society of Automation (ISA), in ISA’s ISA99 committee, and is now jointly developed with the International Electrotechnical Commission (IEC). IACS components in scope include programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), human-machine interfaces (HMIs), and remote terminal units (RTUs).

Why Adoption Is Growing Across Industrial Sectors

Three forces explain why industrial teams now treat IEC 62443 as a working framework:

• IT and OT network convergence: Air-gapping is far less common than it was, and IACS components designed decades ago without encryption now sit on networks that touch the internet. Security controls have to be included in product design from the start.
• The cost of industrial cyberattacks: A stopped production line is expensive and recovery runs long, which is what makes manufacturing a frequent target. Ad-hoc fixes after a breach are no longer enough.
• Regulatory pull: EN 50770, the harmonized standard being developed for operational technology products under the European Union’s Cyber Resilience Act (CRA), is being built on IEC 62443-3-3, IEC 62443-4-1 and IEC 62443-4-2, but it is not yet officially mapped to the CRA’s requirements. Until EN 50770 is published, IEC 62443 is the practical stand-in. The CRA’s own reporting obligations start on September 11, 2026, and its main obligations follow on December 11, 2027.

IEC recognized the series as a horizontal standard in 2021, and its use spans more than twenty industries. The question that follows is usually which part of the series applies.

How the Series Is Structured

The series has four primary parts, and each one targets a different role at a different stage of the lifecycle. Part numbers are the least intuitive way to learn IEC 62443, and they are also how auditors and purchase specifications refer to it.

Part 1: General Concepts and Terminology

IEC 62443-1-1 establishes the core terminology and reference models for the series, and concepts like zones, conduits, and security levels get defined in detail in later parts. Part 1 is the natural starting point for anyone working with the standard for the first time.

Part 2: Policies and Procedures for Asset Owners

Asset owners work to IEC 62443-2-1, which sets out the security program requirements they need in place. IEC 62443-2-4 covers the service providers who integrate and maintain the system, with its own set of requirements.

Part 3: System Requirements and Security Levels

Part 3 covers the system level, and IEC 62443-3-2 and IEC 62443-3-3 are the two documents engineering teams use most. IEC 62443-3-2 defines the risk assessment that produces zones, conduits, and target security levels. IEC 62443-3-3 specifies the system security requirements that apply inside each zone and ties them to those levels.

Part 4: Component Requirements for Product Suppliers

The secure development lifecycle (SDL) in IEC 62443-4-1 covers threat modeling, secure design, verification and validation, defect management, and security update management, organized as eight practices and assessed at one of four maturity levels (ML 1 through ML4). IEC 62443-4-2 defines the technical security capability requirements for embedded devices, host devices, network devices, and software applications. Both parts assume a vocabulary the earlier parts define, and four constructs carry most of the weight.

Zones, Conduits, Security Levels, and Defense in Depth

Zones, conduits, security levels, and defense in depth show up in almost every part of IEC 62443. Each one is a decision that gets recorded, which is why they are also the four things most likely to be out of date.

Zones and Conduits for Network Segmentation

A zone is a group of assets that share common security requirements. A conduit is a logical group of communication channels between zones, and it controls how data moves across zone boundaries. Teams group IACS assets into zones and secure the conduits based on the trust and criticality of the zones they connect.

The Four Security Levels

Security levels (SLs) measure the confidence that a zone or system is free from vulnerabilities and operates as intended. Each higher level adds requirements on top of the level below, and they break down like this:

• SL 1: Protection against unintentional or accidental violations.
• SL 2: Protection against intentional violation using simple means with low resources, generic skills, and low motivation.
• SL 3: Protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills, and moderate motivation.
• SL 4: Protection against intentional violation using sophisticated means with extended resources, IACS-specific skills, and high motivation.

Three SL types apply across the lifecycle. The target level (SL-T) is set during risk assessment, and it is not a single number: IEC 62443-3-2 assigns a separate SL-T to each of the seven foundational requirements, for conduits as well as zones. The capability level (SL-C) is what a product supports out of the box, and the achieved level (SL-A) is what gets measured once the system is running. A zone protecting an emergency shutdown system might warrant SL 3, while a non-critical maintenance laptop zone might sit at SL 1.

Defense in Depth as a Layered Strategy

Defense in depth means layered controls, so a failure at one layer is caught at another. IEC 62443 spreads requirements across people, processes, and technology, since perimeter defenses and device hardening alone don’t cover the full attack surface. A single zone’s evidence therefore spans all three control types, which is why a record that looks complete in one of them can still be out of date in another.

The Seven Foundational Requirements and the Chain They Start

The seven foundational requirements (FRs) introduced in IEC 62443-1-1 and elaborated into system requirements in IEC 62443-3-3 are the basis for every system and component security level:

1. FR 1, Identification and Authentication Control: Verify the identity of users, processes, and devices before granting access.
2. FR 2, Use Control: Restrict authenticated entities to assigned privileges.
3. FR 3, System Integrity: Protect hardware, firmware, software, and data from unauthorized modification.
4. FR 4, Data Confidentiality: Protect information from unauthorized disclosure.
5. FR 5, Restricted Data Flow: Segment the control system via zones and conduits to limit unnecessary data flow.
6. FR 6, Timely Response to Events: Detect, log, and respond to security events with audit accessibility.
7. FR 7, Resource Availability: Keep core IACS functions running under degraded or attack conditions.

Each FR maps to specific system requirements (SRs) in IEC 62443-3-3. The chain runs from FR to SR, then to the target security level on the zone where that SR applies. The last link is the test evidence showing the SR was met. Each link in that chain has an owner that the standard names, and each one is something an engineering change can break.

Who Is Responsible for IEC 62443 Compliance

IEC 62443 distributes cybersecurity responsibility across three roles, each with obligations defined in different parts of the standard:

• Asset owners: Carry overall accountability for IACS cybersecurity risk. Asset owners stand up the security program IEC 62443-2-1 requires, run the risk assessments, define the zones, and write the security requirements that go into procurement.
• System integrators: Handle design, installation, configuration, testing, and commissioning. They design the detailed risk assessment and the technical security measures for each zone and conduit, working to the target security levels the asset owner sets.
• Product suppliers: Run a secure development lifecycle and ship components with a documented SL-C. Vulnerability management and security updates stay with the supplier for the product’s operational life, so component security stays on the application lifecycle management plan long after the component ships.

The three roles meet at the Cybersecurity Requirements Specification (CRS). The asset owner documents the target security levels and approves the CRS, the integrator designs to it, and the supplier’s component capabilities have to line up to deliver the specified level.

How to Implement IEC 62443 Step by Step

Implementation moves through risk assessment, zone design, control comparison, and ongoing management controls, in that order. Each step consumes the output of the one before it.

Run the Initial Risk Assessment

IEC 62443-3-2 defines a two-step risk assessment process. The system under consideration is identified first, and an initial risk assessment (IRA) establishes the baseline risk. Partitioning follows, producing the first zone-and-conduit diagram, where assets that share trust boundaries get grouped into the same zone. A turbine controller, its HMI, and the historian feeding it would typically sit in one zone, while the IT historian database and the corporate firewall sit in another. Where that initial risk exceeds the organization’s tolerable risk, a detailed risk assessment (DRA) walks through each zone and conduit to evaluate credible threats, document the resulting security requirements, and assign target security levels.

Define Zones and Set Target Security Levels

With the risk assessment in hand, IACS assets get partitioned from enterprise assets, and safety-instrumented systems stay in their own zone. The next step is assigning target security levels to each zone and conduit based on the consequences of compromise, with a separate SL-T recorded for each of the seven foundational requirements. The SL-T then locks in which SRs from IEC 62443-3-3 apply.

Compare Requirements Against Existing Controls

Once an SL-T is assigned, the applicable SRs are fixed by the standard. The comparison then evaluates each SR against current controls across all seven FRs and flags where coverage falls short. For teams already running the NIST Cybersecurity Framework or an ISO 27001 program, IEC 62443 is an OT overlay on what exists. Most of that work is mapping existing IT controls to OT-specific SRs.

Build the Asset Owner Security Program

IEC 62443-2-1 sets out the security program requirements an asset owner needs in place, structured as security program elements (SPEs) with a maturity model for assessing each one. The program has to cover policy, procedure, and the management of change that keeps both current as the plant is modified. Edition 2.0 was written to avoid duplicating an information security management system (ISMS), so teams already running ISO 27001 can extend what they have. Getting all of that in place is harder in a running plant than the standard makes it sound.

Where IEC 62443 Adoption Stalls

Adoption stalls on legacy equipment, on the distance between IT and OT security skills, and on the constant churn of engineering changes.

Legacy Equipment With Limited Security Capabilities

A lot of IACS equipment was built for operability, not security, and you can’t always harden the device itself. Compensating controls at the zone boundary cover what the device cannot, with legacy devices isolated in tightly controlled zones and monitored conduits in and out. None of that is cheap. A brownfield plant reaches conformance slowly, one zone at a time, and the equipment that most needs hardening is usually the equipment that cannot take it.

Where IT and OT Security Skills Diverge

Industrial cybersecurity often falls to controls engineers who have limited time for security work, while IT security practitioners aren’t trained for safety-critical OT environments. The standard’s shared vocabulary, including zones, conduits, security levels, and FRs, gives the two groups something to argue from.

Sustaining Compliance Through Engineering Changes

Equipment swaps, firmware updates, and network segmentation changes can quietly create new exposure. Zone-and-conduit diagrams and SL-T assignments are living documents and have to be revisited after every system change. IEC 62443-2-1 requires the asset owner’s security program to cover management of change, so a cybersecurity review sits inside the change impact analysis a team already runs.

Bringing IEC 62443 Compliance Into the Engineering Workflow

Sustained compliance management comes down to keeping cybersecurity requirements connected to engineering evidence through design, verification, and post-deployment updates. What does a customer, an auditor, or an insurer ask a manufacturer to produce? They ask for the zone-and-conduit diagram, the target security level on each zone, the CRS, and the SRs traced to their test results, all of which the risk assessment and requirements steps above already produce.

Traceability From Cybersecurity Requirements to Verification Evidence

IEC 62443-3-3 elaborates the seven FRs into SRs tied to specific security levels. The traceability chain then runs from FR to SR, through zone allocation, design artifact, component requirement, test case, and verification evidence. Teams that keep the chain live in a requirements management tool find audit prep becomes a matter of pulling existing records instead of reconstructing them under deadline.

Linking Risk Assessments to Design and Test Activities

The risk assessment in IEC 62443-3-2 asks teams to define the system, partition it into zones and conduits, and assess risk. Teams then set the target security levels and document the security requirements that come out of them. The risk management work then shapes both the zone architecture and which requirements get pulled in. Skipping the link in the other direction is the common failure, because a test result never tied back to the SR it satisfies leaves the zone’s verification coverage incomplete against its target level.

Audit-Ready Records Across System Updates

Security update management is a normative practice in IEC 62443-4-1 for suppliers, and IEC 62443-2-1 requires the asset owner’s program to cover management of change. Either way, changes to deployed systems trigger the same traceability obligations as original development. Each engineering change requires:

• • SR impact analysis: Determine which system requirements are affected.
  • SL-T re-evaluation: Assess whether the change alters the zone’s threat or vulnerability profile.
  • Re-verification evidence: Link regression test results to the affected SRs.
  • Updated zone configuration records: Revise zone-and-conduit diagrams to reflect the current state.
• Component and vulnerability review: Refresh the SBOM for the delivered release and re-screen it against new CVEs, EPSS scores, and the CISA KEV catalog.

This five-step loop ties every modification back to the original security requirements, so the achieved security level on a zone doesn’t quietly drift over time.

How Jama Connect Supports IEC 62443 Compliance

When cybersecurity requirements live in spreadsheets, the controls list, the risk register, and the conformance evidence drift apart quickly. Jama Connect® is a web-based requirements management and traceability platform that holds the FR-to-SR chain, the zone allocations, and the verification evidence in one connected model. Live Traceability™ is the approach that keeps the FR-to-SR links current as each artifact changes. When an FR 3 control on a zone with an SL-T of 3 is modified, suspect links mark the linked SRs and their test cases for review, and the zone record appears in the same impact view.

The five-step change loop above depends on links that maintain themselves, and the three roles the standard defines work from the same record. An asset owner’s target security levels, an integrator’s design against them, and a supplier’s SL-C all sit in one model. Jama Connect’s machinery and industrial tech framework covers IEC 62443 alongside IEC 62061 and ISO 13849-1. For a quality lead, that means the CRS and its approval trail are one query away when a customer asks.

Keeping Zone Evidence Current as the Product Changes

The product will change again. Every equipment swap, firmware update, and segmentation change either flows through the trace chain or goes unrecorded. The difference surfaces years later, when someone asks for evidence. Teams that treat the zone diagram and the SL-T assignments as engineering artifacts with owners and change control are the ones whose records still hold.

Jama Connect supports this workflow by keeping the trace links between requirements, tests, and risks current as the design moves, so the evidence an audit needs is already assembled. If your team is rebuilding zone evidence by hand after every change, you can start a free 30-day trial today.

Frequently Asked Questions About IEC 62443

What is the difference between IEC 62443 and ISA 99?

ISA99 is the ISA committee that develops the standards published under the IEC 62443 designation. The two names refer to the same body of work, with “ISA/IEC 62443” reflecting the joint development between ISA and IEC.

Is IEC 62443 certification mandatory?

IEC 62443 is a voluntary consensus standard, and ISASecure certifications are also voluntary. The standard is increasingly cited as a reference for cybersecurity compliance, and amendments to IEC 62443-3-3, 4-1, and 4-2 have been adopted as work items in the Cyber Resilience Act standardization request. Adoption as work items puts IEC 62443 on the path to supporting CRA conformance without yet being the primary route.

How often do I need to re-run the IEC 62443 risk assessment?

You re-run it any time a change might alter the threat or vulnerability profile of a zone. Equipment swaps, firmware updates, network segmentation changes, and new assets in a zone all qualify. Under IEC 62443-2-1 the asset owner’s security program has to cover management of change, so the re-assessment happens as part of the change request. Holding the zone diagram and the SL-T assignments under baseline control is what keeps the re-run small.

How does IEC 62443 relate to NIST and ISO 27001?

The NIST Cybersecurity Framework applies across industries and company sizes, while IEC 62443 is specific to IACS and defines explicit security levels. ISO 27001 information security covers IT and enterprise information security, and IEC 62443 covers OT, so most teams treat them as complementary. Where both are in place, the ISO 27001 program usually owns the policy layer while IEC 62443 owns the zone-level technical requirements and their verification.

This article was authored by Mario Maldari on May 14, 2026, and updated on October 9, 2026.