IEC 62443: IEC 62443 – Tutorial (about 60 minutes)

IEC 62443 is an international series of standards for the cybersecurity of industrial automation and control systems: the controllers, sensors, operator stations, networks and software that run factories, power grids, water plants, pipelines and buildings. It is used by the companies that own and operate those systems, by the integrators and maintenance firms that build and support them, and by the manufacturers that make the products inside them. After this tutorial you will be able to explain why industrial security needs its own standard, find your way around the parts of the series, apply zones, conduits and security levels to a real site, and judge what a claim of "IEC 62443 compliance" or "certification" actually means.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: IEC 62443 is not one document but a family of parts with different ages and document types, published by the International Electrotechnical Commission (IEC) through technical committee TC 65 and developed jointly with the ISA99 committee of the International Society of Automation (ISA), which publishes matching ANSI/ISA-62443 versions. The parts most used today are IEC 62443-2-1 Edition 2.0 (2024, asset owner security programme), IEC 62443-2-4 Edition 2.0 (2023, service providers), IEC 62443-3-2 Edition 1.0 (2020, risk assessment and system design), IEC 62443-3-3 Edition 1.0 (2013 with a 2014 corrigendum, system requirements and security levels), IEC 62443-4-1 Edition 1.0 (2018, secure product development) and IEC 62443-4-2 Edition 1.0 (2019, component requirements). Newer specifications include IEC TS 62443-1-5 (2023, security profiles), IEC TS 62443-6-1 (2024) and IEC TS 62443-6-2 (2025) on evaluation methods, IEC PAS 62443-2-2 (2025, security protection scheme) and IEC PAS 62443-1-6 (December 2025, industrial internet of things). The foundational IEC TS 62443-1-1 still dates from 2009. The IEC notes that the committee is revising parts of the series, and industry overviews report revision work on core parts such as 3-2, 3-3, 4-1 and 4-2; no new editions of those parts had been published at the verification date, so this course teaches the editions listed above. Verified 2026-10-29 against the IEC webstore entries for IEC 62443-3-3, IEC PAS 62443-2-2 and IEC PAS 62443-1-6, the published previews of IEC 62443-2-1:2024, IEC TS 62443-1-5, IEC TS 62443-6-1 and IEC TS 62443-6-2, the ISA "ISA/IEC 62443 Series of Standards" page and a 2026 status overview by the Dutch IPCS working group.

Who it is for: engineers and technicians in operational technology (OT), IT security staff who now have to protect plants, project managers and buyers of automation systems, product managers and developers at automation vendors, and auditors or compliance staff who meet IEC 62443 for the first time, for example because a customer, regulator or insurer asks for it.

Prerequisites: none. A rough idea of how an industrial plant is controlled (sensors measure, a controller decides, actuators act, operators watch screens) and of basic network ideas such as firewalls and remote access helps. Every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why industrial control systems need a security approach different from office IT, and what the IEC 62443 series sets out to achieve.
You will be able to define the core vocabulary: IACS, asset owner, service provider, product supplier, zone, conduit, security level, foundational requirement and maturity level.
You will be able to describe the four main groups of the series and say which part matters to which role.
You will be able to walk through the risk-based design process of IEC 62443-3-2, from defining the system to approving its security requirements.
You will be able to distinguish target, capability and achieved security levels and use them to compare a design with its requirements.
You will be able to explain the main certification and assessment routes for products, processes, services and sites, and spot misleading claims.
You will be able to place IEC 62443 next to ISO/IEC 27001, the NIST guidance for OT, functional safety standards and new product regulation.

Lesson 1 – Origins, purpose and scope

Why industrial systems need their own security standard

For decades, industrial control systems were protected mostly by isolation. A plant's controllers spoke proprietary protocols on their own cables, and the only way to change a setting was to walk up to a panel. That world has gone. Today the same plant probably has Ethernet networks, Windows-based operator stations, historians that feed data to the business, wireless sensors, remote access for vendors, and cloud dashboards. Each of these brings efficiency, and each opens a path for an attacker or for an accident. Incidents such as the Stuxnet worm, which damaged uranium centrifuges, the attacks on Ukrainian power distribution in 2015 and 2016, and ransomware outbreaks that forced manufacturers to stop production have shown that a cyber event in this environment can have physical consequences: damaged equipment, environmental releases, loss of essential services, and harm to people.

