When a plant connects its PLCs to the cloud, the question "is this secure?" stops being theoretical — auditors, insurers and end customers all want an answer. IEC 62443 is the international family of standards that structures cybersecurity for industrial automation, and it has become the de facto language in which integrators, device manufacturers and operators discuss risk in IIoT.
In short: IEC 62443 is a set of security standards for industrial automation and control systems (IACS). It splits responsibility between the asset owner, the system integrator and the component supplier, and defines a four-step Security Level scale (SL 1–SL 4). For an IIoT device manufacturer, parts 4-1 (secure development lifecycle) and 4-2 (technical requirements for components) matter most.
What is the IEC 62443 standard and who does it apply to?
IEC 62443 is a series of standards developed by ISA and IEC that describes cybersecurity for IACS environments — from a single sensor up to the entire plant network architecture. Its defining feature is a role-based approach: the same threats are addressed separately from the perspective of three participants in the supply chain.
- Asset owner — parts 2-x: policies, security programme management, operational continuity.
- System integrator (service provider) — parts 3-x: architecture design, zone and conduit partitioning, system requirements.
- Product supplier — parts 4-1 and 4-2: the product development lifecycle and the technical requirements for the device itself.
This structure has a practical consequence: a sensor or gateway vendor cannot "certify an entire plant", but it can document that its product meets the component requirements at a declared level.
Security Level: how does the SL 1–SL 4 scale work?
A Security Level measures resistance to an adversary with defined resources and motivation — it is not an abstract rating of "security quality". The standard defines four levels:
- SL 1 — protection against accidental or mistaken operator action.
- SL 2 — resistance to a deliberate attack using simple means, low motivation and generic skills.
- SL 3 — resistance to attacks using sophisticated tools and IACS-specific knowledge.
- SL 4 — resistance to an adversary with extended resources, typically a state actor.
In practice most industrial projects target SL 2, with critical zones at SL 3. The level is declared separately for each of the seven Foundational Requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.
Zones and conduits: the foundation of a secure OT architecture
A zone is a group of assets that share common security requirements, and a conduit is a controlled communication path between zones. In this standard, segmentation matters more than any single cryptographic mechanism.
A typical plant partitioning follows the Purdue model levels: the control zone (PLCs, drives), the supervisory zone (SCADA, HMI), the industrial DMZ and the IT zone. An IIoT gateway almost always sits in the DMZ and acts as the single conduit to the outside world — which is why its configuration determines the real level of risk. Here it pays to use protocols with a native security model, such as OPC UA in industrial IoT, rather than tunnelling unprotected fieldbuses.
In retrofits of legacy installations the conduit usually ends in protocol conversion — we covered this in detail using the example of Modbus RTU/TCP integration with the cloud.
Part 4-2: what does the standard require from a device?
Part 4-2 translates the general requirements into concrete technical component capabilities. For a firmware team this means a list of features that must be designed in, not bolted on at the end of the project.
- A unique device identity and certificate-based authentication instead of shared passwords.
- Roles and permissions (RBAC) that separate the service account from the operator account.
- Software integrity: signed firmware, verification at boot and a secure update path.
- Transport encryption (TLS 1.2/1.3) and protection of data at rest.
- Security event logging with a tamper-resistant timestamp.
- Controlled session management, locked debug ports and disabled unused services.
Integrity requirements are met in hardware — the starting point is secure boot and a trusted device startup anchored in a key fused into the microcontroller's OTP memory.
How does IEC 62443 relate to the Cyber Resilience Act and NIS2?
IEC 62443 is a technical standard while the CRA and NIS2 are legal acts — the standard provides a proven way to demonstrate compliance with regulatory obligations. The CRA regulation requires manufacturers of products with digital elements to perform risk analysis, handle vulnerabilities throughout the support period and deliver security updates.
In practice this overlaps with part 4-1 of the standard, which describes a secure development lifecycle (SDL): threat modelling, security requirements, testing, vulnerability management and a product end-of-life procedure. We explore the legal context in our article on CRA obligations for IoT manufacturers, and component inventory in the piece on SBOM for IoT devices.
Frequently asked questions (FAQ)
Is IEC 62443 mandatory?
The standard itself is not legally mandatory, but it is increasingly required contractually — in industrial and energy tenders and across automotive supply chains. It also serves as a recognised route to demonstrating compliance with regulations such as NIS2 and the Cyber Resilience Act, so in effect it functions as a market requirement.
How long does component certification to part 4-2 take and what does it cost?
For a single component a typical project runs six to twelve months, depending on process maturity and the number of technical gaps. The largest cost is not the notified body audit but implementing part 4-1: a documented development process covering threat modelling, testing and vulnerability management.
How is IEC 62443 different from ISO 27001?
ISO 27001 describes an information security management system for an organisation, prioritising data confidentiality. IEC 62443 addresses control systems, where availability and the integrity of the physical process come first. The standards complement each other: ISO 27001 organises the company, IEC 62443 supplies technical requirements for devices and OT architecture.
Summary and key takeaways
IEC 62443 is not a checklist to tick off before an audit — it is a way of designing industrial systems from the first architecture sketch. Three practical takeaways: define the target Security Level for every zone before you select hardware; treat part 4-1 as a process project, because that is where most of the work comes from; and build device identity and signed firmware in from the start, because retrofitting them usually means a redesign.
At FSS Technology we design industrial devices and gateways to these requirements — from selecting a microcontroller with secure boot, through firmware with RBAC and TLS, to the backend that registers the fleet. If you are planning an IIoT product or deployment that must comply with this standard, explore our connected device services and let's talk about your architecture.