IEC 62443 is a family of more than a dozen documents written for asset owners, integrators and product suppliers. For an edge device — an AI gateway, a smart camera, a wireless sensor node — the practical core is much narrower. The device is a component, its technical requirements live in IEC 62443-4-2, and most of what goes wrong in the field comes down to a short list of controls: credentials, boot integrity, updates, exposed services, logging and knowing what software is inside.
This article maps the series, gives the checklist we work from, and sets out the EU Cyber Resilience Act dates device makers now face. One distinction runs throughout: designing in line with IEC 62443 is not the same as being certified to it.
How the IEC 62443 series fits together
The series is organized by audience. These are the parts that matter most for edge devices:
| Part | What it covers | Written for |
|---|---|---|
| 62443-2-x | Security programs and policies | Asset owners and service providers |
| 62443-3-2 | Security risk assessment for system design — zones, conduits, target security levels | Asset owners and integrators |
| 62443-3-3 | System security requirements and security levels | Integrators and system designers |
| 62443-4-1 | Secure product development lifecycle | Product suppliers |
| 62443-4-2 | Technical security requirements for components | Product suppliers |
The split between 3-3 and 4-2 is the one people trip over. IEC 62443-3-3 states system requirements: what the assembled control system must be able to do. IEC 62443-4-2 states component requirements: what each software application, embedded device, host device or network device must contribute. A gateway that cannot enforce unique accounts makes the system requirement for user identification harder to meet, however good the firewall is. A smart camera is usually assessed as an embedded device; a gateway that also forwards traffic between networks may pick up network-device requirements too.
The seven foundational requirements
Both parts organize their requirements under the same seven foundational requirements (FRs):
- Identification and authentication control — every user, process and device is identified before it is trusted.
- Use control — each identified party can do only what it is authorized to do.
- System integrity — software, configuration and data are protected against unauthorized change.
- Data confidentiality — information is protected in transit and at rest where it needs to be.
- Restricted data flow — the network is segmented so traffic goes only where it should.
- Timely response to events — security events are recorded and can be acted on.
- Resource availability — the device keeps working, or fails safely, under load, attack or fault.
Security levels
Security levels describe the attacker a zone, system or component is meant to withstand. SL 1 protects against casual or coincidental violation. SL 2 protects against intentional violation using simple means, with low resources, generic skills and low motivation. SL 3 assumes sophisticated means, moderate resources, skills specific to industrial control systems and moderate motivation. SL 4 assumes the same sophistication with extended resources and high motivation.
The number is used three ways. The target level (SL-T) comes out of the risk assessment for each zone and conduit. The capability level (SL-C) is what a component or system can deliver when properly configured. The achieved level (SL-A) is what is actually in place. A datasheet can only ever tell you SL-C; SL-A depends on how the device is installed and run.
Zones and conduits
IEC 62443-3-2 has you partition the system into zones — groups of assets with shared security requirements, such as an inspection cell — and conduits, the communication paths between zones, each with its own controls. Edge devices often sit on a boundary. A gateway with one port on the cell network and one on the plant network is part of a conduit, and it must not route between the two unless that is the documented design.
The hardening checklist
This is the list we work through on every edge device, whether it is ours or one we are integrating. It does not replace the requirements of 4-2, but it covers the controls that most often fail in practice.
Identity and access (FR 1, FR 2)
- A unique credential per device, set at manufacture or forced at first commissioning. No shared default password across a fleet, and no credentials hard-coded in firmware.
- Named accounts with roles; no shared administrator login. People authenticate through the plant’s single sign-on where possible.
- Per-device certificates for device-to-device and device-to-server authentication, with private keys held in a TPM or secure element.
- Lockout or rate limiting on failed logins, and multi-factor authentication for any access from outside the zone.
Boot and software integrity (FR 3)
- Secure boot from a hardware root of trust through the bootloader, kernel and application.
- Signed updates, verified on the device before installation, with anti-rollback so an older vulnerable image cannot be reinstalled.
- A/B partitions, so a failed update leaves the previous image bootable.
- A read-only root filesystem where practical, and integrity checks on configuration.
Least privilege and minimal surface (FR 2, FR 7)
- Services run as unprivileged users; containers do not run as root.
- Unused services, debug consoles and programming headers are disabled on production units. USB storage is off unless the update process needs it.
- Every listening port is documented, with an owner and a reason.
Network exposure (FR 4, FR 5)
- Inbound traffic is denied by default; outbound traffic goes only to named destinations.
- No routing or bridging between interfaces unless designed and documented.
- Encrypted, authenticated protocols where the protocol allows it — MQTT over TLS, OPC UA with signing and encryption. Legacy industrial protocols that run without authentication stay inside their zone.
Logging and monitoring (FR 6)
- Security-relevant events are logged: logins and failures, configuration changes, updates, time changes and service restarts.
- Clocks are synchronized, and logs are forwarded to the plant’s collector, with a local buffer for when the link is down.
- Logs never contain secrets.
SBOM and vulnerability handling (FR 3, plus the process requirements of 4-1)
- A machine-readable software bill of materials for every firmware release, in SPDX or CycloneDX, covering model runtimes and libraries, not only the operating system.
- Continuous matching of the SBOM against newly published vulnerabilities, with each match triaged: is the vulnerable code present, reachable and exploitable in this configuration?
- A published disclosure policy and contact, a stated support period, and target fix times by severity.
Recovery (FR 7)
- Configuration backup and restore, a factory reset that destroys keys and secrets, and a documented decommissioning procedure.
- Watchdogs and graceful degradation, so an overloaded device fails to a known state.
Alignment is not certification
Three claims appear on datasheets, and they mean different things.
- “Designed in line with” or “aligned with” IEC 62443. The supplier has mapped its design to the requirements. It is a statement of engineering intent, backed at best by an internal or independent gap assessment. It is the claim we make for our own hardware: designed in line with IEC 62443-4-2 component requirements.
- “Conforms to” a part at a stated level. The supplier asserts that the product meets specific requirements at a specific security level, and should be able to show evidence requirement by requirement.
- “Certified.” An accredited certification body has assessed the product — and, in schemes such as ISASecure Component Security Assurance, the supplier’s development process under 4-1 as well — and issued a certificate naming the product, the versions and the capability security level. The IECEE also runs a certification scheme for IEC 62443.
When a supplier says “certified”, ask for the certificate, the certification body, the exact product and firmware versions covered, and the security level. When a supplier says “aligned”, ask for the requirement mapping. Both are legitimate. They are not interchangeable.
The EU Cyber Resilience Act timeline for device makers
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements made available on the EU market — including machines with embedded computers built by US equipment makers and sold into Europe. It entered into force on 10 December 2024 and applies in stages:
| Date | What applies |
|---|---|
| 11 June 2026 | Rules for notifying conformity assessment bodies |
| 11 September 2026 | Manufacturers’ obligations to report actively exploited vulnerabilities and severe incidents |
| 11 December 2027 | Main obligations, including the essential cybersecurity requirements, conformity assessment and CE marking |
The reporting obligations have applied since 11 September 2026, and they cover products already on the market, not only new ones. A manufacturer that becomes aware of an actively exploited vulnerability or a severe incident must send an early warning within 24 hours and a notification within 72 hours. A final report follows: for a vulnerability, no later than 14 days after a corrective measure is available; for a severe incident, within one month. Reports are submitted once, through a single reporting platform, and reach both the relevant national CSIRT and ENISA.
A 24-hour deadline is not long. Meeting it requires knowing, for every product you ship, which components and versions are inside it — which is why the SBOM item on the checklist matters. The main obligations make the point explicit: the vulnerability-handling requirements include a software bill of materials covering at least the top-level dependencies.
Aligning with IEC 62443-4-1 and 4-2 is a sound engineering basis for CRA readiness, and much of the work overlaps. It is not, by itself, a demonstration of CRA conformity; the regulation has its own essential requirements and conformity assessment routes.
Our Edge & OT Security work covers device hardening, segmentation and readiness support for equipment makers; for custom devices, our embedded engineering team builds secure boot and signed updates in from the first board. The Security & Trust Center describes how we handle vulnerability disclosure and SBOMs for our own products. If you run isolated sites, our note on air-gapped AI covers how signed updates reach devices without a permanent connection.