Office IT security practices help, but they do not transfer one to one. In a business network the usual priority is to keep information confidential; in a plant, the priority is usually to keep the process running safely and predictably. A controller may run for fifteen or twenty years, cannot be rebooted at will, and may not support modern encryption. A security scan that is harmless on a laptop can crash an old controller. Patching may require a production stop and re-testing with the vendor. Operators need to act within seconds and cannot be locked out by a password policy in the middle of an emergency. Security in this setting has to respect these realities, which is what IEC 62443 is designed to do.

Where the series came from

Work began in the early 2000s in the ISA99 committee, which brought together plant owners, automation vendors, integrators and government experts in North America and beyond. ISA's first technical reports appeared in 2004, and its first standard, on terminology, concepts and models, followed in 2007. IEC technical committee TC 65, which covers industrial-process measurement, control and automation, adopted and co-developed the work, first under the title "Industrial communication networks – Network and system security", later as "Security for industrial automation and control systems". Since then the two bodies have developed the parts together, so the ISA and IEC versions of each part are technically aligned, though publication dates can differ. The series has grown part by part, which is why some documents are recent and others are more than fifteen years old.

What it covers

The scope is the security of industrial automation and control systems across their whole life: specification, design, development, integration, operation, maintenance and retirement. It covers technical requirements (what a component or system must be able to do), process requirements (how a vendor develops products, how a service provider works, how an owner runs a security programme), and the methods for assessing both. It is sector-neutral: the same concepts apply to a chemical plant, a substation, a water utility, a car factory or the building management system of a hospital. Some sectors build on it with their own rules, for example classification societies for ships and national regulators for critical infrastructure.

The central ideas

Three ideas run through every part. First, security is a shared responsibility: no single party can secure an industrial system on its own, so the series gives distinct requirements to the product supplier, the integrator, the maintenance provider and the owner. Second, security is risk-based: the strength of protection should match the threat and the consequences, which is expressed through security levels. Third, defence in depth: the system is divided into zones and protected by several layers, so that no single failure exposes everything. Lesson 2 explains the vocabulary behind these ideas.

Lesson 2 – Key concepts and vocabulary

IEC 62443 uses a precise vocabulary. The terms below are paraphrased explanations, not the standard's own definitions, but they will let you read the parts with confidence.

Industrial automation and control system (IACS) – the people, hardware, software and policies involved in operating an industrial process, including controllers, safety systems, operator stations, engineering workstations, networks and the procedures around them. The term is wider than "a PLC network": it includes the organisation and its practices.
Asset owner – the organisation that owns and is accountable for the IACS and the process it controls, usually the operator of the plant. It decides what level of risk is tolerable.
Product supplier – the manufacturer of hardware or software products used in an IACS, such as a controller, a switch, an operator software package or an industrial firewall.
Service provider – an organisation (or an internal department) that delivers services to the owner. The series distinguishes the integration service provider, who designs, builds and commissions the automation solution, and the maintenance service provider, who supports it in operation.
Automation solution – the specific combination of products and configuration that an integrator delivers for one site. The IACS is this solution plus the owner's operating policies and procedures.
System under consideration (SUC) – the clearly defined boundary of the system being assessed, including what is inside, what is outside and where it connects.
Zone – a group of logical or physical assets that share the same security requirements and are protected as a unit. Typical examples are a control network zone, a safety system zone and a demilitarised zone (DMZ) between plant and business networks.
Conduit – a group of communication channels that connect zones and share security requirements, together with the devices that protect them, such as firewalls, data diodes or VPN gateways.
Security level (SL) – a measure, from 1 to 4, of how strong the protection is against different kinds of attackers, from accidental misuse up to well-resourced, highly skilled and motivated adversaries.
Target, capability and achieved security level (SL-T, SL-C, SL-A) – the level a zone needs according to the risk assessment, the level a component or system is able to provide when properly configured, and the level actually present in the running installation.
Foundational requirement (FR) – one of seven broad security objectives that organise all technical requirements in the series, such as identifying and authenticating users or restricting data flow.
System requirement (SR) and component requirement (CR) – the detailed technical capabilities that systems (IEC 62443-3-3) and components (IEC 62443-4-2) must offer, each linked to a foundational requirement. Requirement enhancements (REs) add strength for higher security levels.
Maturity level (ML) – a scale from 1 to 4 that describes how well a process is defined, practised and improved, used for vendor development processes, service providers and owner security programmes.
Compensating countermeasure – a measure applied when a component cannot meet a requirement itself, for example placing a legacy controller behind a gateway that adds authentication.
Essential functions – the functions that must keep working to maintain health, safety, the environment and availability, such as safety shutdowns, control loops and the operator's view. Security measures must not disable them.
Security programme – the organised set of policies, procedures, roles and technical measures an asset owner uses to manage IACS security over time.

