IEC 62443 Guide: Zones, Conduits and Security Levels

Most industrial sites claim to "follow IEC 62443", yet few can show a zone and conduit diagram, a target security level for each zone, or a supplier certificate that matches the version actually installed. ISA/IEC 62443 is the international series for securing industrial automation and control systems (IACS), and it only works when asset owners, integrators, service providers and product suppliers each meet the part written for them. This guide covers the parts and roles, zones and conduits, security levels, the seven foundational requirements, ISASecure certification and brownfield application. It is for OT security leads, control engineers, integrators and buyers. For OT basics such as the Purdue model and industrial protocols, see the OT Security Guide.

Key takeaways

It is a role-based series, not one document. Asset owners use 62443-2-1 and 3-2, integrators and maintenance providers 2-4 and 3-3, and product suppliers 4-1 and 4-2. "62443 compliance" means little until you know which part and role.
Zones and conduits come before controls. The 62443-3-2 risk assessment partitions the system, then sets a target security level (SL-T) for each zone and conduit.
Three security level types must line up. SL-T is what the risk needs, SL-C is what a product or system can deliver, SL-A is what the installed system achieves. The gaps drive countermeasures.
Identity is the first foundational requirement. FR1 identification and authentication control and FR2 use control cover shared operator logins, device identity, vendor access and the service accounts HMIs and historians run on.
Brownfield is the normal case. IEC 62443-2-1:2024 itself says the security programme for most legacy systems addresses only a subset of its requirements, so compensating measures are expected.

How the 62443 series is organised

The series is developed by the ISA99 committee and adopted by the IEC; ISA states that the ISA and IEC editions are identical and that in 2021 the IEC recognised the series as a horizontal standard, applicable across industries. The documents fall into four groups: General (1-x), Policies and procedures (2-x), System (3-x) and Component (4-x). Editions below are from the IEC webstore and previews where read, otherwise from ISA's list (ANSI/ISA years can differ from IEC years).

Part	Title (short)	Current edition	Main user
62443-1-1	Terminology, concepts and models	Technical specification; ISA-62443-1-1 (2007)	Everyone
62443-2-1	Security program requirements for IACS asset owners	IEC 62443-2-1:2024, Edition 2.0 (7 August 2024)	Asset owner
62443-2-2	IACS security protection scheme	ISA technical report (2025)	Asset owner, assessors
62443-2-3	Patch management in the IACS environment	Technical report (ISA 2015)	Asset owner, supplier
62443-2-4	Security program requirements for IACS service providers	IEC 62443-2-4:2023, Edition 2.0	Integrator, maintenance provider
62443-3-2	Security risk assessment for system design	2020	Asset owner, integrator
62443-3-3	System security requirements and security levels	IEC 62443-3-3:2013, Edition 1.0 (corrigendum 2014)	Integrator, system supplier
62443-4-1	Secure product development lifecycle requirements	IEC 62443-4-1:2018, Edition 1.0	Product supplier
62443-4-2	Technical security requirements for IACS components	IEC 62443-4-2:2019, Edition 1.0	Product supplier

Edition 2.0 of 62443-2-1 is a substantial rewrite of what edition 1 called the cybersecurity management system (CSMS): requirements are restructured into security program elements (SPEs), duplication of an ISMS is removed so it can sit alongside ISO/IEC 27001, and a maturity model is defined for evaluating each requirement. Edition 2.0 of 62443-2-4 (December 2023) is editorial clarification without significant technical change. Check the IEC webstore for the current edition before a contract cites a part: 3-3 and the 4-x parts are the oldest editions in use.

Roles and shared responsibility

ISA describes shared responsibility as "an essential building block of automation cybersecurity". The ISA Global Cybersecurity Alliance quick start guide (a secondary overview, June 2020) defines the principal roles:

Asset owner: the organisation "accountable and responsible for the IACS". It owns the risk assessment, SL-T per zone, the 2-1 programme and residual risk approval.
Integration service provider: designs and builds the automation solution, implements zones and conduits, and evidences its processes under 2-4.
Maintenance service provider: supports the automation solution in operation (patching, backups, remote support), also under 2-4.
Product supplier: "manufactures and supports a hardware and/or software product". It runs a secure development lifecycle (4-1) and ships components with stated capabilities (4-2) and deployment guidelines.

The IACS also includes people and operating policies, so a supplier can certify a control system but only the asset owner can run a secure IACS.

Zones and conduits

A zone is "a grouping of logical or physical assets based upon risk or other criteria"; a conduit is "a logical grouping of communication channels that share common security requirements" (ISAGCA definitions). Zones are drawn on consequence and trust, not on VLANs that happen to exist.

