IEC 62443 Risk Assessment: The Complete Guide to Securing Industrial Automation and Control Systems

In February 2021, an attacker gained remote access to a water treatment facility in Oldsmar, Florida, and attempted to increase the sodium hydroxide concentration in the water supply to dangerous levels.

The intrusion was detected and reversed by an alert operator within minutes. The technical barrier between the attacker and a poisoned water supply was almost nothing: a shared TeamViewer password on an internet-facing computer connected directly to the plant’s SCADA system.

That incident captured headlines, but it was not an outlier. CISA reported that cyberattacks targeting industrial automation and control systems (IACS) doubled in 2024, with ransomware attacks on SCADA systems averaging $13 million in damages per incident. Colonial Pipeline. JBS Foods. Norsk Hydro.

The list of organizations that have suffered operational shutdowns from cyberattacks on their industrial systems continues to grow.

The ISA/IEC 62443 series of standards exists to address exactly this problem. Developed by the International Society of Automation (ISA) and published internationally through the International Electrotechnical Commission (IEC), IEC 62443 is the only globally recognized set of standards purpose-built for securing industrial automation and control systems across their entire lifecycle.

At the center of IEC 62443 sits the risk assessment: a structured, methodical process for identifying threats to IACS, evaluating the likelihood and consequence of those threats materializing, and determining the security measures required to reduce risk to a tolerable level.

This guide walks through the complete IEC 62443 risk assessment process, from foundational concepts through execution. For readers building or refreshing a broader enterprise risk management program that needs to incorporate OT cybersecurity, see our guide to enterprise risk management frameworks.

What Is IEC 62443? Structure and Purpose

IEC 62443 is a series of standards, not a single document. The series is organized into four main categories, each addressing a different dimension of IACS security. Understanding this structure matters because the risk assessment process draws on concepts defined across multiple parts of the series.

A founding principle of IEC 62443 is shared responsibility. Security is not the sole obligation of the asset owner (the organization operating the IACS), nor the system integrator (who designs and builds the solution), nor the product supplier (who manufactures the components).

All three stakeholder groups carry defined security obligations under the standard. The risk assessment, primarily governed by IEC 62443-3-2, is the mechanism through which the asset owner determines what level of security each part of the system requires.

The 2024 update to ISA/IEC 62443-2-1 was a significant milestone. The revised standard aligns risk assessment methodologies with ISO/IEC 27005 and NIST SP 800-30, standardizing risk assessment practices across IT and OT domains.

This harmonization means organizations can apply a consistent risk vocabulary and methodology whether they are assessing risks to their corporate network or their plant floor SCADA system. For context on how ISO 31000 provides the overarching risk management principles that IEC 62443 operates within, see our article on what ISO 31000 is and how to get started.

Key Concepts: Zones, Conduits, and Security Levels

Before conducting a risk assessment under IEC 62443, three foundational concepts must be understood: zones, conduits, and security levels. These concepts are the architectural building blocks that the risk assessment process operates on.

Zones

A zone is a logical or physical grouping of assets that share common security requirements. Every IACS component must be assigned to exactly one zone. The purpose of zoning is to segment the system into manageable units that can be independently assessed and protected.

A zone might be defined by physical location (all assets in a specific control room), by function (all safety instrumented systems), by network boundary (all devices on a particular VLAN), or by a combination of these factors. The key criterion is that assets within a zone share a common security level target, meaning they face similar threats and require similar protections.

IEC 62443 leverages a reference model commonly known as the Purdue Reference Model (derived from the Purdue Enterprise Reference Architecture) to describe how data flows through industrial networks.

The model defines hierarchical levels based on function and response time, from Level 0 (physical process) through Level 4 (enterprise network). Zones are typically defined with reference to these levels.

Conduits

A conduit is any communication path between zones. Conduits control what data can flow between zones, and they are where many security controls (firewalls, data diodes, protocol filters, DMZs) are implemented. A conduit might be a physical cable, a network segment, a VPN tunnel, or even a removable media procedure.

The critical point is that every data flow between zones must traverse a defined conduit with explicit security controls. Uncontrolled data paths between zones are a primary source of risk in IACS environments.

Security Levels (SL)