Security levels in more detail

Security levels are the series' way of making "how secure is secure enough?" concrete. Instead of describing protection in vague terms, they describe the attacker the protection is meant to withstand. In plain language:

SL 1 protects against casual or accidental violations, for example an employee who plugs in the wrong USB stick or changes a setting by mistake.
SL 2 protects against deliberate attacks by someone using simple means, few resources, general IT skills and low motivation, such as an opportunistic intruder using common tools.
SL 3 protects against deliberate attacks by someone with sophisticated means, moderate resources, knowledge specific to industrial systems and moderate motivation, for example a capable criminal group targeting a sector.
SL 4 protects against deliberate attacks with sophisticated means, extensive resources, industrial-system expertise and high motivation, the profile usually associated with state-sponsored teams.

Two points are often missed. First, a security level is really a vector: it can be set separately for each of the seven foundational requirements, so a zone might need SL 3 for integrity but only SL 1 for confidentiality. Second, a security level describes protection against a type of attacker; it is not a grade for the whole company and not a guarantee that no attack can succeed.

The seven foundational requirements

Every technical requirement in parts 3-3 and 4-2 sits under one of seven foundational requirements. In short: FR 1 identification and authentication control (know who or what is connecting), FR 2 use control (allow each identity only what it is permitted to do), FR 3 system integrity (prevent and detect unauthorised changes to software, data and configuration), FR 4 data confidentiality (protect information from disclosure), FR 5 restricted data flow (segment networks and limit communication to what is needed), FR 6 timely response to events (log, monitor and report security events so people can act), and FR 7 resource availability (keep the system available under attack or overload, with backup and recovery). Notice how availability and integrity are given at least equal weight to confidentiality, which reflects industrial priorities.

Lesson 3 – Structure of the series

The parts are numbered in groups. The first number after "62443" tells you the group, and therefore which audience and topic the part addresses. Figure 1 shows the groups and the most-used parts.

Figure 1 – The IEC 62443 series is organised in groups by topic and audience, each holding a few key parts.

Group 1 – General

The general parts set the common foundation. IEC TS 62443-1-1 (2009) explains the terminology, concepts and models, including the reference model of an industrial site, zones and conduits, and the foundational requirements. Because it is old, some of its wording has been overtaken by later parts, and practitioners usually rely on the definitions in the newer documents. IEC TS 62443-1-5 (2023) describes a scheme for security profiles: a way for a sector to select and tailor requirements from the series for its typical systems. IEC PAS 62443-1-6 (2025) explains how the series applies to the industrial internet of things. Further general documents on a glossary, metrics and lifecycle have been planned over the years; check the current status before relying on them.

Group 2 – Policies and procedures

This group addresses organisations rather than technology. IEC 62443-2-1 sets requirements for the asset owner's security programme for an IACS in operation. Its second edition (2024) reorganised the content into eight security programme elements: organisational security measures, configuration management, network and communications security, component security, protection of data, user access control, event and incident management, and system integrity and availability. It removed material that duplicated a general information security management system and added a maturity model, so an owner can state how well each requirement is implemented. IEC PAS 62443-2-2 (2025) describes a security protection scheme, the combined technical, physical and procedural measures protecting an IACS in operation, and a rating approach that combines security levels with maturity levels. IEC TR 62443-2-3 (2015) is a technical report on patch management in industrial environments. IEC 62443-2-4 (Edition 2.0, 2023) sets requirements for the capabilities of integration and maintenance service providers, covering topics such as staffing, architecture, wireless, safety system handling, configuration management, remote access, event management, account management, malware protection, patching and backup.

