IEC 62443 Explained: The OT Cybersecurity Standard Your Industry Cannot Ignore

Most industrial organizations operating in North America have heard of IEC 62443. Fewer can explain what it actually requires of them. Fewer still have mapped their current OT architecture against its security levels and found out where they fall short.

That gap is not unusual. IEC 62443 is a multi-part standard developed by ISA (the International Society of Automation) and adopted by the International Electrotechnical Commission. It covers the full lifecycle of industrial automation and control system (IACS) security - from the policies an asset owner should have in place, to the technical requirements a PLC manufacturer must build into their product. Reading the standard directly is not a lightweight exercise.

This post cuts through the structure. It explains what IEC 62443 actually requires, how Security Levels work in practice, how it compares with the NIST Cybersecurity Framework, and what compliance will look like for manufacturing, energy, and oil and gas operators in 2026.

 

Only 14% of industrial organizations report feeling fully prepared for OT cybersecurity threats despite the fact that IEC 62443 has provided a clear, actionable security framework for industrial control systems since its first publication in 2007. The standard exists. The adoption gap is the problem. Source: OT Cybersecurity Culture Gap Report, 2025

 

What IEC 62443 Is and Why It Was Developed

IEC 62443 - formally ISA/IEC 62443 - is the globally recognized series of standards for securing industrial automation and control systems. It was developed by the ISA99 committee in response to a straightforward problem: OT environments were being connected to IT networks and the internet, and the security frameworks developed for IT did not account for the operational constraints of industrial systems.

The core insight behind IEC 62443 is that OT security cannot be treated as a product problem. A firewall or an intrusion detection system is not a security program. Security requires a combination of governance policies, system architecture, and product-level technical controls - applied coherently across the full lifecycle of an industrial system from design through decommissioning.

The standard organizes those requirements into four series, each targeting a different stakeholder group in the industrial security ecosystem.

 

KEY	IEC 62443 is not a checklist. It is a risk-based framework that asks: what threats does this zone face, what are the consequences of a compromise, and what Security Level is required to defend against those threats? The answers drive architecture decisions, not the other way around.

 

The Four-Part IEC 62443 Series: What Each Section Covers

Understanding which part of the standard applies to your role is the first step to using it practically.

 

Series	Title	Who It Is For
62443-1 (General)	Foundational Concepts and Models	Security managers, architects - define terminology, risk assessment methodology, and the security lifecycle framework
62443-2 (Policies & Procedures)	IACS Security Management	Asset owners - covers security management systems, patch management, and supply chain security requirements
62443-3 (System)	System Security Requirements and Security Levels	System integrators and asset owners - define security levels (SL1-SL4) and zone/conduit architecture requirements
62443-4 (Component)	Product Security Requirements	Product suppliers and OEMs - define what security capabilities individual devices and software must support

 

For most asset owners - the operators of manufacturing plants, power generation facilities, pipelines, and water systems - the most immediately relevant series are 62443-2 (what your security management program must include) and 62443-3 (how your system architecture must be structured and what Security Level each zone must achieve).

62443-4 becomes relevant when you are procuring new OT equipment. Specifying Security Level requirements for PLCs, HMIs, and SCADA software in procurement contracts is one of the most underused but effective controls available to asset owners.

 

IEC 62443 Security Levels: How to Classify Your Zones Against Real Threats

The Security Level concept is what makes IEC 62443 operationally useful. Rather than applying a single blanket standard across your entire facility, the standard asks you to define security zones - logical groupings of assets with similar security requirements - and assign each zone a target Security Level based on the threats it realistically faces.

There are four Security Levels, each defined by the capability of the threat actor that the zone must be able to resist:

 

Level	Threat Actor	Capability	Example Control Requirement
SL 1	Casual/accidental	Unintentional misuse, no specific ICS knowledge	Basic authentication, user access controls, and audit logging
SL 2	Intentional, low-resource	Generic IT attack tools, no ICS-specific knowledge	Encrypted communications, MFA for remote access, and network segmentation
SL 3	Sophisticated, motivated	ICS-specific tools, insider threat, nation-state adjacent	Defense in depth, anomaly detection, and incident response planning
SL 4	Nation-state / APT	State-sponsored, unlimited resources, physical + cyber	Air gapping, hardware security modules, and classified-level controls

 

