What Is IEC 62443? The OT Cybersecurity Standard Explained (2026)
IEC 62443 explained — the structure of the series, security levels (SL 1-4), zones and conduits, the 7 foundational requirements, and how to apply it on your plant floor.
IEC 62443 is a series of consensus standards for cybersecurity across the lifecycle of industrial automation and control systems (IACS). Different parts address asset-owner security programs, service-provider processes, system risk assessment and requirements, secure product development, and component capabilities. A project must name the applicable part, edition, system boundary, stakeholder, and evidence; “IEC 62443 compliant” on its own is not a complete requirement.
What Is IEC 62443?
IEC 62443 (formally IEC/ISA 62443 Industrial Automation and Control Systems Security) is a multi-part standard series developed jointly by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC). Its purpose is to provide a structured, risk-based methodology for securing industrial automation and control systems throughout their entire lifecycle — from initial design through decommissioning.
Unlike IT-focused frameworks such as ISO 27001, IEC 62443 is written specifically for the constraints of OT environments: real-time control requirements, long asset lifetimes (often 15–25 years), safety-critical processes, and the severe consequences of availability loss. A patch cycle that is routine in enterprise IT can require a planned maintenance window, safety-of-function testing, and vendor approval in an OT context. IEC 62443 acknowledges these realities.
The standard addresses three distinct audiences:
- Asset Owners — the companies that operate industrial facilities and must manage risk across their installed base
- System Integrators — contractors and engineering firms that design and deploy control system solutions
- Product Suppliers — vendors who manufacture PLCs, DCS, HMIs, field instruments, and other IACS components
Each audience has specific obligations defined in different parts of the series, which is what makes IEC 62443 practically useful rather than a single one-size-fits-all document.
History: From ISA-99 to IEC 62443
The standard traces its roots to ISA-99, a committee formed by the ISA in 2002 following early awareness of OT cyber threats — years before incidents like Stuxnet brought the topic to mainstream attention. The committee's work produced a series of technical reports and standards published under the ISA-99 designation.
In 2010, ISA and IEC formalized a collaboration to harmonize the work into a single international series. The documents were renumbered as ANSI/ISA-62443 in North America and IEC 62443 internationally, though the content is substantively identical. You will still see ISA-99 used informally as a shorthand, particularly in older project specifications and procurement documents — it refers to the same underlying framework.
Key milestones:
- 2002 — ISA-99 committee formed
- 2007 — First ISA-99 technical reports published
- 2010 — Harmonization with IEC begins; renumbering to 62443
- 2013–2020 — Core system and product parts established, including 3-3, 4-1, 4-2 and the 3-2 risk-assessment process
- 2024–2025 — Part 2-1 was revised for asset-owner security programs, while new evaluation methodologies and technical reports continued to extend the series
Structure of the IEC 62443 Series
The standard is organized into four groups, each targeting a specific aspect of IACS security. Understanding this structure prevents the common mistake of treating IEC 62443 as a single document.
Group 1 — General
These parts establish foundational concepts, terminology, and a common vocabulary used across the entire series. If two teams in the same organization disagree on what "security level" or "zone" means, they should start here. Key output: a shared language that asset owners, integrators, and vendors can use without ambiguity.
Group 2 — Policies and Procedures
This group covers security programs and processes. Part 2-1:2024 specifies asset-owner security-program requirements for IACS in operation. Part 2-4 addresses security-program requirements for IACS service providers during integration and maintenance. Other documents cover areas such as patch management and protection-scheme guidance. Assign the correct stakeholder; Group 2 is not only an asset-owner checklist.
Group 3 — System
The system group is where network architects and control system engineers spend most of their time. It defines how to design a secure IACS by applying security levels, zones, and conduits to a specific system topology. Part 3-2 covers the risk assessment process at the system level. Part 3-3 defines the system-level security requirements that a designed solution must satisfy.
Group 4 — Component
This group is aimed at product suppliers and defines security requirements for individual components — PLCs, HMIs, network switches, historian servers, and any other IACS device. Part 4-2 is the cornerstone: it specifies what a component must do (authentication, audit logging, software update verification, etc.) to claim conformance at a given security level. Many procurement specifications now require Part 4-2 conformance certificates from vendors.
Security Levels (SL 1–4)
Security levels are the core risk-tiering mechanism in IEC 62443. They define the capability of a threat actor that a system or component is designed to resist — not an absolute guarantee of invulnerability, but a calibrated target based on realistic adversary profiles.
| Security Level | Abstract threat capability addressed |
|---|---|
| SL 1 | Protection against casual or coincidental violation |
| SL 2 | Protection against intentional violation using simple means, low resources, generic skills and low motivation |
| SL 3 | Protection against intentional violation using sophisticated means, moderate resources, IACS-specific skills and moderate motivation |
| SL 4 | Protection against intentional violation using sophisticated means, extended resources, IACS-specific skills and high motivation |
Do not assign a level from industry name, company size, or a generic “baseline.” IEC 62443-3-2 establishes a risk-assessment process for the system under consideration, its zones and conduits, and the target security level (SL-T) for each. Requirements can also differ across the seven foundational-requirement vectors rather than collapsing neatly into one slogan.
Three distinct flavors of security level appear throughout the standard:
- SL-T (Target) — the security level the asset owner decides a zone must achieve, based on risk assessment
- SL-C (Capability) — the security level a product or system is capable of achieving by design
- SL-A (Achieved) — the security level a system actually reaches after installation, configuration, and compensating controls are applied
In practice, SL-A is often lower than SL-C because a capable product is misconfigured, patched inadequately, or operated without the compensating controls its design assumed. Closing the gap between SL-C and SL-A is one of the primary goals of a proper 62443 implementation program.
What does a claimed component security level mean for a PLC? It means the product claim must be evaluated against the applicable IEC 62443-4-2 component requirements and enhancements, normally alongside the supplier's IEC 62443-4-1 secure-development evidence. It does not prove that the installed automation solution achieves the project SL-T. Configuration, architecture, compensating controls, accounts, services, patching, monitoring, operations, and verification all matter.
Zones and Conduits
Zones and conduits are the architectural building blocks of an IEC 62443 compliant system design. They are defined in Part 3-2 and represent how you partition your control network to limit the blast radius of a security incident.
A zone is a grouping of logical or physical assets that share common security requirements. Membership does not imply unrestricted communication inside the zone. A conduit is a logical grouping of communication channels connecting two or more zones that share common security requirements. The design must state permitted flows, services, direction, identities, monitoring, availability behavior, and verification evidence.
Mapping Zones and Conduits to a Real Plant Network
Consider a mid-size discrete manufacturing facility. Applying the Purdue Reference Model (ISA-95 / ISA-99 levels) as the skeleton, a practical zone design looks like this:
Level 0/1 — Field and Control Zone (SL-T 2) Individual PLC cells, drive controllers, and field instruments. Each production line or machine cell forms its own zone. Communication within the zone is largely unrestricted, but the zone is isolated from adjacent cells. A compromised robot cell cannot directly reach the packaging line PLC.
Level 2 — Supervisory Zone (SL-T 2) SCADA servers, HMI workstations, and engineering workstations that supervise the field equipment. This zone communicates downward to the control zone via a conduit — typically a managed Layer-3 switch with VLANs and ACLs, or a dedicated industrial firewall.
DMZ — Industrial Demilitarized Zone (SL-T 2–3 depending on criticality) The DMZ is the conduit mechanism between the OT network and enterprise IT (Level 4/5). Historians, remote access gateways, and data diodes sit here. No direct connection exists between the SCADA zone and the corporate network; all data traverses the DMZ where it can be inspected and controlled. This is the single most important architectural decision for most plants that are currently flat-networked.
Level 3 — Site Operations Zone (SL-T 2) Manufacturing execution systems (MES), production scheduling, quality management. Sits above the DMZ on the OT side.
Level 4/5 — Enterprise Zone (governed by IT policy, not IEC 62443) ERP, email, corporate network. IEC 62443's scope stops at the OT/IT boundary — the standard is not trying to replace ISO 27001 for the enterprise side.
Each conduit between zones must have a defined security policy: which protocols are permitted, in which direction, with what authentication. A conduit is not just a cable — it is a documented, enforced communication boundary. A SCADA server that needs to pull data from a PLC should pull it through a one-way data diode or through a historian sitting in the DMZ — not with a direct TCP connection from the corporate laptop to the PLC's Ethernet port.
For a deeper look at securing the systems within these zones, see our guide on PLC security best practices and the architecture patterns covered in our SCADA best practices guide.
The 7 Foundational Requirements (FRs)
Part 3-3 organizes all system-level security requirements into seven Foundational Requirements (FRs). These FRs are the functional categories against which both system designs and individual components are evaluated. Each FR contains a set of System Requirements (SRs) that become more stringent as the target security level increases.
| # | Foundational Requirement | What It Covers |
|---|---|---|
| FR 1 | Identification and Authentication Control (IAC) | Verifying the identity of all users, software processes, and devices before granting access |
| FR 2 | Use Control (UC) | Enforcing authorization — ensuring authenticated entities can only perform permitted actions |
| FR 3 | System Integrity (SI) | Protecting the system from unauthorized modification during operation and maintenance |
| FR 4 | Data Confidentiality (DC) | Protecting information from unauthorized disclosure, particularly across conduits |
| FR 5 | Restricted Data Flow (RDF) | Segmenting the network and controlling communication flows between zones |
| FR 6 | Timely Response to Events (TRE) | Detecting, reporting, and responding to security events in time to limit impact |
| FR 7 | Resource Availability (RA) | Ensuring the IACS remains available and degrades gracefully under attack |
FR 7 (Resource Availability) makes availability requirements explicit within the IACS security model. The consequence of loss of availability is process-specific and can include loss of production, loss of view or control, unsafe operator decisions, or impaired recovery. Cybersecurity controls must therefore be engineered with process, safety, reliability, and recovery requirements rather than copied from an enterprise baseline.
Applying FRs at the engineering level. When your team evaluates a new PLC or HMI for a project, use the FRs as a structured checklist:
- FR 1: Does the device support individual user accounts with configurable password policies? Does it support certificate-based authentication?
- FR 2: Does it support role-based access control with read-only roles for operators vs. write access for engineers?
- FR 3: Does it support firmware signature verification? Does it log configuration changes with user attribution?
- FR 4: Does it support encrypted communication (TLS/DTLS for Ethernet, encrypted OPC-UA)?
- FR 5: Can you configure per-port or per-protocol allow-lists to restrict what the device communicates with?
- FR 6: Does it generate syslog or event log output that a security monitoring system can consume?
- FR 7: Does it support watchdog timers, denial-of-service resilience, and graceful degradation under network flooding?
Major PLC vendors now publish conformance claims against Part 4-2 SRs. Siemens, Rockwell Automation, Schneider Electric, and others provide security compliance documents that map their product features to specific SRs and security levels. Requesting these documents during procurement is a straightforward first step toward 62443 compliance.
IEC 62443 vs ISA-99 vs NIST SP 800-82 vs NERC CIP
These frameworks are frequently mentioned together, and confusion about their scope is common.
| Framework | Scope | Mandatory? | Best For |
|---|---|---|---|
| IEC 62443 | Industrial automation and control systems globally; all sectors | Generally voluntary (except in some regulated sectors/regions) | Cross-sector OT security; vendor qualification; system design |
| ISA-99 | Same as IEC 62443 — it is the predecessor/North American designation | No | Legacy references; same practical content |
| NIST SP 800-82 Rev. 3 | OT security guidance for US federal agencies and critical infrastructure operators | Informative (not mandatory for private sector) | US government contractors; practical implementation guidance alongside 62443 |
| NERC CIP | Bulk electric system (power grid) in North America | Mandatory for registered bulk electric system entities | Electric utilities in the US and Canada |
The key point: IEC 62443 and NIST SP 800-82 are complementary, not competing. NIST 800-82 Rev. 3 explicitly references IEC 62443 as the system-level design framework, while providing additional US-context guidance on incident response, procurement, and supply chain risk. Many asset owners use both: 62443 for the architectural and product requirements, and NIST 800-82 as an operational implementation guide.
NERC CIP is in a different category — it is legally enforceable for specific entities in the power sector. Utilities subject to NERC CIP often also adopt IEC 62443 practices because the standard's zone-and-conduit model maps naturally to NERC CIP's Electronic Security Perimeter (ESP) concept.
The relationship between OT and IT security more broadly is covered in our OT vs IT security overview, and foundational control system context is available in our industrial control systems guide.
Is IEC 62443 Mandatory?
IEC 62443 is a standards series, not one globally applicable law. Whether a specific part or requirement is mandatory depends on the jurisdiction, sector rules, contract, certification scheme, product category, and conformity route.
Situations where 62443 compliance is required or strongly expected:
- EU Cyber Resilience Act (Regulation (EU) 2024/2847) — imposes essential cybersecurity requirements on covered products with digital elements. Harmonised standards can provide a presumption of conformity once their references are published for the relevant requirements; do not assume an IEC 62443 certificate automatically completes every CRA obligation.
- NIS2 and national implementation — creates risk-management and reporting duties for covered entities, but applicability and exact national obligations require legal analysis.
- Sector regulation — electricity, transport, medical, machinery, defense and other sectors may have their own binding rules.
- Contracts and procurement — an owner can make named IEC 62443 parts, editions, profiles, evidence, or certifications contractual even when a statute does not.
A standards-based program can support due diligence, but a certificate or document does not by itself prove that operational risk is controlled. Confirm applicability with competent cybersecurity, engineering, conformity-assessment, and legal professionals.
Who Needs IEC 62443?
In short: any organization that designs, builds, operates, or maintains industrial control systems. More specifically:
- Manufacturing plants (automotive, food and beverage, pharmaceutical, electronics) — asset owner obligations, primarily Groups 2 and 3
- Process industries (oil and gas, chemicals, mining, water treatment) — risk assessment must include safety, environmental, availability and recovery consequences
- System integrators — Part 2-4 defines security program requirements for integrators; increasingly a procurement prerequisite
- PLC/HMI/DCS vendors — Part 4-2 product conformance; increasingly required by asset owners and implicitly by the EU CRA
- Engineering, Procurement, and Construction (EPC) firms — responsible for designing 62443-compliant systems on behalf of asset owners
How to Get Started: Applying IEC 62443 on Your Line
The standard can appear intimidating at first. Here is a practical, sequenced approach for a controls engineer or facility engineer beginning the journey:
Step 1 — Inventory Your Assets
You cannot protect what you cannot see. Start with a complete inventory of every IACS device: PLCs, HMIs, network switches, historians, engineering workstations, remote access points. Document firmware versions, network addresses, and communication relationships. Many facilities discover undocumented connections — a vendor remote access modem, a legacy serial bridge to Ethernet converter — during this step.
Step 2 — Conduct a High-Level Risk Assessment (Part 3-2)
For each group of assets, ask: what is the consequence if this system is compromised (availability loss, safety impact, environmental release, production loss)? And what is the likelihood of attack given the threat actors relevant to your facility? This produces documented consequences, threat assumptions, zone and conduit risk decisions, and proposed target security levels. Assign SL-T through the approved Part 3-2 method; do not copy one level across a sector or facility.
Step 3 — Define Your Zones and Conduits
Draw the network boundaries. Group assets with similar criticality and function into zones. Define every conduit between zones: which protocols, which direction, which authentication. The output is a zone and conduit diagram — the fundamental architectural document for your 62443 program. If you currently have a flat OT network with no segmentation, creating a single DMZ between OT and IT is typically the highest-value first step.
Step 4 — Gap-Assess the Applicable Requirements
Using the approved security requirements and the FR/SR structure from Part 3-3, compare required capabilities and processes with the as-built system. Preserve product limitations and compensating controls instead of treating a product certificate as system evidence.
Step 5 — Prioritize Remediation by Risk
Not all gaps are equal. A direct internet-facing connection to a PLC is a higher priority than a missing audit log on a non-critical conveyor controller. Use the risk assessment from Step 2 to sequence remediation. Quick wins — patching known vulnerabilities, removing default credentials, segmenting the historian from the control network — can dramatically reduce risk before longer-term architectural changes are planned.
Step 6 — Document and Maintain
IEC 62443 is not a one-time certification event — it is an ongoing management system. Maintain your zone and conduit documentation, keep your asset inventory current, and establish a process for reviewing security when changes are made to the control system. Part 2-1 provides the framework for this ongoing security management system.
A structured approach to the underlying PLC security best practices will provide implementation context. Download the IEC 62443 zone-and-conduit workbook (CSV) to inventory zones, conduits, permitted flows, security requirements, owners, evidence and residual risk. It is an engineering worksheet, not a conformity assessment.
Primary sources and edition check
- ISA, ISA/IEC 62443 series of standards, including the current published-part list.
- IEC, IEC 62443-2-1:2024, asset-owner security-program requirements.
- ISA, ANSI/ISA-62443-3-2-2020 preview, scope for system definition, zones/conduits, risk assessment and SL-T.
- European Union, Cyber Resilience Act, Regulation (EU) 2024/2847, official legal text.
Reviewed 26 July 2026. The exact standard edition, amendments, national adoption and contract control the project.
Frequently Asked Questions
What is IEC 62443 used for?
IEC 62443 is used to design, assess, and maintain cybersecurity for industrial automation and control systems (IACS) — including PLCs, DCS, SCADA, HMIs, and the networks connecting them. Asset owners use it to evaluate and reduce OT cyber risk. System integrators use it to demonstrate security capability to clients. Product vendors use it to certify that their devices meet defined security requirements. The standard is sector-agnostic and applies across manufacturing, process industries, utilities, and critical infrastructure.
What are the IEC 62443 security levels?
IEC 62443 defines four security levels (SL 1–4) that represent progressively capable threat actors and increasing resistance to intentional cyber attack. The target security level (SL-T) is selected for a particular zone or conduit through the Part 3-2 risk-assessment process. The levels are not universal sector labels: two systems in the same plant can require different targets because their consequences, exposure, threat assumptions, and compensating controls differ. The approved risk assessment and applicable requirements must support the choice.
What is the difference between IEC 62443 and ISA-99?
There is no substantive difference. ISA-99 is the original designation used by the ISA committee that developed the standard beginning in 2002. When ISA and IEC formally collaborated and published the work as an international standard, the documents were renumbered as IEC 62443 (internationally) and ANSI/ISA-62443 (in North America). The content is harmonized and effectively identical. ISA-99 is still used colloquially, particularly in legacy specifications and documentation written before the renumbering.
Is IEC 62443 mandatory?
Not universally. A named part may become binding through a law, national implementation, sector rule, procurement specification, customer contract, or certification scheme. The EU Cyber Resilience Act does not make every IEC 62443 document universally mandatory; determine the product scope, obligations, transition dates, conformity route, and any cited harmonised standards for the actual case.
What are zones and conduits in IEC 62443?
Zones and conduits are architectural concepts defined in IEC 62443 Part 3-2. A zone groups logical or physical assets that share common security requirements. A conduit groups the communication channels that connect zones and need common security requirements. Zone membership does not authorize unrestricted communication: permitted flows, direction, protocol, identity, monitoring, failure behavior, and compensating controls still require design and verification. Implementations can use industrial firewalls, managed switches with access controls, data diodes, or secure remote-access gateways, but the selected technology must follow the documented risk assessment and system requirements.
