IEC 62443 explained for system integrators and OEMs

The IEC 62443 family of standards is the primary technical reference for cybersecurity in Industrial Automation and Control Systems (IACS). Unlike generic security frameworks, this series was designed specifically for OT environments: it accounts for availability constraints, long lifecycles, legacy components, multi-vendor setups, and the separation of responsibilities between who owns the plant, who integrates it and who makes the parts.

For system integrators and OEMs, IEC 62443 is not just a document to mention in proposals. It defines responsibilities, requirements and maturity levels in a structured way. Understanding how it works helps clarify what the customer can demand, what the supplier must guarantee and where each party's responsibility ends.

Structure of the series: four groups, different purposes

The IEC 62443 series is organised into four groups, each identified by the second digit in the document number. Not all documents carry the same operational weight, and not all have reached final publication, but the overall structure is stable and internationally recognised.

Part 1-x: general concepts and terminology

The 1-x group provides foundational definitions, key concepts and the reference model. The most relevant document is IEC 62443-1-1, which introduces the common vocabulary, roles, relationships and the concept of IACS. IEC 62443-1-2 contains an extended glossary. IEC 62443-1-3 covers compliance metrics, and IEC 62443-1-4 addresses the IACS security lifecycle.

For integrators and OEMs, the 1-x group is mainly about aligning on language. When multiple parties work on the same project, using the same terms is not a detail: it prevents ambiguities in specifications, tenders and acceptance tests.

Part 2-x: policies and procedures for the asset owner

The 2-x group primarily addresses the party that owns and operates the plant: the asset owner. IEC 62443-2-1 defines requirements for an IACS cybersecurity management system (CSMS). IEC 62443-2-4, on the other hand, specifies security requirements for service providers who deliver integration, maintenance and support services.

The 2-4 is one of the most relevant documents for system integrators. It defines what the asset owner can require from a service provider in terms of remote access management, hardening, credential handling, documentation, patching, backup and operational procedures. These are not vague recommendations: they are structured requirements, organised by capability and maturity level.

IEC 62443-2-2 deals with IACS protection level assessment, and IEC 62443-2-3 covers patch management in IACS environments.

Part 3-x: system requirements

The 3-x group gets into architecture. IEC 62443-3-2 defines the security risk assessment process for an IACS, introducing key concepts such as zones, conduits and target Security Levels (SL-T). IEC 62443-3-3 specifies system-level security requirements, organised into seven Foundational Requirements (FR).

For integrators, the 3-2 is the starting point for designing the security architecture of a plant. It explains how to partition the system into zones with homogeneous risk profiles, how to connect zones through controlled conduits, and how to assign each zone a security target consistent with the consequences of an incident. The 3-3 translates those targets into concrete technical requirements.

Part 4-x: product and component requirements

The 4-x group targets product suppliers, meaning the vendors of IACS components and software. IEC 62443-4-1 defines the requirements for a Secure Development Lifecycle, and IEC 62443-4-2 specifies technical security requirements for individual components, classified as software applications, embedded devices, host devices or network devices.

For OEMs, these are the reference documents. The 4-1 requires documented processes for threat modelling, vulnerability management, security testing, patch management and end-of-support handling. The 4-2 maps the Foundational Requirements from 3-3 down to individual component types, with different requirements for each device category.

The three roles: asset owner, integration service provider, product supplier

One of the most useful aspects of IEC 62443 is the explicit distinction between three roles, each with its own responsibilities and dedicated requirements.

Asset owner

The asset owner is the party that owns and operates the IACS. They are responsible for defining security requirements, managing risk, maintaining governance and sustaining the security posture over time. In practice: the plant, the end user, the operator. The asset owner defines the target Security Level (SL-T) for each zone and conduit, approves the solutions proposed by the integrator, and ensures that measures are maintained during operation.

The asset owner does not always have the in-house expertise to perform all these activities. In many industrial contexts, part of the work is delegated to an integrator or consultant. But the ultimate responsibility stays with the asset owner.

Integration service provider (system integrator)

The integrator designs, configures, installs and commissions the IACS, or parts of it. IEC 62443-2-4 defines the requirements that an integrator must meet: from account and credential management, to architecture documentation, configuration backup, component hardening, and remote access handling during commissioning and support.

In practice, this means that the integrator cannot simply make the system work and hand it over. They must demonstrate that the system was integrated following security criteria consistent with the Security Level required by the asset owner. They need to produce documentation, follow auditable procedures, handle credentials in a controlled manner and ensure the delivered system is in a known, recoverable state.

For many integrators, this represents a significant shift. Traditionally, commissioning ended with functional acceptance testing. Under 62443, the scope extends to configuration security, change traceability and delivery of documentary evidence.

Product supplier (vendor / OEM)

The product supplier develops and delivers hardware or software components intended for use in an IACS. IEC 62443-4-1 requires a development process that includes threat modelling, vulnerability management, security testing and update management. IEC 62443-4-2 specifies the technical requirements each component type must meet, as a function of the declared Security Level.