Security levels are the mechanism IEC 62443 uses to quantify how much security a zone or conduit requires. The standard defines four security levels, each representing a different threat capability:

IEC 62443 distinguishes between three types of security levels. SL-T (Target) is the security level the asset owner determines is required for a zone based on the risk assessment. SL-C (Capability) is the security level that the system or component is capable of providing when properly configured.

SL-A (Achieved) is the security level actually achieved after implementation. The risk assessment process produces SL-T values. The design and implementation process must then ensure SL-C and SL-A meet or exceed SL-T.

The Seven Foundational Requirements

Each security level is defined across seven foundational requirements (FRs). These requirements specify the security capabilities that must be present at each level. Understanding the FRs is essential because the risk assessment ultimately determines which level of each FR applies to each zone.

These foundational requirements map directly to the security controls that organizations must implement. For guidance on how to track cybersecurity controls and KRIs against these requirements, see our article on NIST cybersecurity key risk indicators mapped to CSF 2.0.

The IEC 62443-3-2 Risk Assessment Process: Step by Step

IEC 62443-3-2 (Security Risk Assessment for System Design) defines the risk assessment methodology. The standard does not prescribe a single rigid process but requires that the methodology be compatible with the organization’s overall risk management framework.

The steps below synthesize the requirements of IEC 62443-3-2 with practical implementation guidance from ISA, NIST SP 800-82 Rev. 3, and field experience. For a broader view of the risk assessment process applicable across all risk domains, see our complete guide to the risk assessment process.

Step 1: Define the System Under Consideration (SUC)

The first step is to establish the scope and boundaries of the IACS being assessed. This requires a detailed understanding of the physical and logical architecture of the system, including all hardware, software, network components, data flows, and connections to external systems.

Practical requirements for this step include:

• Asset inventory: Document every device, controller, workstation, server, network switch, firewall, and field instrument within the IACS. Include firmware versions, operating systems, patch levels, and communication protocols.
• Network topology: Map all network segments, connections between segments, connections to the enterprise network, connections to the internet (including remote access paths), and wireless access points.
• Data flow diagrams: Document what data moves between components, in what direction, using what protocol, and for what purpose.
• Physical layout: Document where equipment is physically located, who has physical access, and what physical security measures are in place.
• External connections: Identify every path by which data can enter or leave the IACS boundary, including vendor remote access, historian connections, cloud services, and removable media.

Many organizations discover during this step that their actual IACS architecture differs significantly from their documented architecture.

Undocumented connections, shadow IT devices, and legacy systems that no one has inventoried are common findings. The risk assessment cannot be accurate if the asset inventory and network topology are not accurate.

Step 2: Partition into Zones and Conduits

With the SUC documented, the next step is to partition the system into zones and conduits. IEC 62443-3-2 provides criteria for zoning decisions:

• Criticality grouping: Assets with similar consequence profiles (e.g., all safety instrumented systems) should be in the same zone.
• Functional grouping: Assets that serve the same operational function and communicate frequently should be in the same zone.
• Access requirements: Assets that require the same access control policies should be in the same zone.
• Threat exposure: Assets exposed to similar threats (e.g., all internet-facing systems) should be in the same zone.
• Legacy constraints: Systems that cannot be patched or upgraded may need to be isolated in their own zone with compensating controls at the conduit level.

A common zoning pattern for a typical manufacturing facility might include: a Level 3.5 Industrial DMZ zone (historians, patch management servers), a Level 3 Site Operations zone (engineering workstations, OPC servers), a Level 2 Area Supervisory Control zone (HMIs, SCADA servers), a Level 1 Basic Control zone (PLCs, RTUs, controllers), a Level 0 Process zone (sensors, actuators, instruments), and a Safety Instrumented Systems zone (SIS controllers, safety logic solvers).

Each conduit between zones must be documented with the data flows it carries, the protocols used, and the security controls in place. The conduit between the enterprise network (Level 4) and the industrial DMZ (Level 3.5) is typically the highest-risk conduit and receives the most security controls.

Step 3: Conduct Threat Assessment

For each zone and conduit, identify the threats that could compromise security. IEC 62443 considers threats across all seven foundational requirements. The threat assessment should consider:

