IEC 62443 — Industrial Automation & Control System Security
Last verified2026-10 — parts of the series are revised on a rolling basis (62443-2-1 Edition 2 was published in 2024); check the current edition of each part.
What is this?ISA/IEC 62443 is the international series of standards for securing industrial automation and control systems (IACS): the PLCs, SCADA systems, safety systems and networks that run factories, power grids, water plants and pipelines. It is written jointly by the ISA99 committee and IEC Technical Committee 65, and it is the reference framework for operational technology (OT) security in the same way ISO 27001 is for IT.
Why It Matters
An OT incident can stop production, damage equipment, pollute water or hurt people. Stuxnet (2010) destroyed centrifuges; attacks on Ukraine's grid (2015, 2016) cut power; TRITON (2017) targeted a safety instrumented system designed to prevent explosions; Colonial Pipeline (2021) halted fuel supply after IT ransomware; FrostyGoop (2024) used Modbus commands to cut heating to homes.
Systems run for 20–30 years, patching needs a plant shutdown, many protocols have no authentication, and availability and safety come before confidentiality.
NIS2 brings energy, water, transport and manufacturing into scope (see NIS2); EU product rules such as the Cyber Resilience Act and the Machinery Regulation lean on 62443 for industrial products; buyers increasingly require 62443 certification from suppliers.
for OT, critical-infrastructure and manufacturing security roles assume you know zones and conduits, security levels and the Purdue model.
OT Foundations
IT versus OT priorities
| IT | OT | |
|---|---|---|
| Top priority | Confidentiality | Safety, then availability and integrity |
| System lifetime | 3–5 years | 15–30 years |
| Patching | Monthly, automated | Planned outages, vendor approval needed |
| Reboot to fix | Routine | Can stop a production line or a city's water |
| Protocols | Authenticated, encrypted | Often neither (Modbus, older DNP3, Profinet) |
| Active scanning | Normal | Can crash fragile controllers; prefer passive monitoring |
The Purdue model
A reference architecture, used for decades, that layers an industrial network. 62443 doesn't require it, but most zone designs start from it.
Level 5 Enterprise network / internet-facing ┐ IT Level 4 Business systems (ERP, email) ┘ ──────── Level 3.5 Industrial DMZ — historian replica, patch server, jump host ──── Level 3 Site operations (historian, MES, OT domain controller) ┐ Level 2 Supervisory control (SCADA, HMI, engineering workstations)│ OT Level 1 Basic control (PLCs, RTUs, safety controllers) │ Level 0 Physical process (sensors, actuators, motors, valves) ┘
The key rule: no direct traffic between IT (levels 4–5) and control (levels 0–2). Everything passes through the industrial DMZ, ideally with no single connection spanning it.
Key components
industrial computer running control logic.
field device for remote sites.
operator screens.
supervises geographically spread processes.
process control within a plant.
independent system that shuts the process down safely; the last line before physical harm.
time-series database of process data, often the bridge IT wants access to.
programs PLCs; a prime attacker target.
In practiceWhy "no authentication" matters: a passive OT monitoring sensor logging Modbus traffic. Any device that can reach a PLC on port 502 can write to it; the protocol has no idea who is asking.
time src dst proto function detail
2026-10-02 03:12:44 10.30.2.15 10.30.5.21 Modbus 03 Read Holding Regs addr 400-410 (HMI polling: normal)
2026-10-02 03:12:45 10.30.2.15 10.30.5.21 Modbus 03 Read Holding Regs addr 400-410
2026-10-02 03:13:02 10.20.8.77 10.30.5.21 Modbus 06 Write Single Register addr 405 = 1800 ← new source, from the IT range, writing a setpoint
ALERT new-talker + write function code to PLC-21 (Line 3 dosing pump)🎯On the job. OT detection is mostly "who talks to what, with which function": baseline the normal pairs (HMI → PLC reads, engineering workstation → PLC writes during maintenance windows) and alert on new talkers, writes, firmware downloads and PLC mode changes.
How the Standard Is Organised
The four groups
concepts, terminology and models (62443-1-1 introduces zones, conduits and security levels).
for organisations:
security programme requirements for asset owners (Edition 2, 2024, organised as security programme elements with a maturity model).
patch management in the IACS environment (technical report).
security programme requirements for service providers (integrators and maintenance providers).
for the integrated system:
security risk assessment and system design: how to divide a system into zones and conduits and assign target security levels.
system security requirements and security levels.
for product suppliers:
secure product development lifecycle requirements.
technical security requirements for components.
Roles — who uses which part
Asset owner (runs the plant) ──────────► 2-1 security programme, 3-2 risk assessment
│ hires
Service provider (integrator / maintainer) ► 2-4 programme, builds the system to 3-3
│ buys from
Product supplier (PLC, HMI, switch vendor) ► 4-1 development process, 4-2 component requirementsCore Concepts
Zones and conduits
- A zone is a group of assets (physical or logical) that share the same security requirements, for example "Line 3 control," "Safety systems," "Industrial DMZ."
- A conduit is a communication channel between zones, with the controls applied to it (firewall, data diode, encrypted tunnel, protocol filter).
┌───────────────┐ conduit C1: firewall, ┌──────────────────┐
│ Zone: IT │ only historian replication │ Zone: Industrial │
│ (Level 4) │◄─────────────────────────────►│ DMZ (Level 3.5) │
└───────────────┘ └────────┬─────────┘
conduit C2: firewall + jump host, MFA,
OT protocols allow-listed
┌────────▼─────────┐ conduit C3: ┌──────────────┐
│ Zone: Line 3 │ one-way data │ Zone: Safety │
│ control (L1–L2) │◄─────────────────│ system (SIS) │
└──────────────────┘ diode └──────────────┘Each zone gets a target security level, and each conduit is designed to protect the zone with the higher requirement.
Risk assessment and design (62443-3-2)
- Identify the system under consideration (SUC).
- Do an initial (high-level) risk assessment of worst-case consequences.
- Partition the system into zones and conduits (separate safety systems, wireless, devices reached from outside, IT/OT boundaries).
- Do a detailed risk assessment per zone and conduit (threats, vulnerabilities, consequences, likelihood).
- Assign a target security level (SL-T) to each zone and conduit.
- Document it all in a cybersecurity requirements specification (CRS).
Security levels (SL 0–4)
Security levels describe the strength of attacker a zone must withstand:
no specific protection.
casual or coincidental violation (an operator's mistake, accidental malware).
intentional violation using simple means, low resources, generic skills, low motivation (opportunistic attackers).
intentional violation using sophisticated means, moderate resources, IACS-specific skills, moderate motivation (hacktivists, organised crime targeting OT).
sophisticated means with extended resources, IACS-specific skills, high motivation (nation-state).
Three flavours:
what the risk assessment says the zone needs.
what a component or system can achieve when properly configured.
what the deployed zone actually achieves.
The goal is SL-A ≥ SL-T, using components whose SL-C supports it.
The seven foundational requirements (FR)
Every system (3-3) and component (4-2) requirement maps to one of seven foundational requirements:
know who and what is connecting.
enforce what authenticated users may do (authorisation, least privilege).
prevent unauthorised changes to software, firmware and data.
protect information on channels and in storage.
segment with zones and conduits; limit unnecessary flows.
log, detect and respond.
withstand denial of service, keep backups, ensure the process keeps running.
Maturity levels
Process maturity (in 2-1 and 4-1) is graded ML 1 Initial (ad hoc), ML 2 Managed (documented and repeatable), ML 3 Defined (practised across the organisation, consistently) and ML 4 Improving (measured and continuously improved).
Secure development for suppliers (62443-4-1)
Eight practices: security management; specification of security requirements; secure by design; secure implementation; security verification and validation testing; management of security-related issues (vulnerability handling); security update management; and security guidelines (hardening documentation for customers).
62443-4-2 then sets technical requirements by component type: software applications, embedded devices (PLCs), host devices (workstations, servers) and network devices (switches, firewalls).
In practiceA conduit expressed as a firewall policy between the industrial DMZ and a control zone — allow-list by source, destination, protocol and function:
# Conduit C2: Industrial DMZ (L3.5) → Line 3 control (L1-L2)
allow src=historian-relay dst=PLC-21..PLC-29 proto=modbus/502 fc=3,4 # read-only polling
allow src=jump-host-ot dst=EWS-03 proto=rdp/3389 schedule=maint-window mfa=required
deny any any any log=yes # everything elseDeep-packet-inspection OT firewalls can enforce the fc=3,4 part (read functions only), which a normal port-based firewall can't.
Certification
- Organisations and products — there is no single "62443 certified" label. Certification bodies (accredited under ISO/IEC 17065) assess against specific parts: asset owners against 2-1, service providers against 2-4, a supplier's development process against 4-1, components against 4-2 and systems against 3-3. ISASecure is the best-known programme, with five schemes: SDLA (a supplier's secure development lifecycle, 4-1, the prerequisite for product certification), CSA (components, 4-1 and 4-2), ICSA (IIoT components), SSA (systems, 3-3) and ACSSA (automation and control systems at asset-owner sites, against 2-1, 2-4, 3-2 and 3-3, with ongoing surveillance; its first certification body was accredited in 2026). The IECEE also certifies against 62443.
- People — ISA's ISA/IEC 62443 Cybersecurity Certificate Program has four specialist certificates (Cybersecurity Fundamentals Specialist, Risk Assessment Specialist, Design Specialist, Maintenance Specialist); holding all four earns the Cybersecurity Expert designation. The Fundamentals exam is the entry point and covers the concepts in this file.
Security Angle — Attacks and Defences in Practice
phishing or a VPN exploit into IT → credential theft → pivot through a poorly separated historian or remote-access path into OT → engineering workstation → modify PLC logic or HMI. Ransomware often never touches OT but forces a shutdown because IT dependencies (billing, scheduling) fail, or because nobody can prove OT is clean.
attackers use legitimate engineering software and protocol commands (Modbus writes, S7 commands), so detection relies on knowing normal process behaviour.
vendor remote-access tools and always-on VPNs are the most common way in. Use a brokered jump host in the DMZ, MFA, time-limited access, session recording.
asset inventory (you can't defend what you don't know), segmentation into zones with tight conduits, secure remote access, passive network monitoring with OT protocol awareness, offline and tested backups of PLC logic and configurations, and an OT-specific incident response plan that includes plant operations and safety.
prefer secure versions where they exist (OPC UA with security modes, DNP3 Secure Authentication, IEC 62351 for power-system protocols); where they don't, compensate with segmentation and allow-listing.
See also network segmentation and incident response.
📰Real incident — Unitronics PLCs at water utilities (2023). An Iran-linked group calling itself CyberAv3ngers took over internet-exposed Unitronics PLCs — many still on the default password — at water facilities including the Municipal Water Authority of Aliquippa in Pennsylvania, defacing their screens and forcing a switch to manual operation. The "attack" needed no exploit: a PLC on the internet with a default password.
📰Real incident — Colonial Pipeline (2021). Ransomware entered through a legacy VPN account without MFA and encrypted IT systems. The operational pipeline wasn't directly hit, but the company shut it down for days as a precaution, unable to bill or be sure OT was clean — causing fuel shortages across the US East Coast. IT incidents become OT outages through dependencies and uncertainty.
📰Real incident — FrostyGoop (2024). Malware that speaks Modbus TCP was used against a municipal heating company in Lviv, Ukraine, in January 2024, cutting heating to around 600 apartment buildings for two days in sub-zero temperatures. It was the first known malware to cause physical impact using Modbus directly, and the controllers were reachable from the internet.
📰Real incident — Norwegian dam valve (2025). In April 2025 attackers accessed the web control panel of a small dam in western Norway and opened a water-release valve for about four hours before it was noticed. Norway's security service later attributed it to pro-Russian actors. Small, internet-exposed sites with weak passwords are the soft underbelly of critical infrastructure.
🎯On the job. Start every OT assessment with an external check: search for your organisation's IP ranges on internet-scanning services for exposed HMIs, PLCs and remote-access portals. In many real incidents, that alone would have found the way in.
Interview Questions
A zone is a group of assets with the same security requirements, like a production line's controllers or the safety system, and a conduit is the communication path between zones along with the controls on it — firewalls, protocol filters, data diodes. You assign each zone a target security level from a risk assessment and design each conduit to protect the more sensitive side. It's segmentation driven by risk, and it's the heart of 62443-3-2.
Security levels describe the attacker a zone must withstand: SL1 against accidents and casual misuse, SL2 against intentional attacks with simple means and generic skills, SL3 against sophisticated attackers with OT-specific skills and moderate resources, and SL4 against well-resourced, highly motivated ones like nation-states. You set a target level per zone, pick components whose capability level supports it, and verify the achieved level in the deployed system.
Identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability. Every detailed system and component requirement in 3-3 and 4-2 hangs off one of these. Notice that availability and integrity get as much weight as confidentiality, which reflects OT priorities.
In OT, safety and availability come before confidentiality, systems run for decades, patching needs planned shutdowns and vendor approval, and many protocols have no authentication at all. Even active scanning can crash a fragile controller, so you lean on passive monitoring. That shifts the emphasis from patching and endpoint agents to segmentation, secure remote access, asset inventory and knowing normal process behaviour.
Asset owners running the plant use 2-1 for their security programme and 3-2 to risk-assess and design zones. Service providers who integrate and maintain systems use 2-4 and build to the system requirements in 3-3. Product suppliers use 4-1 for their secure development lifecycle and 4-2 for component requirements. The split is the standard's strength, because it gives every party in the supply chain a clear, certifiable responsibility.
Inventory what's on the plant network, ideally passively, then put an industrial DMZ between IT and OT so nothing talks directly across — the historian gets replicated into the DMZ and remote access goes through a jump host with MFA. Next I'd split OT into zones, starting by isolating the safety system and engineering workstations, and make sure PLC logic and configurations have offline, tested backups. Then run a 62443-3-2 risk assessment to set target levels and plan the rest.
ISA offers four specialist certificates — Fundamentals, Risk Assessment, Design and Maintenance — and holding all four earns the Cybersecurity Expert designation. The Fundamentals Specialist covers the core concepts: the standard's structure, zones and conduits, security levels, foundational requirements, maturity levels and the roles of asset owners, integrators and suppliers. It's the usual first step for someone moving from IT security into OT.