For an OEM building machines or subsystems destined for larger plants, compliance with 4-1 and 4-2 is an increasingly common requirement in tender specifications. It is not enough that the product works: it must be developed through a documented process and must expose security capabilities consistent with the levels required by the target system.

Security Levels: what they are and how they work

IEC 62443 defines four Security Levels (SL), numbered 1 to 4, representing the expected level of protection against escalating threat categories. They are not generic severity ratings: they relate to the type of attacker and the resources they can bring to bear.

The Security Level concept comes in three distinct forms:

• SL-T (Target): the desired security level, defined by the asset owner for each zone and conduit based on the risk assessment.
• SL-C (Capability): the security level a component or system is capable of supporting, based on its technical features. This is what the vendor or integrator declares.
• SL-A (Achieved): the level actually reached after integration and configuration in the real operational context.

The relationship between these three levels is fundamental. The asset owner defines SL-T. The integrator selects components with adequate SL-C and configures them to reach SL-A >= SL-T. If a component has SL-C below the target, compensating measures at the system or zone level are required.

In practice, most industrial plants operate between SL 1 and SL 2. Reaching SL 3 requires significant investment in architecture, processes and skills. SL 4 is rare outside government or military critical infrastructure.

Zones and conduits: the core of the security architecture

The zone-conduit model is the mechanism through which IEC 62443-3-2 organises the security segmentation of an IACS. It is not an abstract concept: it is how a risk assessment translates into network and system architecture.

Zones

A zone is a logical grouping of IACS assets that share the same required security level (SL-T). All assets within a zone have homogeneous security requirements. The zone defines a protection boundary: traffic entering or leaving the zone must pass through a controlled conduit.

In practice, a zone may correspond to a production cell, a functional area (e.g. compressors, utilities, packaging), an architecture layer (e.g. field level, control level, supervisory level) or an organisational domain. The choice depends on the risk analysis and the plant structure.

A common mistake is creating zones that are too broad, grouping assets with very different security requirements under the same boundary. Another is making zones too granular, rendering the architecture unmanageable. The 3-2 does not prescribe a fixed number of zones: it requires that the partitioning be consistent with risk and documented.

Conduits

A conduit is the communication channel connecting two zones. It has its own SL-T and must ensure that traffic between zones is controlled, filtered and consistent with the security policy. A conduit may be implemented with a firewall, a DMZ, a data diode, routing rules or a combination of measures, depending on the required security level.

The key principle is that no communication between different zones should occur without passing through a defined and documented conduit. In reality, many existing plants have unmapped flows, direct connections between layers, shared switches across OT and IT networks, or remote access paths that bypass the intended segmentation entirely.

For integrators, the zone-conduit model is both a design tool and a language for communicating with the asset owner. When presenting a network architecture, reasoning in terms of zones and conduits makes boundaries, allowed flows, dependencies and control points explicit.

The seven Foundational Requirements

IEC 62443-3-3 organises system-level technical requirements into seven areas called Foundational Requirements (FR). Each FR contains a set of System Requirements (SR), and for each SR there are Requirement Enhancements (RE) that apply at progressively higher Security Levels.

Not all FRs carry the same weight in every context. In a plant where availability is the absolute priority, FR 7 and FR 5 are often the first to address. Where sensitive process data exists, FR 4 becomes more relevant. Prioritisation depends on the risk assessment and the assigned SL-T values.

For integrators, the FRs in 3-3 are the map of system-level technical requirements to fulfil. For OEMs, the 4-2 translates the same FRs to component level. Consistency between the two levels is essential: a system cannot reach SL 2 if its components do not support at least SL-C 2 for the relevant FRs, unless documented compensating measures are in place.

What changes in practice for a system integrator

For those integrating IACS, IEC 62443 introduces concrete changes on several fronts.

Documentation and handover

Delivering an electrical schematic and an operating manual is no longer sufficient. The 62443-2-4 requires the integrator to provide security architecture documentation, a list of accounts and credentials, configuration baselines, backup and recovery procedures, and a description of hardening measures applied. In many projects, this documentation does not exist or is incomplete.

Access management during commissioning

Credentials used during installation and commissioning must be managed in a controlled way. Temporary accounts, unchanged default passwords, remote access left active after acceptance: these are all points that 62443 addresses explicitly. The integrator must demonstrate that the system is delivered in a "clean" state regarding credentials and access.

Hardening and security configuration

Disabling unnecessary services, closing unused ports, configuring protocols according to vendor recommendations, limiting the privileges of operational accounts: these activities are no longer optional but an integral part of handover when the contract references 62443.

Responsibility for the achieved Security Level

If the contract specifies an SL-T for a zone, the integrator is responsible for demonstrating that the integrated system meets that target, or for documenting gaps and compensating measures. This requires skills beyond traditional automation: network segmentation, identity management, logging, communication protection.