Separate by consequence: the safety instrumented system (SIS) is its own zone, never shared with the basic process control system it protects.
Separate by function and owner: production lines, utilities, building management, the industrial DMZ and vendor-managed skids are typical zones.
Separate by exposure: anything with wireless, cellular or cloud connectivity sits in a zone whose conduit is treated as untrusted.
Define every conduit: endpoints, protocols and ports, direction, initiating side, owner and enforcing device (firewall, unidirectional gateway or jump host). Dual-homed hosts are conduits too.

Zone boundaries are enforced by SR 5.1 network segmentation and SR 5.2 zone boundary protection in 62443-3-3. For segmentation technology choices, see the Network Segmentation Guide.

Security levels: SL-T, SL-C and SL-A

Security levels describe the attacker a zone, conduit, system or component is designed to withstand. The definitions below are from the ISAGCA quick start guide; SL 0 means no specific requirements or protection.

Level	Protection against	Practical reading
SL 1	Casual or coincidental violation	Mistakes: an operator in the wrong screen, a laptop plugged into the wrong port
SL 2	Intentional violation using simple means, low resources, generic skills, low motivation	Commodity malware, opportunistic misuse of default or shared credentials
SL 3	Intentional violation using sophisticated means, moderate resources, IACS-specific skills, moderate motivation	Criminal groups or insiders who understand industrial protocols and engineering tools
SL 4	Intentional violation using sophisticated means, extended resources, IACS-specific skills, high motivation	State-level campaigns built for a specific process

SL-T (target): the desired level for a zone or conduit, set by the 3-2 risk assessment and recorded in the cybersecurity requirements specification.
SL-C (capability): what a component (4-2) or system (3-3) can deliver natively when properly integrated and configured. 62443-3-3 states that its scope is SL-C; SL-T and SL-A are out of its scope.
SL-A (achieved): what the installed solution actually achieves in operation; it degrades as configuration drifts.

Levels are set per foundational requirement, so a zone may need SL 3 for FR1 and FR5 but SL 1 for FR4 where data is not confidential. In 4-2, each component requirement (CR) has requirement enhancements (REs), and "the combination of CRs and REs is what will determine" the level a component can reach. Where SL-C is below SL-T, close and document the gap with compensating countermeasures at the zone boundary or in procedures.

The seven foundational requirements

62443-3-3 groups 51 system requirements (SRs) under seven foundational requirements (FRs); 62443-4-2 mirrors them as component requirements. Selected SRs from the 3-3 table of contents:

FR	Purpose	Selected system requirements
FR1 Identification and authentication control	Know who and what is connecting	SR 1.1 human user, SR 1.2 software process and device, SR 1.3 account management, SR 1.5 authenticator management, SR 1.7 password strength, SR 1.8 PKI certificates, SR 1.11 unsuccessful login attempts, SR 1.13 access via untrusted networks
FR2 Use control	Enforce what an authenticated identity may do	SR 2.1 authorisation enforcement, SR 2.3 portable and mobile devices, SR 2.5 session lock, SR 2.6 remote session termination, SR 2.8 auditable events, SR 2.11 timestamps, SR 2.12 non-repudiation
FR3 System integrity	Prevent unauthorised change	SR 3.1 communication integrity, SR 3.2 malicious code protection, SR 3.4 software and information integrity, SR 3.5 input validation, SR 3.9 protection of audit information
FR4 Data confidentiality	Protect information in transit and at rest	SR 4.1 information confidentiality, SR 4.2 information persistence, SR 4.3 use of cryptography
FR5 Restricted data flow	Enforce zones and conduits	SR 5.1 network segmentation, SR 5.2 zone boundary protection, SR 5.3 person-to-person communication restrictions, SR 5.4 application partitioning
FR6 Timely response to events	Detect and respond	SR 6.1 audit log accessibility, SR 6.2 continuous monitoring
FR7 Resource availability	Keep the process running	SR 7.1 denial of service protection, SR 7.3 backup, SR 7.4 recovery and reconstitution, SR 7.6 network and security configuration settings, SR 7.7 least functionality, SR 7.8 component inventory

4-2 adds CR 1.14 strength of symmetric key-based authentication and CR 2.13 use of physical diagnostic and test interfaces, and groups requirements by component type: software application (SAR), embedded device (EDR), host device (HDR) and network device (NDR). Its constraint CCSC 1 requires countermeasures to support essential functions: a failed-login lockout must never block an operator from the HMI during an upset.

Where identity fits: FR1 and FR2 in practice