Group 3 – System

This group addresses the automation solution as a whole. IEC TR 62443-3-1 (2009) is an older technical report surveying security technologies. IEC 62443-3-2 (2020) gives the process for security risk assessment and system design: defining the system under consideration, partitioning it into zones and conduits, setting target security levels and documenting the resulting cybersecurity requirements. Lesson 4 walks through this process. IEC 62443-3-3 (2013) lists the system requirements, grouped under the seven foundational requirements, with enhancements for each higher security level. It is the main technical yardstick for integrators and for system-level products.

Group 4 – Component

This group addresses product suppliers. IEC 62443-4-1 (2018) defines the secure product development lifecycle through eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines (the documentation that tells users how to install and operate the product securely). IEC 62443-4-2 (2019) lists the technical security capabilities of components, mirroring 3-3 at component level. It distinguishes four component types: software applications, embedded devices, host devices and network devices, with general requirements for all and specific ones for each type.

Profiles and group 6 – Evaluation

IEC TS 62443-1-5 anticipates a dedicated sub-series of security profiles, but no such profile had been published when this course was checked. Group 6 supports conformity assessment: IEC TS 62443-6-1 (2024) gives an evaluation methodology for service providers against 2-4, and IEC TS 62443-6-2 (2025) gives one for components against 4-2, aiming for repeatable results whichever evaluator does the work. These methods are not certification schemes themselves; schemes use them.

Document types matter

The letters in each designation tell you how binding a document is. A plain "IEC 62443-x-y" is an International Standard with requirements you can claim conformance to. A technical specification (TS) is normative but less settled, a technical report (TR) is informative guidance, and a publicly available specification (PAS) is published quickly to meet an urgent need and is reviewed after a few years. When someone says "we follow IEC 62443", always ask: which parts, which editions, in which role?

Lesson 4 – How it works in practice

Roles and how the parts fit together

The easiest way to understand the series is to follow the chain of responsibility from product to plant. A product supplier develops components under a secure development process (4-1) and gives them security capabilities (4-2). An integration service provider combines those products into an automation solution for a site, following its own secure practices (2-4), and designs it to meet the system requirements (3-3) needed for each zone, based on a risk assessment (3-2). The asset owner operates the result inside a security programme (2-1), often supported by a maintenance service provider (2-4). Figure 2 shows this chain.

Figure 2 – Each role contributes a different layer of security, and each layer is covered by its own parts of the series.

The value of this split is that each party can be held to requirements it can actually control. A vendor cannot decide how an owner segments its network, and an owner cannot fix a hard-coded password in a vendor's firmware. By writing requirements per role, the series lets buyers ask suppliers for specific evidence and lets everybody see where gaps fall.

Zones and conduits

The zone and conduit model is the practical heart of IEC 62443. Instead of trying to protect every device equally, the designer groups assets into zones of similar criticality and trust, then controls every communication path between zones through conduits. A device inside a zone trusts its neighbours more than devices outside; traffic between zones must pass through a conduit where it can be filtered, authenticated, encrypted or logged. Figure 3 shows a typical arrangement for a process plant.

Figure 3 – Zones group assets of similar criticality, and every path between zones passes through a conduit that applies controls.

Some rules of thumb follow from the model. Never allow direct traffic from the business network to controllers: put a DMZ in between so that no connection crosses from enterprise to control in one step. Keep safety systems in their own zone, with the most restrictive conduit. Treat remote access as a conduit in its own right, with strong authentication, approval and logging. Wireless networks, cloud connections and portable media are paths too, and must be treated as conduits or controlled by procedures.

The risk assessment and design process of 3-2

IEC 62443-3-2 turns the zone idea into a repeatable process. It defines a sequence of zone and conduit requirements (ZCRs) that move from a rough picture of the system to an approved set of security requirements. Figure 4 shows the flow.

Figure 4 – The IEC 62443-3-2 process moves from defining the system to approved cybersecurity requirements, and repeats when things change.