• Threat sources: Nation-state actors, organized crime, hacktivists, insiders (malicious and negligent), competitors, and terrorists. The applicable threat sources depend on the industry, geography, and geopolitical context.
• Attack vectors: Network-based attacks (from enterprise network, internet, wireless), physical access attacks (USB, direct console access, insider sabotage), supply chain attacks (compromised firmware, backdoored software updates), and social engineering.
• Threat intelligence: Use sector-specific threat intelligence from CISA ICS-CERT advisories, ISACs (Information Sharing and Analysis Centers), and vendor security bulletins.

The threat assessment directly informs the target security level (SL-T) for each zone. If the threat assessment identifies nation-state actors as a credible threat for a particular zone (e.g., the safety system of a nuclear facility), that zone will require SL 4. If the primary threat is opportunistic malware from the enterprise network, SL 2 may be sufficient.

Step 4: Assess Vulnerabilities

Identify the vulnerabilities in each zone and conduit that could be exploited by the identified threats. Vulnerability sources include:

• Technical vulnerabilities: Unpatched software, default credentials, insecure protocols (Telnet, FTP, Modbus without authentication), unnecessary open ports, and weak encryption.
• Configuration vulnerabilities: Overly permissive firewall rules, shared accounts, lack of network segmentation, and misconfigured access controls.
• Architectural vulnerabilities: Flat networks with no segmentation between IT and OT, direct internet connections to SCADA systems, and single points of failure.
• Process vulnerabilities: No change management procedures, infrequent patching, lack of incident response plans, and insufficient employee training.
• Physical vulnerabilities: Unlocked control panels, unmonitored access to control rooms, and exposed network ports in public areas.

IEC 62443 recognizes that IACS environments face unique vulnerability challenges. Many industrial control system components have lifecycles exceeding 20 years, run on operating systems that are no longer supported, and cannot be patched without shutting down production.

The 2024 update to ISA/IEC 62443-2-1 explicitly acknowledges this reality and provides guidance for legacy systems where standard patching requirements cannot be met. For a framework-level view of how vulnerability assessment fits into the broader risk management process, see our article on the ISO 31000 vs COSO ERM framework comparison.

Step 5: Determine Consequence and Impact

For each zone, assess the consequences if a threat successfully exploits a vulnerability. IEC 62443 considers consequences across multiple dimensions, with particular emphasis on impacts unique to industrial environments:

The HSE dimension is what distinguishes IEC 62443 risk assessments from IT-centric cybersecurity assessments. In IT, the worst-case scenario for a security breach is typically data loss or financial theft.

In IACS, the worst-case scenario is physical harm to people or the environment. This is why safety systems (SIS) are almost always assigned the highest security levels and placed in their own dedicated zones.

Step 6: Calculate Risk and Assign Target Security Levels

Risk is calculated as a function of the likelihood of a threat exploiting a vulnerability and the consequence of that exploitation. IEC 62443-3-2 does not mandate a specific risk scoring formula, but the following 5×5 risk matrix is widely used in practice:

IEC 62443 Risk Assessment Matrix:

The output of this step is a target security level (SL-T) for each zone and each conduit. The SL-T is the security level that the zone must achieve to reduce risk to a tolerable level.

Organizations then compare SL-T against the current achieved security level (SL-A) for each zone. The gap between SL-T and SL-A defines the scope of the security improvement program.

Step 7: Document and Define Countermeasures

The final step is to identify the specific countermeasures (security controls) required to achieve the target security level for each zone and conduit. Countermeasures are mapped to the seven foundational requirements and the specific system requirements (SRs) defined in IEC 62443-3-3.

For example, if a zone requires SL 3 for FR 1 (Identification and Authentication), the countermeasures must include unique identification for all users and devices, multi-factor authentication for all access, and centralized account management.

The specific requirements are defined in IEC 62443-3-3, which lists the SRs and requirement enhancements (REs) applicable at each security level. For guidance on tracking these countermeasures in a risk register, see our article on key elements of a risk register.

All risk assessment findings, security level assignments, and countermeasure requirements must be documented in a formal risk assessment report. This document serves as the basis for the security architecture design and becomes part of the organization’s Cybersecurity Management System (CSMS) as required by IEC 62443-2-1.

How IEC 62443 Integrates with Other Standards and Frameworks

