IEC 62443 industrial security requirements shape almost every stage of connected device design across manufacturing and process industries. The standard offers a comprehensive approach to identifying and mitigating vulnerabilities within industrial networks by recognising that a water treatment plant, a pharmaceutical line, and an automotive factory or power substation each carry different risk profiles and therefore need different depths of protection.
Originally written for large control room installations, it’s now the reference framework that gateway designers and firmware engineers work against on IoT devices, whether or not those devices are ever formally certified. This post covers what the IEC 62443 industrial security standard asks of an IoT device, and where UK operators are already being held to it in practice.
This is the fifth post in Ignitec’s Industrial IoT and Automation series. Earlier posts covered MQTT as the dominant messaging protocol for industrial telemetry, WiFi HaLow as a long-range low-power alternative for sprawling sites, industrial gateway design principles, and the practicalities of building gateways around the ESP32 platform. IEC 62443 sits above all of that architecture, and determines whether the protocol and gateway assumptions made in those earlier posts will hold up to scrutiny.
Why IEC 62443 industrial security has moved from guidance to expectation
IEC 62443 carries no statutory force in the UK, unlike product safety marking, yet its practical weight has grown considerably over the past few years. UK operators of essential services fall under the Network and Information Systems Regulations (NIS), and the National Cyber Security Centre’s Cyber Assessment Framework (CAF), which those operators are assessed against, aligns closely with IEC 62443 at a technical level. A device or system that can demonstrate IEC 62443 alignment gives its operator a running start on a CAF assessment, and the standard now turns up routinely in UK procurement specifications across energy, water, transport and manufacturing supply chains.
For product designers, this changes the brief: IEC 62443 has to be scoped before the first PCB layout or firmware architecture decision, in the same way EMC or power budget considerations are scoped early, rather than left for a client’s security team to handle once a device has shipped. Retrofitting alignment onto a finished product is possible, but it’s slower and more expensive, and it rarely clears 4-2 component-level requirements without hardware changes.
How the IEC 62443 industrial security standard is structured
IEC 62443 is a family of documents rather than a single certificate, and understanding which part applies to which role on a project avoids a lot of wasted effort.
- General (62443-1-x): Shared terminology, concepts and models used across the rest of the series.
- Policies and Procedures (62443-2-x): Requirements for asset owners running a security management programme.
- System (62443-3-x): Requirements for system integrators, including the zone and conduit segmentation model and target security levels for a given system.
- Component (62443-4-x): Requirements for product suppliers, covering the secure development lifecycle in 62443-4-1 and technical requirements for individual components in 62443-4-2.
For an IoT device manufacturer, or a company building industrial gateways as covered in the earlier posts in this series, the practical focus sits in 62443-4-1 and 62443-4-2. But those two documents cannot be read in isolation. A device’s actual security requirements are set by the target Security Level (SL-1 to SL-4) assigned to the zone it will operate in, which is a System-level (62443-3-x) decision made by whoever is architecting the wider installation.
|
🛠️ DESIGN CONSIDERATION Security Level targets should be agreed with the system integrator or asset owner before component selection begins. A gateway spec’d for SL-2 protection against casual or unintentional misuse will need a materially different secure boot chain, key storage and update mechanism than one spec’d for SL-3 protection against a sophisticated, resourced attacker. Confirming the target SL early avoids over-engineering low-risk zones and under-engineering the ones that actually need it. |
Zones, conduits and the gateway layer
The zone and conduit model at the heart of IEC 62443-3-2 divides an industrial network into groups of assets that share a security requirement (zones), connected by defined communication paths (conduits) that can be monitored and controlled. This is where the architectural decisions covered earlier in this series become directly relevant. A gateway sitting between an MQTT broker on the OT side and a corporate network on the IT side is, in IEC 62443 terms, a conduit, and its design needs to reflect that rather than being treated as a generic network appliance.
Access technology choice feeds into this directly. A WiFi HaLow deployment spanning a large site introduces a different segmentation challenge to a wired or short-range wireless installation, simply because of the physical area a single zone might cover. Gateway placement, and the hardware decisions discussed in the ESP32 industrial gateway post, need to account for where zone boundaries actually sit on the site plan, not just where power and connectivity happen to be convenient.
|
⚠️ CRITICAL ALERT Treating IEC 62443 as a one-off certification exercise rather than an ongoing lifecycle is a common and costly mistake. A component certified against 62443-4-2 today can fall out of compliance through an unpatched vulnerability or a change in the zone it operates in. Security level targets and conduit boundaries need reviewing whenever a system changes, not only at initial deployment. |
The secure industrial IoT product development lifecycle (IEC 62443-4-1)
IEC 62443-4-1 sets out requirements for how a product itself is developed, not just what it does once deployed. For engineering teams, this means formal practices around threat modelling at the architecture stage, secure coding standards, third-party component and dependency tracking, vulnerability handling and disclosure processes, and a defined, verifiable process for delivering firmware updates over the life of the product.
What this looks like in practice for a constrained IoT device
For a resource-constrained edge device, such as the ESP32-based gateways discussed earlier in this series, meeting 62443-4-1 typically involves a documented threat model produced before hardware is finalised, a secure boot chain that verifies firmware signatures before execution, encrypted and authenticated storage for credentials and keys rather than plaintext flash, and a rollback-resistant over-the-air update mechanism with a clear revocation path if a signing key is ever compromised.
|
🛠️ DESIGN CONSIDERATION Secure boot and signed firmware updates are frequently treated as software features to be added later in the project. On constrained hardware they’re architectural decisions: key storage and the flash budget for a dual-bank update scheme need to be accounted for in the initial bill of materials, not discovered as a gap during 62443-4-2 assessment. |
Case study: Certifying an energy sector system against IEC 62443
TÜV SÜD assessed Siemens Energy solutions and development processes against IEC 62443-3-3 and IEC 62443-4-1 as part of a formal cybersecurity certification process. It examined both system security requirements and the company’s secure product development lifecycle rather than applying a checklist to a finished product alone. This case illustrates how IEC 62443 certification increasingly evaluates the processes behind industrial products, particularly secure development lifecycle practices, rather than focusing only on the security features of a finished device.
Case study: What happens when segmentation fails
The 2019 LockerGoga ransomware attack on Norsk Hydro is one of the most extensively documented industrial cybersecurity incidents of the past decade. It illustrates the practical value of the zone and conduit approach even where a formal IEC 62443 assessment was not the trigger for recovery. Attackers gained an initial foothold through a phishing email, then escalated privileges and moved laterally through Norsk Hydro’s Windows-based IT environment before deploying ransomware that encrypted files and locked user accounts. The attack disrupted IT systems supporting approximately 35,000 employees across 40 countries.
Importantly, later reporting indicated that Norsk Hydro’s industrial control systems themselves were not directly compromised. The separation between enterprise IT and OT environments limited the impact, allowing plants to continue operating through manual processes while IT systems were restored from backups. The company achieved significant recovery within days and full recovery within approximately one month, with total costs later estimated at around $71 million.
The incident is now widely used as a reference case precisely because it demonstrates why segmentation, i.e., the separation that existed between IT and OT systems in this case, limited the damage. IEC 62443 formalises this principle through its zones and conduits model, requiring organisations to design controlled communication paths between industrial assets rather than relying on accidental separation.
The UK regulatory picture for industrial IoT security
IEC 62443 sits at the centre of how UK regulators and auditors expect operational technology risk to be managed, even though it isn’t itself a piece of UK legislation. Operators of essential services under the NIS Regulations are expected to manage cyber risk proportionately and demonstrably, and the NCSC’s guidance on industrial control systems aligns closely with IEC 62443 at a technical level. The Health and Safety Executive has also referenced IEC 62443 directly in guidance covering cybersecurity for industrial automation and control systems, alongside NCSC principles, for sites that fall under both safety and NIS obligations.
For product and system suppliers, the practical effect is that IEC 62443 alignment is increasingly requested in tender documentation and supply chain security requirements across energy, water, transport and critical manufacturing, even where it is not contractually mandatory. Being able to point to a documented secure development lifecycle and defined security level for a product is becoming a genuine commercial differentiator across many sectors, not just a compliance cost.
|
⚠️ CRITICAL ALERT IEC 62443 alignment is increasingly treated by UK asset owners as evidence of proportionate risk management under the NIS Regulations, even though the standard itself carries no statutory force. Suppliers who can evidence a secure development lifecycle and a stated security level are starting to win procurement conversations that suppliers without that documentation cannot enter. |
Final thoughts: Where industrial IoT security standards leave product and system design
IEC 62443 industrial security is best treated as a design constraint that runs alongside protocol choice and network architecture, not as a compliance step bolted on at the end. The zone and conduit decisions made when architecting a gateway network, and the secure development practices applied to firmware and updates, both feed into the same overall security posture. Getting the target security level agreed early, and designing to it from the first review, is consistently cheaper and more defensible than retrofitting compliance onto a finished product.
The next post in this series turns to predictive maintenance in industrial environments, and how the data gathered through the gateway and messaging architecture built up over this series can be put to work.
|
WORK WITH IGNITEC Ignitec designs and engineers industrial IoT products and gateways with security built in from the first architecture review, including secure boot and signed firmware update paths aligned to IEC 62443-4-1 and 4-2. If you’re scoping a new industrial device or reviewing an existing product against a target security level, our engineering team can help you get the design decisions right before they become expensive to change. |
IEC 62443 industrial security is ultimately about designing systems that stay trustworthy as they age and change, not just passing a single assessment. If you are scoping a new IIoT deployment or need an independent technical review before committing to a vendor, get in touch to discuss your requirements with our product design and engineering specialists.