In ZCR 1 the team draws the boundary of the system under consideration and lists its assets, connections and owners. In ZCR 2 it performs an initial, high-level risk assessment, looking at the worst realistic consequences if the system were compromised, before any specific security measures are credited. This tells the team how much is at stake. In ZCR 3 the system is divided into zones and conduits, keeping safety-related assets apart from others, separating wireless and externally connected assets, and grouping by function and criticality. In ZCR 4 the initial risk is compared with the owner's tolerable risk. Where it is higher, ZCR 5 requires a detailed risk assessment of that zone or conduit: identifying threats and vulnerabilities, estimating likelihood and consequence, setting a target security level, and selecting countermeasures until the residual risk is tolerable. ZCR 6 records the outcome in a cybersecurity requirements specification: the zones, conduits, target security levels, required countermeasures, assumptions, constraints and the environment the design relies on. In ZCR 7 the asset owner reviews and formally approves the result, accepting the residual risk. The process is repeated when the system changes, when new threats appear, or at planned intervals.

From target to capability to achieved

Once each zone has a target security level, the designer must show that the chosen system and components can deliver it, and later that the installation really does. Figure 5 shows how the three kinds of security level fit together.

Figure 5 – The target level comes from risk, the capability level from the design, and the achieved level from the real, configured installation.

A component with SL-C 3 for a foundational requirement can only provide that protection if it is configured as its security guidelines describe; a default password left in place lowers the achieved level immediately. Equally, an achieved level can be higher than the capability of individual parts when compensating countermeasures are applied, such as a conduit device that adds authentication in front of an old controller. The aim is that, for each zone and each foundational requirement, the achieved level meets the target.

Running the programme

Design is only the start. The asset owner's security programme under 2-1 keeps the system secure over its life. Typical activities include maintaining an asset inventory and configuration baseline, controlling changes, hardening components, managing portable media and malware protection, testing and installing patches or applying mitigations when patching is not possible, managing user accounts and access rights, controlling remote access, monitoring and responding to security events, backing up and restoring, and reviewing the programme periodically. Service providers that touch the system should meet 2-4 requirements, and the owner should write those expectations into contracts. Training matters throughout, because many industrial incidents begin with people: a technician's laptop, a phishing email to an engineer, or a shared password.

Maturity levels

The process-oriented parts (2-1, 2-4 and 4-1) use maturity levels to describe how well a requirement is implemented. In outline: at ML 1 the work is done in an ad hoc, often undocumented way; at ML 2 it is managed, with written procedures, trained people and repeatable results; at ML 3 it is defined across the organisation and there is evidence that it has actually been practised; at ML 4 the organisation measures the process and improves it continuously. Process certificates usually state the maturity level that was demonstrated, and an owner can use maturity levels to plan improvement step by step rather than trying to do everything at once.

Lesson 5 – Assessment, certification and compliance

What can be certified

Because IEC 62443 addresses different roles, there is no single "62443 certificate". Instead there are certifications for specific parts and roles, granted by independent certification bodies after an assessment. The most common objects are:

Development processes of product suppliers against 4-1, usually with a maturity level stated.
Components against 4-2 (in some schemes together with the 4-1 process that produced them), stating the capability security level achieved per foundational requirement.
Systems, meaning a vendor's system product or reference architecture, against 3-3, again with capability security levels.
Service providers against 2-4, stating which capabilities they offer and at which maturity.
Asset owner programmes against 2-1, a newer and less common area that the second edition and 2-2 aim to support.

Who certifies

Two well-known frameworks exist. ISASecure, operated by the ISA Security Compliance Institute, offers schemes for development lifecycles (SDLA, based on 4-1), components (CSA, based on 4-1 and 4-2), systems (SSA, based on 3-3 and 4-1) and industrial internet of things components (ICSA). Its certificates are issued by accredited certification bodies. The IECEE, the IEC system for conformity assessment of electrical equipment, runs a programme for industrial cybersecurity in which accredited bodies issue IECEE certificates for several 62443 parts. Many national testing and certification organisations offer assessments under these frameworks or under their own accredited schemes. Evaluation methods in 6-1 and 6-2 help different evaluators reach the same conclusions. For people rather than organisations, ISA runs a certificate programme in which individuals take courses and exams on the series; this shows personal knowledge and is not an organisational certification.

What an assessment looks like

