IEC 62443 (ISA-99), industrial control cybersecurity
Guide, IEC 62443
IEC 62443 is the international reference for cybersecurity of Industrial Automation and Control Systems (IACS). Born in 2002 as ISA-99 inside the International Society of Automation (ISA), the series was transferred from 2007 onward to a joint ISA/IEC track under IEC TC 65 / WG 10 and is now published as the multi-part IEC 62443 family. The series addresses asset owners, system integrators and component manufacturers, around a common conceptual chassis: zones and conduits, Security Levels (SL 0 to 4) and seven Foundational Requirements. This guide walks through the structure of the series, the key parts in detail, the SL and FR model, the role of 62443-4-1 for component developers, the certification ecosystem (ISASecure, TUV Rheinland, TUV SUD, DEKRA), the regulatory hooks (NIS 2, CRA, NERC CIP, NIST SP 800-82r3) and the recurring pitfalls.
From ISA-99 to IEC 62443
Section titled “From ISA-99 to IEC 62443”ISA-99 was launched in 2002 by the ISA, as the first dedicated industrial cybersecurity standard at a time when IT security frameworks (ISO/IEC 17799, later ISO/IEC 27001) were not addressing the specifics of process control. The early ISA-99 documents introduced the concept of zones and conduits and the notion that availability and safety in OT environments often outrank confidentiality.
From 2007 onward, the series was transferred to a joint ISA/IEC track. IEC Technical Committee 65 (Industrial-process measurement, control and automation) and its Working Group 10 took over development, while ISA kept co-authorship. Numbering moved to IEC 62443-x-y, and the series became multi-part by design, with each part addressing a defined audience and scope.
Today, the ISA-99 label is mainly historical. Active parts are published under the IEC 62443 designation and form a coherent body of work, even though individual parts are at different revision stages (some parts are still under revision, some have been recently updated, some are stable).
Structure of the IEC 62443 series
Section titled “Structure of the IEC 62443 series”The series is organised in four groups, by audience and scope.
| Group | Audience | Scope |
|---|---|---|
| 62443-1-x | All actors | General concepts, terminology, lifecycle, master glossary |
| 62443-2-x | Asset owner, service provider | Policies, procedures, security programme |
| 62443-3-x | System integrator | System-level requirements, zones and conduits, system Security Level |
| 62443-4-x | Component manufacturer | Component-level requirements, SDL, technical component requirements |
This split is deliberate: an asset owner operating a refinery, a system integrator delivering a control architecture and a component vendor selling a PLC do not consume the same requirements. Each actor reads the relevant 62443 part and points to the others through contractual obligations.
Key parts in detail
Section titled “Key parts in detail”The following parts form the practical backbone of any 62443 programme.
| Part | Title (abridged) | Edition | Audience |
|---|---|---|---|
| 62443-1-1 | Terminology, concepts and models | 2009 (revision in DIS, expected 2025) | All |
| 62443-2-1 | Security programme requirements for IACS asset owners | 2024 (replaces 2010 edition) | Asset owner |
| 62443-2-4 | Security programme requirements for IACS service providers | 2015 + A1:2017 | Service provider, integrator |
| 62443-3-2 | Security risk assessment for system design | 2020 | System integrator, asset owner |
| 62443-3-3 | System security requirements and security levels | 2013 | System integrator |
| 62443-4-1 | Secure product development lifecycle requirements | 2018 | Component manufacturer |
| 62443-4-2 | Technical security requirements for IACS components | 2019 | Component manufacturer |
The combination 62443-3-2 + 62443-3-3 + 62443-4-1 + 62443-4-2 is what most certification programmes evaluate against, in practice.
Security Levels (SL 0 to 4)
Section titled “Security Levels (SL 0 to 4)”The Security Level scale models the strength of the threat the system or component is expected to withstand. It applies per Foundational Requirement (see next section).
| Level | Threat model |
|---|---|
| SL 0 | No specific protection required against intentional violation |
| SL 1 | Protection against casual or coincidental violation |
| SL 2 | Protection against intentional violation by simple means, limited resources, generic skills, low motivation |
| SL 3 | Protection against intentional violation by sophisticated means, moderate resources, IACS-specific skills, moderate motivation |
| SL 4 | Protection against intentional violation by sophisticated means, extended resources, IACS-specific skills, high motivation (typically state-sponsored) |
Each SL is declined in three flavours:
- SL-T (Target): the level required by design, set during the 62443-3-2 risk assessment per zone and per FR.
- SL-C (Capability): the level a system or component is capable of supporting in a properly configured deployment.
- SL-A (Achieved): the level actually achieved in the deployed environment, accounting for configuration, compensating controls and operational practice.
A common error in commercial communication is to advertise an SL-C as if it were an SL-A. The two are not equivalent: SL-C is a property of the product, SL-A is a property of the deployed system.
Foundational Requirements (FR 1 to FR 7)
Section titled “Foundational Requirements (FR 1 to FR 7)”The seven Foundational Requirements structure all technical security requirements across the system and component standards.
| FR | Name | Concern |
|---|---|---|
| FR 1 | Identification and Authentication Control (IAC) | Who or what is acting on the system |
| FR 2 | Use Control (UC) | What that actor is allowed to do |
| FR 3 | System Integrity (SI) | Integrity of code, data and process |
| FR 4 | Data Confidentiality (DC) | Protection of data in transit and at rest |
| FR 5 | Restricted Data Flow (RDF) | Segmentation, conduit control |
| FR 6 | Timely Response to Events (TRE) | Logging, monitoring, alerting |
| FR 7 | Resource Availability (RA) | Resilience against denial of service, degraded modes |
62443-3-3 (system) and 62443-4-2 (component) both organise their detailed requirements under these seven FRs, which makes the two standards consistent and traceable. A component claiming SL-C 2 on FR 1 means it implements the technical requirements listed under FR 1 in 62443-4-2 at level SL 2.
Zones and conduits model (62443-3-2)
Section titled “Zones and conduits model (62443-3-2)”The zone and conduit model is the cornerstone of 62443 system thinking. Its principle is direct.
- Zone: a group of assets that share the same security requirements (for example, the safety instrumented system zone, the basic process control zone, the engineering workstation zone).
- Conduit: a communication channel between zones, with controlled and documented flows (for example, the conduit between the engineering zone and the control zone for downloads).
- Risk assessment: per zone and per FR, with a documented SL-T.
- Residual risk: explicitly accepted by the asset owner, with compensating controls described.
The Purdue Enterprise Reference Architecture (Purdue model, ISA-95) is the historical network segmentation reference that anchors the zone/conduit logic in most plants: level 0 (physical process), level 1 (basic control), level 2 (supervisory), level 3 (manufacturing operations), levels 4 and 5 (enterprise IT). 62443 does not mandate Purdue, but most credible zone definitions in process and discrete manufacturing settings map back to it.
Secure Product Development Lifecycle, 62443-4-1
Section titled “Secure Product Development Lifecycle, 62443-4-1”For a component manufacturer (PLC vendor, drive vendor, RTU vendor, edge gateway vendor), 62443-4-1 is the entry door. It defines a Secure Product Development Lifecycle (SDL) organised in eight practice areas.
| Code | Practice | Concern |
|---|---|---|
| SM | Security Management | Governance, roles, training, supplier control |
| SR | Specification of Security Requirements | Threat model, security objectives, security requirements specification |
| SD | Secure by Design | Architecture, defence in depth, attack surface reduction |
| SI | Secure Implementation | Coding standards, secure libraries, peer review |
| SVV | Security Verification and Validation Testing | Static analysis, dynamic analysis, fuzzing, penetration testing |
| DM | Defect Management | Vulnerability tracking, root cause analysis, patch cycle |
| SUM | Security Update Management | Patch delivery, customer notification, end-of-support policy |
| SG | Security Guidelines | Hardening guides, secure configuration documentation for the user |
Each practice is broken into specific requirements with mandatory evidence: process records, design documents, test reports, defect database. A 62443-4-1 audit consumes this evidence early; missing SUM or DM is a frequent reason for non-conformity in first audits.
Technical component requirements, 62443-4-2
Section titled “Technical component requirements, 62443-4-2”62443-4-2 maps the seven Foundational Requirements onto four component types, each with specific Component Requirements (CR), Requirement Enhancements (RE) and per-SL profiles.
| Type | Examples |
|---|---|
| Software Application (SA) | SCADA package, HMI software, historian server |
| Embedded Device (ED) | PLC, safety controller, drive, smart sensor, RTU |
| Host Device (HD) | Engineering workstation, application server, industrial PC |
| Network Device (ND) | Industrial firewall, managed switch, gateway, secure router |
For each type, 62443-4-2 lists which requirements apply at each SL and which requirement enhancements lift the level. A vendor declaring SL-C 3 on FR 1 for an Embedded Device must show that all applicable CRs and REs from FR 1 are implemented up to that level. This is the body of evidence that ISASecure CSA evaluates.
Certification programmes
Section titled “Certification programmes”Several conformity assessment programmes evaluate against the 62443 parts.
| Programme | Operator | Scope |
|---|---|---|
| ISASecure CSA (Component Security Assurance) | ISCI, ISA Security Compliance Institute | 62443-4-1 + 62443-4-2, per component type |
| ISASecure SSA (System Security Assurance) | ISCI | 62443-3-3 system-level, with 62443-3-2 risk assessment |
| ISASecure SDLA (Security Development Lifecycle Assurance) | ISCI | 62443-4-1 SDL process audit |
| ISASecure ACSSA (Automation Control System Security Assurance) | ISCI | Site-level, asset owner programme audit, ties into 62443-2-1 |
| TUV Rheinland 62443 | TUV Rheinland | 62443-4-1, 62443-4-2, 62443-3-3 |
| TUV SUD 62443 | TUV SUD | 62443-4-1, 62443-4-2, 62443-3-3 |
| DEKRA 62443 | DEKRA | 62443-4-1, 62443-4-2 |
| Bureau Veritas 62443 | Bureau Veritas | 62443-4-1, 62443-4-2 |
ISASecure is the historical programme, run by the standard owner ecosystem (ISA / ISCI). The European notified bodies and third party labs (TUV Rheinland, TUV SUD, DEKRA, Bureau Veritas) have built parallel 62443 certification offers, often in conjunction with CE-RED, EN 18031 or CRA preparation. The choice is typically driven by the destination market and existing supplier relationships.
Regulatory hooks
Section titled “Regulatory hooks”IEC 62443 is not directly mandated by name in most regulations, but it is the de facto reference for the IACS scope across several regulatory frameworks.
EU, NIS 2 Directive
Section titled “EU, NIS 2 Directive”The Directive (EU) 2022/2555 (NIS 2) is in force since October 2024. It applies to essential and important entities, including operators of industrial systems in sectors such as energy, water, manufacturing of critical products, chemicals. NIS 2 requires state-of-the-art cybersecurity measures and incident reporting. IEC 62443 is a recognised reference for OT operators when justifying the technical and organisational measures.
EU, Cyber Resilience Act
Section titled “EU, Cyber Resilience Act”The Cyber Resilience Act (Regulation (EU) 2024/2847) becomes applicable December 2027. It sets essential cybersecurity requirements for Products with Digital Elements (PDE) placed on the EU market. IEC 62443-4-1 and 62443-4-2 are expected to underpin conformity for industrial components. For the CRA itself, see Cyber Resilience Act.
US, NERC CIP for electric utilities
Section titled “US, NERC CIP for electric utilities”The NERC CIP standards (CIP-002 through CIP-014) govern cybersecurity of the North American bulk electric system. CIP and 62443 are conceptually aligned: asset classification, electronic security perimeter, system security management, incident response. Many utilities use 62443 as the technical underpinning of their CIP programme.
US, NIST SP 800-82r3
Section titled “US, NIST SP 800-82r3”NIST SP 800-82 Revision 3, Guide to Operational Technology (OT) Security, published 2023, is the US federal reference for OT cybersecurity. It explicitly cross-references IEC 62443 and the NIST SP 800-53 control catalogue, providing a mapping for US operators that need to bridge both worlds.
IT (ISO 27001) versus OT (IEC 62443)
Section titled “IT (ISO 27001) versus OT (IEC 62443)”A recurring confusion in projects is the assumption that an ISO 27001-certified Information Security Management System (ISMS) covers the OT cybersecurity scope. It does not.
| Dimension | ISO 27001 (IT) | IEC 62443 (OT) |
|---|---|---|
| Primary scope | Information assets, IT infrastructure | Industrial automation and control systems |
| Priority order | Confidentiality > Integrity > Availability | Safety > Availability > Integrity > Confidentiality |
| Key concept | ISMS, Annex A controls | Zones and conduits, Security Levels, FRs |
| Audited evidence | Policies, procedures, control records | Risk assessment, system design, component capability |
| Typical asset | Server, workstation, application | PLC, drive, RTU, safety controller |
| Threat model anchor | Data breach, financial fraud | Process upset, equipment damage, safety incident |
The two standards share conceptual building blocks (risk-based approach, governance, controls catalogue) and are often run in parallel by industrial operators: ISO 27001 for the corporate IT perimeter, IEC 62443 for the OT perimeter. A certified ISO 27001 ISMS does not satisfy 62443, and conversely a 62443 component certificate does not cover the corporate IT.
Step-by-step approach for a component manufacturer
Section titled “Step-by-step approach for a component manufacturer”The typical sequence for an electronics company developing an industrial automation device (PLC, drive, RTU, edge gateway) that wants to enter the 62443 evaluation track.
- Define the product class (Software Application, Embedded Device, Host Device, Network Device per 62443-4-2) and the target SL-C per FR.
- Stand up the SDL along the eight 62443-4-1 practice areas (SM, SR, SD, SI, SVV, DM, SUM, SG), including roles, training and process records.
- Build the threat model and the security requirements specification (SR practice), tracing to the FRs at the target SL.
- Apply secure design patterns (SD): defence in depth, attack surface reduction, secure boot, signed firmware, hardware root of trust where relevant.
- Implement and verify (SI, SVV): coding standards, static and dynamic analysis, fuzzing, penetration testing, with results tracked in the defect management database (DM).
- Establish the SUM process (Security Update Management): patch delivery channel, customer notification, end-of-support policy, signed update mechanism. This is often the weakest area in first audits.
- Document the SG (Security Guidelines): hardening guide, secure default configuration, operational guidance for the user.
- Engage a third party lab (ISASecure, TUV Rheinland, TUV SUD, DEKRA, Bureau Veritas) for the SDLA process audit (62443-4-1) and the CSA component audit (62443-4-2).
- Maintain the certificate: re-audit on major releases, monitor vulnerability reports, run the SUM cycle on findings.
- Map to regulatory hooks: CRA preparation in the EU, NIS 2 evidence for downstream operators, NERC CIP for North American electric utility customers, NIST SP 800-82r3 for US federal customers.
For cross-cutting orders of magnitude per phase, see certification timeline.
Common pitfalls
Section titled “Common pitfalls”| Pitfall | Consequence |
|---|---|
| Starting with 62443-4-2 SL-1 component requirements without doing 62443-3-2 zone and conduit risk assessment first | Component over- or under-engineered, no justification of the chosen SL-T, dossier rebuilt |
| Missing 62443-4-1 SDL evidence (process records, threat model, defect database) | Audit blocked at the SDLA stage, component evaluation cannot start |
| Confusing SL-C (capability) with SL-A (achieved) in customer-facing claims | Misleading commercial statements, customer dispute, contractual exposure |
| Neglecting the Security Update Management practice (SUM) of 62443-4-1 | No defensible patch process, regulatory exposure under CRA and NIS 2, customer complaints |
| Assuming ISO 27001 ISMS covers OT cybersecurity | OT perimeter unprotected, NIS 2 non-conformity for the IACS scope |
| Ignoring the Purdue model network segmentation | Zone definitions not defensible, conduit controls weak, integrator audits fail |
| Confusing IT and OT priorities (placing confidentiality above availability and safety) | Inappropriate controls (heavy crypto on time-critical loops, blocking updates), operational incidents |
| Treating 62443 as a one-shot certification | Programme decays after first audit, re-certification surprises on major releases |
Going further
Section titled “Going further”- Cyber Resilience Act: EU regulation for products with digital elements, applicable December 2027
- EN 303 645, consumer IoT cybersecurity: the consumer-IoT equivalent, complementary to 62443 in the industrial scope
- Industrial robotics, ISO 10218 and ISO/TS 15066: functional safety side of industrial automation, often paired with 62443 cybersecurity
- Common Criteria, ISO/IEC 15408: generic security evaluation framework, occasionally invoked alongside 62443 for high-assurance components
- Certification timeline: cross-cutting orders of magnitude per phase
- Glossary: definitions of IACS, SDL, SL, FR, zone, conduit, ISASecure
See also
Section titled “See also”- DO-326A and ED-202A: avionics cybersecurity airworthiness
- ETSI EN 303 645: cybersecurity for consumer IoT
- NISTIR 8425 and the US Cyber Trust Mark: consumer-IoT label
- NIST SP 800-213 and 8259A: US baseline for IoT cybersecurity
- Common Criteria (ISO/IEC 15408): IT security eval
Sources & references
- IEC 62443 series (IEC TC 65 / WG 10) , IEC webstore.iec.ch/en/searchform&q=62443
- ISA-99 / ISA 62443 committee , International Society of Automation www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
- ISASecure certification programme , ISA Security Compliance Institute www.isasecure.org/
- NIS 2 Directive (Directive (EU) 2022/2555) , EUR-Lex eur-lex.europa.eu/eli/dir/2022/2555/oj
- Cyber Resilience Act (Regulation (EU) 2024/2847) , EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security , NIST csrc.nist.gov/pubs/sp/800/82/r3/final
- NERC CIP standards (Critical Infrastructure Protection) , North American Electric Reliability Corporation www.nerc.com/pa/Stand/Pages/CIPStandards.aspx