What Is IEC 62443? A Complete Guide to Industrial Cybersecurity

Industrial teams that wire cybersecurity into their requirements process get cleaner audits, fewer regressions when systems change, and a defensible record when regulators or insurers come asking. IEC 62443 is the international standard built to deliver that outcome across the operational technology (OT) lifecycle, and adoption has accelerated as information technology (IT) and OT networks converge. When that convergence is left untreated, the consequences show up as production shutdowns, ransom demands, and regulatory action.

IEC 62443 covers the full lifecycle of industrial automation and control systems (IACS) and assigns clear ownership to asset owners, system integrators, and product suppliers. The hard part is knowing which part of the standard applies to which role, and how the pieces fit together. This guide walks through the structure of the series, the core technical concepts, how responsibilities split across roles, and what it looks like to build IEC 62443 into engineering work day to day.

What Is IEC 62443?

IEC 62443 is the international standard series for cybersecurity across the IACS lifecycle. The work began inside ISA’s ISA99 committee at the International Society of Automation (ISA), and is now jointly developed with the International Electrotechnical Commission (IEC). It applies to the full range of IACS components: programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and remote terminal units (RTUs).

Why IEC 62443 Adoption Is Growing

IEC 62443 has moved from optional reference to working framework, and three forces are driving that shift:

• IT and OT networks have converged: Air-gapping is mostly gone, IACS components written decades ago without encryption now sit on networks that touch the internet, and security controls have to be designed in instead of bolted on later.
• Industrial cyberattacks have gotten expensive: Production losses, supply chain disruptions, ransom demands, and long recovery cycles have made manufacturing a frequent target, so ad-hoc fixes after a breach are no longer enough.
• Regulators and customers are pointing at it directly: The EU’s Cyber Resilience Act introduces phased mandatory requirements starting 11 September 2026, and the FDA recognizes ISA-62443-4-1 for medical-device cybersecurity.

Across all three, IEC 62443 has become a de facto reference for any company shipping into regulated industrial markets.

The Structure of the IEC 62443 Series

The series has four primary parts, and each one targets a different role at a different stage of the lifecycle.

Part 1: General Concepts and Terminology

ISA-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

IEC 62443-2-1 sets out the security program requirements for asset owners. IEC 62443-2-4 defines contractual security obligations for system integrators and service providers. Both target the people-and-process layer that wraps around the technical system.

Part 3: System-Level Security Requirements

IEC 62443 uses a zone-and-conduit model to segment industrial networks. IEC 62443-3-3 specifies the system security requirements and security levels that apply within each zone.

Part 4: Component Requirements for Product Suppliers

IEC 62443-4-1 specifies a secure development lifecycle (SDL) covering threat modeling, secure design, verification and validation, defect management, and security update management. IEC 62443-4-2 defines the technical security capability requirements for embedded devices, host devices, network devices, and software applications.

Core Concepts in the IEC 62443 Framework

IEC 62443 rests on four technical constructs that show up in almost every section: zones, conduits, security levels, and defense in depth.

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.

Security Levels From SL 1 to SL 4

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, 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.

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.

The Seven Foundational Requirements (FRs)

The seven foundational requirements (FRs) defined in ISA/IEC 62443-1-1 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 in IEC 62443-3-3. The target security level on a zone determines how deep those requirements go.

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. That means standing up a cybersecurity management system, running risk assessments, defining zones, and writing the security requirements that go into procurement.
• System integrators: Handle design, installation, configuration, testing, and commissioning. They produce the Cybersecurity Requirements Specification (CRS) that covers the zone model and target security levels.
• Product suppliers: Run a secure development lifecycle and ship components with documented capability security levels (SL-C). They stay accountable for vulnerability management and security updates throughout the product’s operational life.

These three roles meet at the Cybersecurity Requirements Specification, where the asset owner’s target security levels feed into the integrator’s design, and the supplier’s component capabilities have to line up to deliver the specified SL.

How to Implement IEC 62443 Step by Step

Implementation moves through four steps in this order: risk assessment, zone design, gap assessment, and ongoing management controls.

Run the Initial Risk Assessment

