Ask an OT security practitioner which standard governs industrial cybersecurity and the answer is usually “IEC 62443.” Ask them to explain what any specific part of it requires and the room gets quieter. The standard is large, structured in a way that assumes familiarity with its own terminology, and splits responsibilities across multiple series in a way that confuses procurement teams, asset owners, and even experienced security professionals.
This article is a practical explainer: what IEC 62443 is, how its parts map to different stakeholders, what the Security Level model means in practice, and how to reference it in vendor contracts without creating compliance theatre.
What IEC 62443 Covers
IEC 62443 is a series of standards for Industrial Automation and Control Systems (IACS) cybersecurity, developed jointly by the International Electrotechnical Commission and the International Society of Automation (ISA). It covers the full lifecycle of an OT/ICS environment: design, implementation, operation, and decommissioning — and addresses three distinct audiences:
- Asset owners: organisations that operate IACS environments
- System integrators: organisations that design, build, and integrate IACS systems
- Product suppliers: manufacturers of components and products used in IACS environments
The standard applies across all industrial sectors: energy, water, manufacturing, chemical, oil and gas, transport, and any other environment running automated industrial processes.
The Series Structure
IEC 62443 is organised into four parts, each with multiple documents:
| Series | Audience | Focus |
|---|---|---|
| 2 — Policies and Procedures | Asset owners and operators | Security management system, supplier requirements |
| 3 — System Level | System integrators and asset owners | Risk assessment methodology, system security requirements |
| 4 — Component Level | Product suppliers | Secure development lifecycle, component security requirements |
The most practically important documents are:
IEC 62443-2-1 (Security management): Defines what an IACS security management system looks like. The OT equivalent of ISO 27001, covering policies, roles, risk assessment processes, and ongoing security governance.
IEC 62443-2-4 (Service provider requirements): Specifies security requirements for system integrators and service providers who install, maintain, or operate IACS environments. Relevant when hiring contractors with OT network access.
IEC 62443-3-2 (Security risk assessment): Defines the process for conducting security risk assessments, segmenting the environment into zones and conduits, and assigning Security Levels.
IEC 62443-3-3 (System security requirements): Defines the security requirements that an IACS system must meet to achieve each Security Level. The most commonly referenced document in procurement specifications.
IEC 62443-4-1 (Secure development lifecycle): Specifies requirements for the process used to develop secure products. If you’re buying software or firmware-embedded components, this is what you require the vendor to comply with.
IEC 62443-4-2 (Component security requirements): Specifies security requirements for individual IACS components — PLCs, DCS controllers, HMIs, network devices. This is what gets tested in product certification.
Security Levels Explained
Security Levels (SLs) are the 62443 framework’s way of expressing the threat you’re designing against and the protection you need. There are four levels:
SL 1 — Protection against casual or unintentional violations. Adequate where the threat is primarily errors, basic opportunistic attacks, and unintentional damage. Most operators should exceed SL 1 for any production system.
SL 2 — Protection against intentional violations using simple means. This is the baseline for most operational environments. The attacker has motivation, resources, and IACS-specific skills at a basic level. Typical adversary profile: a cybercriminal group using commodity tooling with some OT capability.
SL 3 — Protection against intentional violations using sophisticated means. The attacker has significant resources, advanced skills, and IACS-specific knowledge. Appropriate for critical national infrastructure, primary production processes with safety implications, and high-value targets subject to state actor interest.
SL 4 — Protection against state-sponsored attacks with unlimited resources. The highest level; applicable to the most sensitive national security environments. In practice, most commercial operators do not need to achieve SL 4 and should not use it as a procurement target without a specific threat justification.
The Security Level concept works in three forms: the Target Security Level (what you want to achieve), the Achieved Security Level (what your system actually achieves after implementation), and the Capability Security Level (what a product or system is capable of). Procurement requirements should specify Target SL; certification documents from vendors describe Capability SL.
Zones and Conduits
The 62443-3-2 risk assessment methodology requires dividing the IACS environment into security zones: logical or physical groupings of assets with common security requirements. Every zone gets a target Security Level.
Conduits are the communication channels between zones — every connection between zones must be defined and controlled. The conduit definition forces you to answer: what data flows between these zones, in which direction, using which protocol, and is that communication necessary?
A simple zone model for a manufacturing environment:
Enterprise Zone (SL 1)
│
Conduit: DMZ with data diode / unidirectional gateway
│
Control Zone (SL 2)
├── Engineering workstations
├── HMI servers
└── Historian
│
Conduit: Firewall with application-layer inspection
│
Safety Instrumented System Zone (SL 3)
└── Safety controllers (physically isolated where possible)The zone/conduit model makes OT network architecture decisions auditable — if a conduit exists that wasn’t modelled, it’s a deviation from design. If a conduit allows protocols not required for the defined data flow, it’s a finding. This is why the model is increasingly referenced in NCSC and CISA guidance as a baseline architecture approach.
Using 62443 in Procurement
Referencing 62443 in vendor contracts falls into two approaches, and most organisations get this wrong by using the less useful one.
Weaker (avoid): “The system shall comply with IEC 62443.” This is nearly meaningless — 62443 is a framework, not a checklist. Which parts? At which Security Level? How will compliance be demonstrated?
Stronger: Specify the relevant parts and the Security Level target:
-
“Software components shall be developed in accordance with IEC 62443-4-1 (secure development lifecycle). Evidence of compliance shall include either third-party certification or a documented secure development process audit within the last 24 months.”
-
“Industrial network devices supplied under this contract shall meet the requirements of IEC 62443-4-2 at Security Level 2 (Capability) or above. Certification by an accredited laboratory (TÜV SÜD, Exida, DEKRA, or equivalent) is required.”
-
“The system integrator shall implement the project in accordance with IEC 62443-2-4. A security plan conforming to 2-4 requirements shall be submitted for review prior to project commencement.”
When vendors have IEC 62443 certification, ask specifically: which part, which Security Level, which scope (the whole product or specific functions), and from which certification body. Certification of a small subset of functionality at SL 2 from a product that you’re deploying in an SL 3 zone is not the same as full product certification at SL 3.
Certification Bodies
The main accredited certification bodies for IEC 62443-4-1 and 4-2 product certifications are:
- TÜV SÜD (Germany/international): widely used for process industry components
- Exida (US): specialist in functional safety and IACS security
- DEKRA (Germany/international): growing OT certification practice
- UL Solutions (US): strong in North American markets
Not all vendors claiming “62443 compliance” have third-party certification. Self-assessed compliance claims require you to conduct or commission your own audit to verify — budgeted and planned.
The Practical Starting Point
If your organisation operates OT/ICS environments and you haven’t applied 62443, the useful entry point is IEC 62443-3-2: conduct a zone-and-conduit analysis of your current environment, assign target Security Levels to each zone, and use the gap between current state and target as your OT security roadmap. This exercise typically surfaces more actionable improvement items than any other single assessment, and it gives you the documented risk justification needed to prioritise investment.
The procurement requirements flow naturally from the zone analysis: if a zone needs SL 2, procure SL 2-capable components and require SL 2-compliant development practices from your vendors.
IEC 62443 is not a compliance exercise to be completed once. It’s the framework against which you measure your OT environment continuously — as the threat evolves, as technology changes, and as the regulatory landscape around critical infrastructure security tightens.