A component assessment typically combines a review of the vendor's development process (documented procedures and evidence they were followed, such as threat models, code reviews, test reports and vulnerability handling records) with technical testing of the product: checking each claimed capability, running robustness and vulnerability tests, and reviewing the security guidelines given to users. A service provider assessment looks at policies, procedures, staff qualifications and evidence from real projects. An assessment of an operating site compares the security programme and the installed system with the cybersecurity requirements specification and the relevant parts, and is often done as a gap assessment before any formal certification.

Reading claims critically

Claims about IEC 62443 are easy to make and easy to misread. A product brochure that says "designed according to IEC 62443" means little without a certificate or an evaluation report naming the part, edition, security levels and the certification body. A component certificate says that the product can deliver certain capabilities when configured as instructed; it does not make the plant secure. A vendor's development process certificate says nothing about a particular product version unless the product itself is covered. And a statement that a site "is 62443 certified" needs unpacking: which part, which scope, and by whom? Ask for the certificate, check its scope and validity, and read the conditions of use.

Compliance and regulation

IEC 62443 is voluntary in itself, but it is widely used to demonstrate "state of the art" security where laws or contracts demand it. Regulators of critical infrastructure in many countries refer to it in guidance, insurers and large buyers ask for it in tenders, and sector rules build on it; for example, classification societies' unified requirements for ship cyber resilience draw on its concepts. In the European Union, the Cyber Resilience Act sets security requirements for products with digital elements, and the standards being prepared to support it draw on existing work including the 62443 series. Always check the specific legal text and its harmonised standards rather than assuming that a 62443 certificate automatically satisfies a law.

Lesson 6 – Worked example: a water utility secures its treatment plant

Riverbend Water (a fictional utility) supplies drinking water to a city of 400,000 people. Its main treatment plant has a SCADA system installed fifteen years ago, a chlorine dosing system with an automatic gas leak shutdown, and twelve remote pumping stations connected over a cellular network. The business network shares a firewall with the plant network, a vendor connects remotely through a permanently open VPN, and several engineers use the same administrator account. After a neighbouring utility suffered ransomware that spread into its control room, Riverbend's board asked for a programme based on IEC 62443. Here is how the team applied the series step by step.

Step 1 – Set up the security programme (2-1)

The head of operations was made accountable, with a small OT security team that includes an operations engineer, an IT security specialist and a representative of the control room. Using the eight security programme elements of 2-1 as a structure, they recorded the current state of each requirement and set realistic maturity targets: ML 2 everywhere within eighteen months, and ML 3 for network security and user access control, which they judged most urgent. They linked the programme to the company's existing information security management system so policies were not written twice.

Step 2 – Define the system under consideration (ZCR 1)

The team drew a boundary around the treatment plant control system, the chlorine safety system, the pumping stations and the communication links between them. The business network, billing system and email were outside the boundary but recorded as connected. An inventory found 140 devices, including two forgotten laptops in a cabinet and an unused modem still connected to a controller.

Step 3 – Initial risk assessment (ZCR 2)

Assuming no security measures, the team asked what the worst realistic consequences of a compromise would be. Loss of treatment control could interrupt supply to the city; tampering with chemical dosing could make water unsafe; a defeated gas leak shutdown could endanger workers and neighbours. These consequences were well above the utility's tolerable risk, set by the board with reference to public health and service obligations.

Step 4 – Zones and conduits (ZCR 3)

The team designed six zones: enterprise, a new plant DMZ, supervisory (SCADA servers and operator stations), plant control (controllers and I/O), chlorine safety, and remote stations. Conduits were defined between each pair that needed to talk: a firewall pair between enterprise and DMZ, a filtered link between DMZ and supervisory, controlled switch rules down to the controllers, a tightly restricted link to the safety system, an encrypted cellular link with mutual authentication to the pumping stations, and a new remote access conduit that terminates in the DMZ, requires multi-factor authentication and is only opened on request for a fixed time.

Step 5 – Detailed risk assessment and target levels (ZCR 4 and 5)

Because the initial risk was above tolerable for every zone except enterprise, each was assessed in detail. Threats considered included ransomware arriving from the business network, a compromised vendor laptop, theft of credentials, an attacker on the cellular network, and a malicious insider. The team set target security levels per foundational requirement. For example, the chlorine safety zone received SL-T 3 for integrity, use control and restricted data flow, but SL-T 1 for confidentiality, because the safety logic contains nothing secret; the control and supervisory zones received SL-T 2 across most requirements; the remote stations zone received SL-T 2 with extra attention to authentication over the public network.