What changes for an OEM

For those manufacturing machines, subsystems or components intended for IACS, parts 4-1 and 4-2 define a precise scope of responsibility.

Secure Development Lifecycle (4-1)

The 4-1 requires the development process to include threat modelling, vulnerability management, security testing, patch release and advisory communication. This is not about appending a security test at the end of development: the point is that security must be embedded in the process, from specification through to end of support.

For a mid-sized OEM, adopting 4-1 can require significant investment in processes and expertise. Certification under 4-1 is available through bodies such as ISASecure (ISCI) and involves documentary and process audits. Not every vendor achieves it, and not every market requires it equally. But the trend is clear: tender documents reference it with increasing frequency, especially in regulated sectors.

Component requirements (4-2)

The 4-2 specifies what a component must support from a security standpoint, as a function of the declared Security Level. For an embedded device at SL 2, for example, the requirements include unique device identification, user authentication, credential protection, security event logging, firmware integrity protection and secure update capability.

Not all components on the market meet these requirements. In many cases, PLCs, HMIs, industrial switches or gateways have limited security capabilities, especially in older versions. The OEM must know the Security Level their product can support and declare it transparently, because the integrator and asset owner depend on it for design decisions.

Certification: ISASecure, IECEE and other schemes

Conformity to IEC 62443 can be self-declared by the vendor or integrator, or independently verified through certification schemes. The main ones are:

• ISASecure (ISCI): a programme managed by ISA offering certifications for components (EDSA, SSA), development processes (SDLA, based on 4-1) and systems (SSA). It is the most widely used international scheme for IACS products.
• IECEE: the IEC conformity assessment system, which introduced a dedicated programme for 62443. It provides conformity assessment through accredited laboratories (CB Scheme).
• TUV, Bureau Veritas and others: several bodies offer 62443-based assessment and certification services, with varying approaches and scopes.

Certification is not legally mandatory in most contexts, but it is becoming a market requirement. Some asset owners mandate it in specifications; others treat it as a preferred criterion. For an OEM, holding 4-1 or 4-2 certification is a tangible competitive advantage. For an integrator, the ability to work according to 2-4 and to document the process is increasingly a prerequisite for participating in regulated-sector projects.

IEC 62443 and NIS2: areas of overlap

NIS2 does not explicitly reference IEC 62443, but the directive's requirements around risk management, incident handling, supply chain security, governance and business continuity overlap substantially with the areas covered by 62443. For industrial organisations that need to comply with NIS2, IEC 62443 provides a coherent technical framework for translating regulatory requirements into concrete measures.

In particular, 62443 addresses aspects that NIS2 requires but does not detail: segmentation, Security Levels, zones and conduits, supplier requirements, secure development lifecycle, and OT patch management. For integrators or OEMs operating within the NIS2 perimeter, adopting 62443 as a technical reference is a prudent and well-supported choice.

Limitations and practical considerations

IEC 62443 is a powerful instrument, but it comes with real-world complexity and practical limits.

• Cost and accessibility: the documents in the series are not free. Purchasing the complete set represents an investment, and reading them requires time and specific expertise. There is no official simplified version for SMEs or first-time readers.
• Publication status: not all documents in the series have reached final publication. Some parts are under revision or development. It is important to check which edition is current before referencing specific requirements.
• Applicability to existing plants: the series was designed for new systems or significant retrofits. Applying it to plants with decades of layered growth, legacy components and undocumented architectures requires compromise and pragmatism. Not everything can be brought to SL 2 without structural work.
• Required expertise: implementing 62443 demands skills that combine automation, networking, cybersecurity and process management. These skills are not yet uniformly available across the industry.
• Gap between theory and practice: the zone-conduit model presupposes a well-segmented and documented network. In many real plants, the network grew over time without a security design, with shared switches, unmanaged VLANs, direct cross-layer connections and unmapped remote access. Before applying 62443, substantial mapping and remediation work is often required.

A gradual, realistic approach

Full 62443 compliance does not need to happen all at once. A realistic path for an integrator or OEM can start with a few concrete steps:

The goal is not formal compliance but the ability to demonstrate that your work follows documented, repeatable security criteria aligned with a recognised standard.

Our take

IEC 62443 is becoming the common language of industrial cybersecurity. It is not the only relevant standard, and it does not solve every problem, but it provides a clear structure for assigning responsibilities, defining requirements and verifying results. For system integrators, it means rethinking how a plant is delivered. For OEMs, it means building security into the development process, not just the finished product.

Those who start working with 62443 today will be in a stronger position tomorrow, when tender documents require it as a baseline rather than an option.

Official resources and useful guidance

• ISA/IEC 62443 Series of Standards — ISA
• IEC — Cyber Security
• ISASecure — Industrial Cybersecurity Certification
• IECEE — IEC 62443 Conformity Assessment
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
• Directive (EU) 2022/2555 (NIS2) — official EUR-Lex text