FR1 and FR2 are where brownfield sites usually fall furthest short, because shared logins, vendor default passwords and long-lived service accounts are built into how plants run.

Shared operator accounts (SR 1.1): higher levels require unique identification of every human user. Where shift handover makes individual HMI logins impractical, keep a shared view-only session but require individual authentication for setpoint changes, alarm shelving and mode changes, logged under SR 2.8.
Software process and device identity (SR 1.2): historians, OPC servers and SCADA services authenticate to each other with service accounts or certificates. Inventory them, give each an owner and remove interactive logon rights. See the Service Account Security Guide.
Authenticator management (SR 1.5): change default credentials at commissioning, record it in the integrator handover, and vault controller and engineering passwords inside the OT zone.
Access via untrusted networks (SR 1.13): vendor and remote engineering access should terminate in the DMZ on a broker with MFA, approval and session recording. The Colonial Pipeline ransomware attack began with a single unused VPN account without MFA, the exact failure SR 1.13 and SR 1.3 account management are meant to prevent. See the Remote Access Identity Guide.
Authorisation enforcement (SR 2.1): separate operator, engineer and administrator roles, and restrict controller programming to engineering workstations in their own sub-zone. See the Privileged Access Management Guide.

MITRE ATT&CK for ICS lists T0859 Valid Accounts under both Persistence and Lateral Movement, with mitigations including M0932 Multi-factor Authentication and M0926 Privileged Account Management. For an OT identity architecture in depth, see the OT and ICS Identity and Access Guide.

Risk assessment with 62443-3-2

62443-3-2 defines the zone and conduit requirements (ZCRs) that turn a system description into a cybersecurity requirements specification:

ZCR 1, identify the system under consideration (SUC): the boundary, the assets inside it and every access point that crosses it.
ZCR 2, initial cybersecurity risk assessment: worst-case consequence assuming compromise, usually drawn from the site's existing process hazard analysis (HAZOP or LOPA).
ZCR 3, partition into zones and conduits: as described above.
ZCR 4, compare initial risk to tolerable risk: zones within tolerance skip the detailed assessment, with the rationale documented.
ZCR 5, detailed risk assessment: threats, vulnerabilities, likelihood and existing countermeasures per zone and conduit, leading to SL-T per foundational requirement.
ZCR 6, document requirements, assumptions and constraints: the cybersecurity requirements specification, including SL-T vectors and compensating measures.
ZCR 7, asset owner approval: residual risk is accepted by an accountable owner, not by the integrator.

Repeat it when a conduit is added, a supplier gains remote access or the process changes, and keep the specification under change control: integrators build against it and auditors test against it.

Maturity levels and security programmes

Security levels measure technical capability; maturity levels measure how well a process is run. 62443-4-1 and 2-4 use a four-level model derived from CMMI, summarised by the ISAGCA guide as ML1 Initial (ad hoc, often undocumented), ML2 Managed (written policies), ML3 Defined (trained staff following defined procedures) and ML4 Improving (process metrics drive effectiveness and improvement).

Product suppliers (4-1): eight practices: security management (SM), specification of security requirements (SR), secure by design (SD), secure implementation (SI), security verification and validation testing (SVV), management of security-related issues (DM), security update management (SUM) and security guidelines (SG).
Service providers (2-4): the security processes an integrator or maintenance provider offers the asset owner. Ask for the claimed maturity level per requirement, not a single badge.
Asset owners (2-1): security program elements (SPEs), each evaluated with the edition 2 maturity model.

62443-2-2 (technical report, 2025) combines SL-A with the maturity of operational policies and procedures to rate the protection an operating IACS actually provides.

Product and system certification

ISASecure, run by the ISA Security Compliance Institute, certifies against 62443 through ISO/IEC 17065 accredited certification bodies. The IECEE Industrial Cyber Security Programme also certifies to parts of the series.

Scheme	Certifies	Based on	What it tells a buyer
SDLA	A supplier's development organisation	62443-4-1	The development lifecycle, not any specific product
CSA	A component (embedded, host, network device or software application)	62443-4-2 and 4-1	Capability SL 1 to 4, via process assessment, functional security assessment and vulnerability identification testing
ICSA	IIoT components	62443-4-2	Component capability for IIoT devices
SSA	A control system product	62443-3-3	System capability (SL-C) for the certified control system
ACSSA	An automation and control system as deployed	62443-2-1, 2-4, 3-2, 3-3	Spans owner, provider, risk and system parts; confirm scope with ISASecure

When buying, check that the certificate names the exact version and firmware you will install, and read the supplier's security guidelines (practice SG) for configuring the product to reach that level. A CSA SL 2 controller deployed with default settings does not give you SL-A 2.