Step 6 – Document and approve the requirements (ZCR 6 and 7)

The results went into a cybersecurity requirements specification describing each zone, its assets, its target level vector, the conduits and their rules, assumptions (such as physical security of the stations) and constraints (such as legacy controllers that cannot be patched). The operations director signed it, formally accepting the residual risk and the plan.

Step 7 – Procurement and design (4-1, 4-2, 3-3, 2-4)

For the SCADA upgrade, Riverbend's tender asked bidders for evidence of 4-1 process certification and 4-2 component certificates stating capability levels, and asked integrators to demonstrate 2-4 capabilities for remote access, account management, patch management and backup. The winning integrator mapped the design to the system requirements of 3-3 and showed, zone by zone, where the capability met the target. One gap remained: the old pumping station controllers cannot authenticate users at all. Replacing them all at once was too expensive, so the design added a compensating countermeasure: each station got a small security gateway that authenticates connections, allows only the required protocols and logs access, with replacement of the controllers scheduled over three years.

Step 8 – Commissioning and operation (2-1, 2-3, 2-4)

Before go-live, an independent team tested the installation against the requirements specification and found that two switches still had default credentials, which lowered the achieved level in the control zone until fixed. In operation, the maintenance contract required the vendor to follow 2-4 practices, including named personal accounts instead of the shared administrator account. A patch process based on the 2-3 guidance had the vendor qualify patches on a test system, after which Riverbend installed them during planned maintenance windows or applied documented mitigations. Security events from firewalls, gateways and servers were sent to a monitoring service with a response plan that the operators rehearse twice a year.

Step 9 – Review and improve

A year later, the team reassessed maturity: most elements had reached ML 2, and network security had reached ML 3. A new connection request, a cloud dashboard for water quality data, triggered the 3-2 process again for the affected zones, leading to a one-way data transfer from the DMZ rather than a connection into the plant. The example shows the series working as intended: a programme with clear ownership, a risk-based design, products and services held to their own requirements, and a cycle of review.

Lesson 7 – Relationship to other standards and frameworks

IEC 62443 seldom stands alone. Organisations often run it alongside an information security management system, national guidance and safety standards. The table compares common neighbours.

Standard or framework	Main focus	Relationship to IEC 62443
ISO/IEC 27001	Information security management system for any organisation, certifiable	Provides the management system; 62443-2-1 expects an ISMS and adds IACS-specific programme requirements, and 3-3/4-2 add technical depth for control systems.
NIST SP 800-82 Rev. 3	US guidance on securing operational technology	Free guidance that explains OT risks and controls and refers to 62443 concepts such as zones and conduits; not a certifiable standard.
NIST Cybersecurity Framework 2.0	High-level outcomes for managing cybersecurity risk	Useful for board-level reporting; 62443 parts can serve as detailed references for meeting its outcomes in OT.
IEC 61508 and IEC 61511	Functional safety of electrical/electronic safety systems and of process-sector safety systems	Safety standards ask for security threats to be considered; 62443 provides the methods. IEC TR 63069 discusses how to combine safety and security work.
ISO/SAE 21434	Cybersecurity engineering for road vehicles	Similar lifecycle thinking for a different sector; automotive factories may use 62443 for production systems while vehicles follow 21434.
EU Cyber Resilience Act	Legal security requirements for products with digital elements sold in the EU	A law, not a standard; 62443-4-1 and 4-2 practices overlap strongly with its product and vulnerability handling obligations, but compliance must be shown against the law and its harmonised standards.

IEC 62443 and ISO/IEC 27001 together

A frequent question is whether a company already certified to ISO/IEC 27001 needs IEC 62443. The two complement each other. ISO/IEC 27001 gives the management framework: leadership, risk assessment, policies, internal audit and continual improvement across the organisation. It does not tell you how to segment a control network, what security capabilities a controller should have, or how to patch a system that cannot be stopped. IEC 62443 provides that industrial detail and the role-based requirements for suppliers and service providers. Many owners run one ISMS that covers both IT and OT, and use 62443 parts to define what "good" looks like inside the plant.

