IEC 62443

IEC 62443 is not a single document but a family of related standards, and understanding the structure is essential for using it correctly. Series 1 establishes the foundational concepts, terminology, and security metrics that the rest of the standard family builds on. The most important document in this series for practitioners is IEC 62443-1-1, which defines the zone and conduit model, Security Levels, and Foundational Requirements. Series 2 addresses the security program requirements for asset owners, covering the security management system, patch management, incident response, and the security requirements that owners should impose on service providers and system integrators.

Series 3 covers system-level security requirements and is where the practical architecture work happens. IEC 62443-3-2 defines a risk assessment methodology for determining target Security Levels for zones. IEC 62443-3-3 defines the system-level security requirements that an IACS must meet at each Security Level, organized around the seven Foundational Requirements. Series 4 addresses component-level requirements. IEC 62443-4-1 defines a secure product development lifecycle that suppliers should follow, covering practices such as security requirements engineering, threat modeling, security testing, and vulnerability handling. IEC 62443-4-2 defines the technical security requirements for IACS components at each Security Level.

The practical implication of this structure is that different roles engage with different parts of the standard. An asset owner establishing a security program focuses on Series 2. A security architect designing a plant network focuses on Series 3. A PLC manufacturer implementing security features focuses on Series 4. When all parties use the standard for their respective roles, the result is a supply chain where security requirements flow consistently from the asset owner's risk assessment through the system integrator's design to the component supplier's product capabilities.

The zone and conduit model is the central architectural concept in IEC 62443 and its most practically useful contribution to ICS security. A zone is a grouping of assets that share the same security requirements and are governed by the same security policy. Assets are placed in the same zone when they have similar criticality, similar access requirements, and similar risk profiles. A conduit is a communication path between zones that must be secured according to the security requirements of the zones it connects. Every communication path between zones must be defined as a conduit with explicit security controls.

Security Levels define the capability required to resist attack at each zone. SL 1 addresses protection against unintentional or coincidental violations, such as misconfigurations or accidents. SL 2 addresses protection against intentional attacks by someone with basic skills, generic tools, and low motivation or resources. SL 3 addresses sophisticated attackers with specialized tools and significant motivation. SL 4 addresses nation-state level capabilities with the resources and determination to mount a sustained campaign. The target Security Level for a zone is determined by the consequence of compromise and the realistic threat actors the organization faces.

The Foundational Requirements provide the detailed capability checklist for each Security Level. The seven FRs are: Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, and Resource Availability. For each FR, the standard defines what capabilities must be present at SL 1, SL 2, SL 3, and SL 4. This gives system designers and evaluators a structured way to assess whether a proposed architecture or deployed system actually meets its target Security Level rather than simply asserting that it does.

One of IEC 62443's most important contributions is its explicit recognition that IACS security is a multi-party problem and that each party has distinct responsibilities. Asset owners are the organizations that operate the industrial system. They are responsible for defining the security requirements for their environment, conducting risk assessments, establishing security management programs, and ensuring that the systems they operate meet those requirements. Asset owners define the target Security Levels for their zones and specify security requirements in procurement contracts with integrators and suppliers.

System integrators design and deploy IACS on behalf of asset owners. They are responsible for designing an architecture that meets the target Security Levels defined by the asset owner, selecting components with appropriate security capabilities, integrating those components correctly, and documenting how the delivered system achieves the required security properties. IEC 62443-2-4 defines the security requirements that asset owners should impose on system integrators, covering practices such as security management during the project, security documentation, configuration management, and handover procedures.

Component suppliers manufacture the products that make up an IACS: PLCs, RTUs, SCADA software, network devices, and sensors. They are responsible for building security into their products during development, following a secure development lifecycle consistent with IEC 62443-4-1, implementing the technical security requirements defined in IEC 62443-4-2, and providing clear documentation of their products' security capabilities. When a supplier can demonstrate that their product is certified against IEC 62443-4-2 at a given Security Level, integrators and owners can make informed decisions about where to place that product in their architecture.

The IEC 62443 approach to risk assessment, described primarily in IEC 62443-3-2, is consequence-driven. The starting point is not a generic threat catalog but a specific analysis of what would happen if each zone were compromised: what physical process would be affected, what safety systems might fail, what regulatory obligations would be violated, and what the operational and financial impact would be. This consequence analysis is what determines the target Security Level for each zone, and it grounds the entire security program in operational reality rather than abstract risk scores.

The risk assessment process identifies the assets in scope, groups them into candidate zones, analyzes the consequences of compromise for each zone, identifies the threat actors relevant to the organization and environment, and uses that combination of consequence and threat to determine a target Security Level. The resulting zone map with assigned Security Levels becomes the baseline against which architecture design, component selection, and ongoing operations are evaluated.

An important practical consideration is the gap analysis between the target Security Level and the current state. Most operational IACS environments will have zones with target Security Levels that their current controls do not meet. The gap analysis identifies specific deficiencies in the seven Foundational Requirements and creates an actionable remediation roadmap. Prioritizing gaps by consequence and feasibility, rather than trying to close all gaps simultaneously, is the approach that produces sustainable security improvement in environments where operational continuity constraints limit how aggressively changes can be made.

Organizations approaching IEC 62443 for the first time are often intimidated by the scale of the standard family. The practical starting point is Series 2, specifically establishing an IACS security management system that defines governance, ownership, and a repeatable process for managing security. Without a management system, technical controls tend to degrade over time as people change, architectures evolve, and exceptions accumulate without review. The management system is what makes security improvements durable.

From the management system foundation, the next step is the zone and conduit analysis from Series 3. Even a simplified version, mapping assets to zones and documenting all communication paths as conduits, immediately surfaces architectural gaps and creates a structured view of the security landscape that most OT environments lack. This analysis does not need to be perfect to be valuable: a rough zone map with honest Security Level targets is far more useful than no map at all, because it enables prioritized remediation rather than ad hoc response.

Sustaining IEC 62443 compliance over time requires treating it as a living program rather than a project with an end date. Assets change, new connectivity is added, threats evolve, and vulnerabilities in deployed components are discovered. The patch management, change management, and incident response processes defined in Series 2 are what keep the security posture aligned with the evolving reality of the environment. Organizations that successfully embed IEC 62443 into their operational processes find that it provides a consistent framework for evaluating the security implications of operational changes, which reduces the risk of well-intentioned operational improvements inadvertently creating security gaps.