IEC 62443-3-2 defines a two-step risk assessment process. The initial risk assessment (IRA) sets the scope of the system and produces 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. The detailed risk assessment (DRA) then 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 a target security level (SL-T) to each zone based on the consequences of compromise. A zone protecting an emergency shutdown system might warrant SL 3, while a non-critical maintenance laptop zone might sit at SL 1. The SL-T then locks in which system requirements (SRs) from IEC 62443-3-3 apply.

Map Gaps Between Requirements and Existing Controls

Once an SL-T is assigned, the applicable SRs are fixed by the standard. The gap assessment 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 ISO 27001 information security program, IEC 62443 is an OT overlay and not a replacement, so most of the gap work is mapping existing IT controls to OT-specific SRs.

Build the Cybersecurity Management System

IEC 62443-2-1 defines the cybersecurity management system (CSMS) for IACS, and the standard organizes it into three categories that get built in sequence:

• Risk analysis: Document the business rationale, identify risks, and classify and assess them across all IACS zones and conduits.
• Addressing risk with the CSMS: Set security policy, build organizational structure and awareness, and put technical, procedural, and physical controls in place.
• Monitoring and improving the CSMS: Verify controls, audit conformance, and update the system as new threats and lessons feed back into risk assessment.

This structure is intentionally compatible with ISO/IEC 27001’s ISMS, so teams running an ISO 27001 program can extend their existing controls instead of starting over.

Common Challenges in IEC 62443 Adoption

Three things complicate IEC 62443 adoption more than anything else: legacy equipment that wasn’t built for security, the gap in skills between IT and OT teams, and 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 close that gap, with legacy devices isolated in tightly controlled zones, restricted ingress and egress, and monitored conduits in and out.

The Skills Gap Between IT and OT Teams

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 builds cybersecurity review directly into engineering change impact analysis.

Bringing IEC 62443 Compliance Into the Engineering Workflow

Sustained compliance comes down to keeping cybersecurity requirements connected to engineering evidence through design, verification, and post-deployment updates.

Traceability From Cybersecurity Requirements to Verification Evidence

The seven FRs are the foundation for every system and component requirement in the standard, and IEC 62443-3-3 elaborates them 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. Most teams keep that chain live in their requirements tool, so audit prep becomes a matter of pulling existing records instead of reconstructing them under deadline.

Linking Risk Assessments to Design and Test Activities

IEC 62443-3-2 asks teams to define the system, partition it into zones and conduits, assess risk, set target security levels, and document the security requirements that come out of all of that. The risk assessment then shapes both the zone architecture and which requirements get pulled in.

Audit-Ready Records Across System Updates

IEC 62443-4-1 makes security update management a normative lifecycle process, so 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.

This four-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.

Connecting IEC 62443 to the Engineering Record

When cybersecurity requirements live in spreadsheets, the controls list, the risk register, and the conformance evidence drift apart inside a quarter. The four-step change loop in 62443-4-1 only works if a single change to a controller surfaces every linked SR, test, and zone diagram automatically.

Jama Connect® is a requirements management platform that keeps cybersecurity requirements, risk outputs, design decisions, and verification evidence in one connected model, so when an FR-3 control changes, the linked artifacts update in the same place. Live Traceability™ extends that thread across requirements, test artifacts, risks, tasks, defects, and change history, and the platform ships with a pre-configured industrial machinery structure aligned to IEC 62443, IEC 62061, IEC 61508, and ISO 13849. To see how it fits into your IACS lifecycle, start a 30-day free trial.

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, including in relation to the EU CRA, though the CRA does not explicitly designate it as a conformance pathway.

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, which covers equipment swaps, firmware updates, network segmentation changes, and new assets added to a zone. IEC 62443-2-1 builds the trigger directly into engineering change management, so the re-assessment happens as part of the change request and not as a separate compliance activity.

How does IEC 62443 relate to NIST and ISO 27001?

The NIST Cybersecurity Framework is outcome-based and technology-agnostic, while IEC 62443 is specific to IACS and defines explicit security levels. ISO 27001 covers IT and enterprise information security, and IEC 62443 covers OT, so most teams treat them as complementary. The CSMS in 62443-2-1 was designed to be compatible with the ISMS in ISO 27001, which means an existing ISO program can be extended for OT instead of duplicated.

This article was authored by Mario Maldari on May 14, 2026.