Security and safety

Safety engineers ask what happens when equipment fails at random or because of design mistakes; security engineers ask what happens when someone tries to make it fail. In industrial plants these questions meet: a compromised safety system is both a security and a safety problem. Process-sector safety standards expect a security risk assessment of safety systems, and the zone model gives a natural place to isolate them. The two disciplines should share hazard information and agree that security measures will not interfere with safety functions, for example that an account lockout cannot stop an operator from triggering a shutdown.

Common pitfalls and best practices

Pitfalls

Treating the series as one checklist. Teams buy "the standard" and try to apply every part to themselves, when most parts are written for other roles. Start by identifying your role and the parts that apply to it.
Confusing product certificates with a secure site. Buying certified components is useful, but a plant built from them can still be insecure if it is badly segmented, poorly configured or run without a security programme.
Quoting a single security level for everything. Saying "our plant is SL 2" hides the per-zone, per-requirement nature of security levels and the difference between target, capability and achieved levels.
Flat networks with a single firewall. Without a DMZ and internal zones, one compromised laptop can reach every controller.
Copying IT practices blindly. Aggressive scanning, automatic patching or strict lockout policies can disrupt production or block an operator in an emergency.
Cherry-picking requirements. Claiming conformance while quietly leaving out inconvenient requirements undermines the meaning of any claim; record exclusions and their justification.
Forgetting the people around the system. Shared accounts, uncontrolled vendor access and untrained staff defeat technical measures.
Treating the assessment as a one-off project. Systems, threats and staff change; a risk assessment that is never revisited becomes fiction.

Best practices

Start with an inventory and a boundary. You cannot protect assets you do not know about; a good system-under-consideration description pays off throughout.
Use zones and conduits as the backbone of the design. Group by criticality and function, isolate safety systems and control every path, including remote access, wireless and removable media.
Set target levels from risk and document them as vectors. Make the cybersecurity requirements specification the single reference for design, procurement and testing.
Write 62443 requirements into contracts. Ask suppliers for 4-1 and 4-2 evidence, integrators and maintainers for 2-4 capabilities, and define who patches, who monitors and who may connect.
Verify the achieved level on site. Test configurations, credentials and firewall rules after commissioning and after major changes, not only the design documents.
Plan for legacy systems. Use compensating countermeasures and a replacement roadmap rather than ignoring devices that cannot meet requirements.
Build maturity step by step. Use maturity levels to set achievable targets and show progress to management.
Involve operations and safety engineers. Security that operators understand and that respects essential functions is security that stays in place.

Summary and key takeaways

IEC 62443 is a series of standards, technical specifications and reports for the security of industrial automation and control systems, developed jointly by IEC TC 65 and ISA99.
It divides responsibility among product suppliers (4-1, 4-2), integration and maintenance service providers (2-4, 3-3) and asset owners (2-1, 3-2), so each party is held to what it can control.
Zones and conduits are the core design tool: group assets of similar criticality and control every communication path between groups.
Security levels 1 to 4 describe the attacker a measure is meant to withstand, are set per foundational requirement, and come in target, capability and achieved forms.
The seven foundational requirements organise all technical requirements and give availability and integrity full weight alongside confidentiality.
Maturity levels 1 to 4 describe how well processes are defined, practised and improved for suppliers, service providers and owners.
Certification applies to specific parts and objects, such as a development process, a component, a system or a service provider; no certificate makes a whole plant secure by itself.
The parts have different editions and ages; several core parts are under revision, so always check which parts and editions a claim refers to.

Reflection questions

Think of an industrial or building system you know. Which organisations play the roles of asset owner, integrator, maintenance provider and product supplier, and which parts of the series would apply to each?
Sketch the zones and conduits of that system. Where are the paths that an attacker could use but that nobody currently controls?
For one zone, which foundational requirements would you give a higher target level than the others, and why?
A vendor offers a product "designed to IEC 62443". What questions would you ask, and what evidence would you expect before accepting the claim?
Your organisation has an ISO/IEC 27001 certificate. What would you add, and what would you reuse, to bring the plant floor up to the expectations of IEC 62443-2-1?