IEC 62443 does not exist in isolation. Most organizations operating IACS must comply with multiple standards and frameworks simultaneously. The 2024 updates to the series explicitly harmonize with several complementary frameworks.

For organizations managing both information security and industrial cybersecurity, the ISO 27001 framework often serves as the ISMS foundation, with IEC 62443 providing OT-specific extensions. Our guide to ISO 27001 risk assessment methodology covers the information security side of this integrated approach.

Industry-Specific Applications of IEC 62443 Risk Assessment

Energy and Utilities

Electric utilities, oil and gas pipelines, and water treatment facilities face some of the most severe threat landscapes for IACS. TSA Security Directives now require pipeline operators to implement specific cybersecurity measures.

NERC CIP standards govern the electric grid. IEC 62443 risk assessments in this sector must account for nation-state threats (SL 3-4 for critical generation and transmission assets), cascading failure scenarios where a single compromise can affect millions of customers, and the intersection of cyber and physical safety risks.

Manufacturing

Manufacturing environments typically combine legacy systems (PLCs and DCS controllers running for 15-20+ years), modern IIoT devices, and increasing cloud connectivity for analytics and remote monitoring. IEC 62443 risk assessments must address the full spectrum, from unpatched Windows XP historian servers to cloud-connected edge devices.

The primary consequences are operational (production loss, equipment damage) and financial, though chemical manufacturing and pharmaceutical operations may face significant HSE consequences. For machine-level risk assessment in manufacturing environments, see our article on the ISO 12100 risk assessment template.

Transportation

Rail systems, aviation, maritime operations, and traffic management systems all rely on IACS. The consequences of compromise include direct safety risks to passengers and the public. IEC 62443 risk assessments for transportation must integrate with sector-specific safety standards and regulatory requirements (FRA, FAA, TSA, Coast Guard).

Building Automation

Building management systems (BMS) controlling HVAC, fire safety, elevators, and physical access are increasingly IP-connected and cloud-managed. While often overlooked, a compromised BMS can disable fire suppression, lock or unlock access doors, or create physical safety hazards. In 2021, IEC recognized IEC 62443 as a horizontal standard applicable across all industry verticals using operational technology, explicitly including building automation.

Common Mistakes in IEC 62443 Risk Assessments

Treating the risk assessment as an IT exercise. IEC 62443 risk assessments require OT engineers, process safety engineers, and control system experts at the table. An IT security team conducting the assessment alone will miss critical operational context: which processes can and cannot tolerate latency, which controllers cannot be restarted without a physical presence, and which safety interlocks must remain functional under all conditions.

Incomplete asset inventory. If you do not know what is connected to your industrial network, you cannot assess the risk to it. Passive network monitoring and active asset discovery tools designed for OT environments are essential before beginning the risk assessment.

Ignoring safety system cybersecurity. Safety Instrumented Systems are designed to prevent catastrophic events. If a cyber attacker can compromise the SIS (as the TRITON malware attempted at a Saudi Arabian petrochemical facility in 2017), the consequences can be fatal. SIS must always be assessed as a separate zone with the highest applicable security level.

Applying uniform security levels. Not every zone needs the same security level. A data historian in the DMZ does not require the same protections as a safety controller. Uniform security levels waste resources on low-risk zones and may still leave high-risk zones underprotected.

Performing the assessment once and filing it. IEC 62443 requires continuous review. The risk assessment must be updated when systems change, when new threats emerge, when incidents occur, or at defined intervals. The industrial threat landscape evolves continuously, and so must the assessment.

Not involving product suppliers and integrators. Under IEC 62443’s shared responsibility model, product suppliers must provide products capable of meeting the required security levels (SL-C), and integrators must implement them correctly. If the risk assessment does not involve these stakeholders, the resulting security requirements may be technically infeasible.

Practical Implementation Roadmap

For organizations beginning an IEC 62443 risk assessment program, the following phased approach provides a practical starting point. For the broader risk management context in which this roadmap operates, see our five steps of the risk management process.

Phase 1: Foundation (Months 1-3)