In practice, most North American industrial facilities should be targeting SL2 as their baseline across all zones, with SL3 applied to the highest-consequence zones - typically those controlling safety systems, critical production processes, or grid-connected assets.

SL1 is not a defensible baseline for any zone that is connected to a corporate IT network or the internet. If a zone is at SL1 and it has any path to an external network, it is a liability.

SL4 is typically reserved for defense and nuclear applications. If you operate a commercial or industrial facility and someone recommends SL4 controls across the board, that recommendation is not calibrated to your actual threat environment.

 

INSIGHT

The most common IEC 62443 implementation error is assigning the same Security Level to every zone in a facility. The standard is designed to be risk-proportionate. A packaging line controller does not require the same controls as the safety instrumented system on a chemical reactor.

 

Zones and Conduits: The Architecture Model That Replaces Purdue Levels

If you have read our previous post on the Purdue Model, you will recognize the concept of network segmentation. IEC 62443 formalizes and extends that concept through its zones-and-conduits model.

A zone is a logical grouping of assets that share a common security level requirement and are managed under a common security policy. A conduit is the controlled communication pathway between zones.

The zones and conduits model improves on the Purdue Model in one critical way: it is not constrained by physical or hierarchical network topology. A zone can span multiple Purdue levels if the assets within it share the same security requirements and access policies. This makes it more practical for modern industrial environments where flat networks, cloud connectivity, and remote access have blurred traditional Purdue boundaries.

Defining zones in practice:

• Start with consequence: Which assets, if compromised, would cause the highest operational, safety, or environmental impact? Those form your highest-priority zones.
• Group by function and access: Assets that are accessed by the same set of users and systems, and that perform related functions, belong in the same zone.
• Define conduit controls explicitly: Every communication path between zones must be documented, monitored, and controlled. Undocumented conduits - vendor connections, historian data flows, engineering laptop access - are where attacks propagate.
• Assign a target Security Level to each zone: Use the threat actor capability model above. For most operational zones, start with SL2 as your floor.

 

IEC 62443 vs NIST CSF: Which Framework Should OT Teams Follow?

This is one of the most common questions from IT/OT security leads who have been applying the NIST Cybersecurity Framework to their IT environment and are now extending their scope to OT. The honest answer is that the two frameworks serve different purposes, and most mature OT security programs use both.

 

Factor	IEC 62443	NIST CSF 2.0
Scope	Industrial automation and control systems specifically	All sectors, IT and OT, broader organizational scope
Structure	4-series standard with specific technical requirements	6 functions (Govern, Identify, Protect, Detect, Respond, Recover)
Security Levels	Defined SL1-SL4 per zone, maps to threat capability	Tiers 1-4 reflect program maturity, not threat specificity
Compliance Driver	Required or referenced in IEC, EU NIS2, and some NERC CIP contexts	Mandatory for US federal agencies, widely adopted by critical infrastructure
Best Use	Technical architecture and product certification for OT/ICS	Governance framework and program maturity assessment
North America Relevance	Growing adoption in manufacturing, energy, oil, and gas	Strong baseline for all critical infrastructure operators

 

The practical approach for North American industrial operators: use NIST CSF 2.0 as your governance and program maturity framework - it gives leadership a structured view of where the organization stands across the full security lifecycle. Use IEC 62443 as your technical architecture and compliance standard for the OT environment - it gives engineers and system integrators the specific requirements they need to design and validate secure industrial systems.

If you are subject to NERC CIP requirements, which apply to bulk electric system operators in North America, note that NERC CIP and IEC 62443 complement each other well. NERC CIP defines specific controls for critical cyber assets in the electric sector. IEC 62443 provides a broader architecture framework that helps you meet those controls systematically rather than in isolation.

 

How IEC 62443 Applies in the Industry in North America

Manufacturing

For discrete and process manufacturers, IEC 62443 compliance is increasingly a customer and supply chain requirement rather than a purely internal decision. Large industrial customers in automotive, aerospace, and food and beverage are beginning to require IEC 62443 certification from suppliers operating IACS that touch shared production data or networked systems. The most practical starting point for manufacturers is a 62443-2-1 security management program assessment combined with a 62443-3-3 system requirements gap analysis.

Energy and Utilities