62443 alongside NIST SP 800-82, NIS2 and the CRA

Framework	Relationship to 62443	How to use them together
NIST SP 800-82 Rev. 3 (September 2023)	US guide to OT security with an OT overlay for SP 800-53 Rev. 5	Use 800-53 IDs for US audit reporting and 62443 for design and supplier requirements; a Rev. 4 draft is open for comment until 30 November 2026
NIST CSF 2.0	Outcome framework	Map FR1 and FR2 to PR.AA, FR5 to PR.IR-01, FR6 to DE.CM and the 3-2 assessment to ID.RA
ISO/IEC 27001:2022	Enterprise ISMS	2-1:2024 removed ISMS duplication, so run it as the OT extension of the ISMS (A.8.22 segregation of networks, A.5.15 access control)
NIS2 (Directive (EU) 2022/2555)	Article 21 risk management measures for essential and important entities	A 3-2 assessment, 2-1 programme and 2-4 supplier terms evidence Article 21 measures in OT. See the NIS2 Directive Guide
EU Cyber Resilience Act (Regulation (EU) 2024/2847)	Product law for products with digital elements; reporting from 11 September 2026, main obligations from 11 December 2027	4-1 and 4-2 overlap with CRA secure development and vulnerability handling, but presumption of conformity comes only from harmonised standards (request M/606) cited in the Official Journal

Applying 62443 at a brownfield site

Existing plants start from equipment that cannot meet SL 2 natively, so the work is staged and every step is tested against the process.

Inventory the real system: passive discovery of assets and flows, including vendor connections and dual-homed hosts, reconciled with drawings.
Run 3-2 on the highest-consequence area first: usually the SIS and the units with the worst hazard scenarios. Produce zone and conduit diagrams and SL-T vectors.
Close the conduits first: put a firewall or unidirectional gateway at each zone boundary in monitor mode, log for two to four weeks, build the allowlist from observed traffic, then enforce in a planned outage with the previous rule set saved for rollback.
Fix FR1 and FR2 next: remove default and orphaned accounts, broker all remote access through the DMZ, and split shared accounts where the HMI supports it. Test lockout and session settings on a spare HMI or in the factory acceptance test (FAT) environment first.
Add monitoring (FR6): passive monitoring at conduits, and logs from boundary devices, jump hosts and domain controllers sent to the SOC.
Document SL-A and the gaps: record which SRs are met natively, which are met by compensating measures, and which are accepted risk, with an owner and a review date.
Raise SL-C at replacement: require 4-2 capability and 4-1 processes (or CSA and SDLA certification) in every refresh and in 2-4 service contracts.

Small and large sites: a single-site manufacturer can run a handful of zones, one boundary firewall each and a service provider held to 2-4; a multi-site operator needs a reference zone model, an SL-T library per asset type and reusable supplier requirements.

Measuring progress

Coverage: share of production assets in a documented zone with an approved SL-T.
Conduit control: share of conduits with an enforcing device and a rule set reviewed in the last 12 months.
SL gap: zones where SL-A is below SL-T for any FR, and how many have an approved compensating measure.
Identity hygiene: shared, default or ownerless accounts in OT zones, and share of remote sessions brokered with MFA.
Supplier assurance: share of new components bought with 4-2 evidence and service contracts with 2-4 terms.

Common failure patterns

Treating a supplier certificate as plant compliance: SL-C on a datasheet is not SL-A in the field; the asset owner still needs zones, conduits and a 2-1 programme.
One SL for the whole site: a single "SL 2" label hides that the SIS and the vendor access conduit need more.
Zones that mirror VLANs: zones drawn from the existing network rather than consequence leave the SIS and control in one trust boundary.
Unmanaged vendor and service accounts: integrator and remote access accounts left active after commissioning.
A risk assessment done once: 3-2 completed for a project and never revisited when cloud analytics or remote support were added.
Contracts that cite "IEC 62443" without a part: integrators and suppliers cannot be held to an unspecified requirement; name the part, the edition, the SL-T and the maturity level expected.

Practitioner checklist

Identify which 62443 parts apply to you by role, and to each supplier and integrator.
Run a 62443-3-2 assessment for the highest-consequence area and get asset owner sign-off.
Publish zone and conduit diagrams with an owner, protocols and enforcing device for each conduit.
Set SL-T per foundational requirement for each zone and conduit, not one number per site.
Remove default, shared and orphaned accounts, and inventory OT service accounts against SR 1.2 and SR 1.3.
Route all remote access through a DMZ broker with MFA and session recording.
Require named 62443 parts, editions and SL or ML expectations in procurement and service contracts.