• Establish an IACS asset inventory using passive network monitoring and physical walkthroughs.
• Document the network architecture, all external connections, and all data flows between IT and OT.
• Identify the team: OT engineers, control system specialists, process safety engineers, IT security, and a risk management lead.
• Select the risk assessment methodology and define the organization’s risk tolerance criteria for IACS.

Phase 2: Assessment (Months 3-6)

• Partition the IACS into zones and conduits based on the Purdue model and organizational architecture.
• Conduct threat assessments for each zone using sector-specific threat intelligence.
• Perform vulnerability assessments (both technical scanning where safe to do so, and manual review of configurations and architectures).
• Calculate risk scores and assign target security levels (SL-T) for each zone and conduit.
• Document findings in a formal risk assessment report.

Phase 3: Remediation Planning (Months 6-9)

• Identify security control gaps (where SL-A falls below SL-T for each zone).
• Define compensating controls for legacy systems that cannot meet requirements natively.
• Develop a prioritized remediation roadmap with timelines, resource requirements, and budget.
• Incorporate IEC 62443 requirements into procurement specifications for new systems and components.

Phase 4: Continuous Program (Ongoing)

• Implement monitoring and detection capabilities (IDS, behavioral anomaly detection, log collection from OT devices).
• Establish a change management process that triggers risk reassessment for any modification to the IACS.
• Conduct periodic reassessments (annually at minimum, or when triggered by system changes, incidents, or new threat intelligence).
• Report security posture and risk trends to leadership using metrics aligned to the seven foundational requirements.

For guidance on building KRI dashboards that track IEC 62443 security posture, see our article on cybersecurity key risk indicators.

Regulatory Context: U.S. Requirements for Industrial Cybersecurity

While IEC 62443 itself is a voluntary consensus standard in the United States, multiple U.S. regulatory frameworks either reference it directly, require equivalent capabilities, or create legal obligations that an IEC 62443 risk assessment can satisfy.

• TSA Security Directives: Following the Colonial Pipeline attack, TSA issued Security Directives requiring pipeline and rail operators to implement cybersecurity measures including network segmentation, access control, continuous monitoring, and incident response plans. IEC 62443 risk assessments directly address these requirements.
• NERC CIP Standards: Mandatory for the electric utility sector, NERC CIP standards require identification of critical cyber assets, electronic security perimeters, access management, and security monitoring. IEC 62443 zones and conduits map directly to NERC CIP Electronic Security Perimeters.
• CFATS (Chemical Facility Anti-Terrorism Standards): DHS requires high-risk chemical facilities to implement cybersecurity measures for IACS that control chemical processes.
• NIST SP 800-82 Rev. 3: While not regulatory, NIST SP 800-82 is the primary federal guidance for OT security and is widely referenced in audits, assessments, and compliance programs across critical infrastructure sectors.
• SEC Cybersecurity Disclosure Rules (2023): Public companies must disclose material cybersecurity risks and incidents. For companies with significant IACS operations, OT cybersecurity risk (as assessed through IEC 62443) may constitute material risk requiring disclosure.

Frequently Asked Questions

What is the difference between IEC 62443 and ISO 27001?

ISO 27001 is a general-purpose information security management system (ISMS) standard applicable to any organization handling information assets. IEC 62443 is purpose-built for industrial automation and control systems.

The key difference is that IEC 62443 addresses the unique characteristics of OT environments: safety implications (cyber compromise can cause physical harm), availability priorities (uptime is typically more critical than confidentiality), long asset lifecycles (20+ year equipment that cannot be easily patched), and real-time performance requirements. Organizations with both IT and OT environments typically implement ISO 27001 for IT and use IEC 62443 as the OT-specific extension.

Who should conduct an IEC 62443 risk assessment?

An IEC 62443 risk assessment requires a multidisciplinary team including OT/control system engineers (who understand the physical processes and control logic), IT/cybersecurity specialists (who understand threats, vulnerabilities, and network security), process safety engineers (who understand the safety implications of control system compromise), and risk management professionals (who understand risk assessment methodology).

External specialists with IEC 62443 certification may be needed, particularly for the initial assessment. ISA offers specific training and certification programs for IEC 62443 practitioners.

How often should the risk assessment be updated?