Electric utilities subject to NERC CIP already operate within a mandatory compliance framework, but IEC 62443 provides the technical depth in the architecture that NERC CIP does not prescribe. The zones and conduits model maps directly to NERC CIP Electronic Security Perimeters. Oil and gas pipeline operators subject to TSA Security Directives will find IEC 62443 Security Level requirements align closely with TSA's requirements for access control, monitoring, and incident response in OT environments.

Oil and Gas

Upstream, midstream, and downstream operations each carry different risk profiles under IEC 62443. Upstream SCADA systems controlling remote wellhead equipment face high SL exposure due to internet-accessible RTUs and limited on-site security capability. Midstream pipeline operators face regulatory pressure from TSA Directives that reference IEC 62443-compatible controls. Downstream refinery operations typically have the highest process consequences per zone and should target SL3 for safety-critical systems.

 

How to Start an IEC 62443 Compliance Program Without Being Overwhelmed

IEC 62443 is a large standard. Organizations that try to implement all of it simultaneously achieve none of it effectively. The correct approach is phased, risk-prioritized, and grounded in your current architecture.

 

• Step 1 - Conduct a baseline gap assessment: Map your current architecture against IEC 62443-3-3 system requirements. Identify your zones, document your conduits, and assess the target Security Level each zone requires against your current capability.
• Step 2 - Prioritize by consequence: Focus initial remediation on the zones with the highest safety and operational consequence - not the largest number of assets. One compromised SIS controller poses a greater risk than 50 compromised HMIs.
• Step 3 - Stand up a 62443-2-1 security management program: Before investing in technology controls, establish governance. This means a formal OT security policy, a patch management process, an incident response plan, and a supply chain security review process.
• Step 4 - Enforce zone and conduit controls: Define formal conduit documentation, implement firewall rules that enforce it, and deploy OT-native network monitoring to detect conduit violations.
• Step 5 - Embed IEC 62443 requirements in procurement: Add Security Level requirements to vendor RFPs and contracts. Require compliance with 62443-4-2 for new OT equipment suppliers. This is the only way to improve baseline device security without replacing your entire installed base overnight.

 

BOTTOM LINE

IEC 62443 is the most technically complete framework available for securing industrial control systems. It is not the easiest standard to read, but it is the most useful one to follow. Organizations that implement it systematically - starting with a gap assessment and a risk-prioritized zone model - build security programs that hold up under both regulatory scrutiny and real-world attacks.

 

About Arista Cyber Arista Cyber helps industrial organizations in North America and Europe design, assess, and implement IEC 62443-aligned OT security programs. Our engagements are grounded in the operational realities of the facilities we protect, not in theoretical frameworks applied without regard for production constraints.

 

Frequently Asked Questions - IEC 62443 and OT Security

Is IEC 62443 mandatory in North America?

IEC 62443 is not a federal mandate in the US or Canada, but it is referenced or required in several regulatory and industry contexts. TSA Pipeline Security Directives reference IEC 62443-compatible controls. Some state-level utility regulations reference it. In the EU, the NIS2 Directive and the Cyber Resilience Act reference IEC 62443 compliance for critical infrastructure operators. For North American manufacturers supplying European customers, IEC 62443 compliance is increasingly a contractual requirement.

What is the difference between IEC 62443 and ISA 99?

ISA 99 is the ISA committee that developed the standard. IEC 62443 is the designation given to the standard upon its adoption by the International Electrotechnical Commission. They refer to the same body of work. You will see both designations used; ISA/IEC 62443 is the correct reference.

How long does IEC 62443 compliance take?

A realistic baseline gap assessment against IEC 62443-3-3 takes four to eight weeks for a medium-complexity industrial facility. Full compliance - meaning a documented security management program, defined zones and conduits, and remediated gaps against target Security Levels - typically takes twelve to twenty-four months for a facility that is starting from a low maturity baseline. Organizations with existing NERC CIP or NIST-aligned programs can move faster because the governance foundations are already in place.

Can a small or mid-size manufacturer implement IEC 62443?

Yes. The standard is designed to be scalable. A smaller facility with a limited number of control systems and a simpler network architecture will have a shorter path to compliance than a large refinery or power generation asset. The key is starting with a scoped gap assessment rather than attempting to address the entire standard at once. Prioritizing the highest-consequence zones first keeps the program manageable and delivers measurable risk reduction early.