IEC 62443-2-1 requires periodic reassessment. In practice, organizations should conduct a full reassessment at least annually, and trigger reassessments whenever significant changes occur: new equipment or systems are added, network architecture changes, new threat intelligence indicates changed risk, after a security incident, when regulatory requirements change, or when the organization’s risk tolerance changes.

Can IEC 62443 be applied to existing legacy systems?

Yes. The 2024 update to ISA/IEC 62443-2-1 explicitly recognizes that IACS lifecycles can exceed 20 years and that many legacy systems contain unsupported hardware and software. For legacy systems, the standard allows a subset of requirements to be addressed through compensating controls: network isolation, monitoring, restricted access, and additional physical security measures.

The risk assessment should identify which zones contain legacy systems and what compensating controls are needed to achieve the target security level.

What are the costs of implementing IEC 62443?

Costs vary significantly based on organizational size, complexity, and current security maturity. A mid-sized manufacturing facility conducting its first IEC 62443 risk assessment might budget $50,000-$150,000 for the assessment phase (including external expertise and asset discovery tools), with remediation costs ranging from $200,000 to several million depending on the gap between current state and target security levels.

However, these costs must be weighed against the potential consequences of a successful attack. The average cost of a ransomware attack on SCADA systems was $13 million in 2024.

Does IEC 62443 certification exist?

Yes. ISASecure, operated by the ISA Security Compliance Institute, offers certification programs aligned with IEC 62443. These include Component Security Assurance (CSA) certification for products under IEC 62443-4-2, System Security Assurance (SSA) certification for systems under IEC 62443-3-3, Security Development Lifecycle Assurance (SDLA) certification for development processes under IEC 62443-4-1, and the forthcoming Automation and Control System Security Assurance (ACSSA) certification for operational systems.

Conclusion: IEC 62443 Risk Assessment Is Where OT Security Begins

Industrial automation and control systems are no longer isolated from cyber threats. The convergence of IT and OT, the growth of IIoT, and the increasing sophistication of threat actors targeting critical infrastructure have made industrial cybersecurity a business-critical concern.

The IEC 62443 risk assessment provides the structured methodology for determining what needs to be protected, against what threats, and to what level. It translates the abstract concept of OT cybersecurity risk into concrete, actionable security requirements: specific security levels for specific zones, mapped to specific controls across seven foundational requirements.

The process requires investment, both in expertise and in implementation. But the alternative, operating IACS without a systematic understanding of cybersecurity risk, is not a defensible position for any organization responsible for critical infrastructure, manufacturing operations, or processes with safety implications.

Start with an accurate asset inventory and network topology. Partition your systems into zones and conduits. Assess the threats, vulnerabilities, and consequences specific to your operations. Assign target security levels. Close the gaps. Monitor continuously. This is what IEC 62443 requires, and this is what effective industrial cybersecurity looks like in practice.

Build your industrial cybersecurity risk management capability. From enterprise risk management frameworks to cybersecurity KRI dashboards, our resource library covers the standards and practical tools that risk and security professionals rely on. Explore our guides at Risk Publishing to deepen your understanding of ISO 31000, NIST CSF, IEC 62443, and OT security risk assessment.

Sources and References

1. ISA. ISA/IEC 62443 Series of Standards. International Society of Automation. isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
2. ISA. ANSI/ISA-62443-2-1-2024: Security Program Requirements for IACS Asset Owners (January 2025).
3. NIST. SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security (September 2023). csrc.nist.gov/pubs/sp/800/82/r3/final
4. NIST. Cybersecurity Framework (CSF) 2.0 (February 2024). National Institute of Standards and Technology.
5. ISO 31000:2018. Risk Management Guidelines. International Organization for Standardization.
6. ISO/IEC 27001:2022. Information Security Management Systems. International Organization for Standardization.
7. CISA. ICS-CERT Advisories. Cybersecurity and Infrastructure Security Agency. cisa.gov/news-events/ics-advisories
8. Dragos. ISA/IEC 62443 Explained: OT Cybersecurity Standards (2025). dragos.com/blog/isa-iec-62443-concepts
9. Echelon Risk + Cyber. Navigating the 2024 Updates to ISA/IEC 62443.
10. NICCS/CISA. IEC 62443: Industrial Automation and Control Systems Cybersecurity Training. niccs.cisa.gov

Chris Ekai

Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.