If you manufacture devices that end up in industrial control systems — PLCs, field sensors, edge controllers, remote terminal units — your customers are increasingly asking a specific question: "Are your devices IEC 62443 compliant?" The question sounds simple. The answer requires understanding what part of a very large standard actually applies to device manufacturers, versus what applies to system integrators and asset owners, and what "compliant" means when no third-party audit has been completed.
IEC 62443 is the international standard series for operational technology (OT) cybersecurity. It is published jointly by IEC and ISA (as ISA/IEC 62443) and covers the full lifecycle of industrial control systems: from component manufacturers through system integrators to the end asset owner operating the plant. For IoT device manufacturers specifically, the most relevant parts are 62443-4-1 (Product Security Development Life-Cycle Requirements) and 62443-4-2 (Technical Security Requirements for IACS Components).
Understanding the 62443 Part Structure
The IEC 62443 series is organized into four groups:
Part 1 — General: Terminology, concepts, and a security metrics framework. Foundational reading, not directly actionable for product teams.
Part 2 — Policies and Procedures: Targeting asset owners and operators. Covers patch management, security management systems, protection levels. Less relevant for component manufacturers.
Part 3 — System Requirements: Targeting system integrators designing complete ICS. Defines Security Levels (SL 1-4) for systems, security zones and conduits, and system security requirements. Relevant when your device is sold as part of a complete system, but primarily your integrator customer's concern.
Part 4 — Component Requirements: This is where device manufacturers live. 62443-4-1 defines the secure development lifecycle process requirements. 62443-4-2 defines the technical requirements that a component (your device) must satisfy at a given Security Level.
62443-4-2 Component Security Requirements: What Matters for IoT Hardware
IEC 62443-4-2 organizes component requirements into seven Foundational Requirements (FRs). For IoT device manufacturers, FR1 (Identification and Authentication Control) and FR3 (System Integrity) are the most directly relevant to device identity and firmware security. Here is what they require at Security Level 2 (SL2) — the level most industrial IoT applications target:
FR1 — Identification and Authentication (CR 1.1 through CR 1.13): Devices must support human-user authentication, software process authentication, and device authentication. CR 1.2 specifically requires software process authentication — meaning devices interacting with the control network must authenticate using a mechanism that cannot be easily replicated by an attacker. Certificate-based mutual TLS authentication satisfies this requirement; shared passwords typically do not at SL2.
FR3 — System Integrity (CR 3.1 through CR 3.9): The device must protect its firmware and software from unauthorized modification. CR 3.3 (Security Functionality Verification) requires that the device can verify the integrity of security functions — which is the technical basis for secure boot and firmware signing requirements. CR 3.4 (Software and Information Integrity) requires mechanisms to detect unauthorized modification of software — which maps directly to cryptographic firmware signing and bootloader verification.
CR 7.3 — Control System Backup and CR 7.6 — Network and Security Configuration Settings Backup: These requirements specify that configuration, including security configuration (keys, certificates), must be backed up and restorable. For devices using per-device certificates, this implies the need for certificate re-issuance capability when a device is replaced or restored.
62443-4-1: Your Development Process Must Be Auditable
While 62443-4-2 defines what your device must technically do, 62443-4-1 defines how your organization must develop it. For a third-party certification audit, the assessor will look at both the device's technical capabilities and the evidence that your development process produced those capabilities deliberately, not accidentally.
Key practices 62443-4-1 requires (summarized from the published standard):
SM-1 through SM-13 (Security Management): A documented security policy, defined security roles (who in your organization owns the security of the product?), and a process for receiving and responding to vulnerability reports. Many hardware startups have no defined external vulnerability disclosure process — this is an audit finding under 62443-4-1.
SR-1 through SR-8 (Security Requirements): Security requirements must be defined during the requirements phase and traced through to implementation and testing. "We designed it to be secure" is not sufficient — the standard requires documented evidence that specific security properties were specified, designed, and tested.
SUM-1 through SUM-4 (Security Updates Management): Devices must have a defined mechanism for receiving security updates. This is explicitly stated in the standard and applies to the entire deployed lifetime of the product. A device with no OTA update capability — or with OTA update capability that is not signed — is non-conformant with 62443-4-1 for any product with a defined support lifetime.
Security Levels and What Your Customers Are Actually Asking For
The IEC 62443 Security Level framework (SL 1-4) is often misapplied. The levels describe the sophistication of the threat actor the system is designed to withstand:
- SL1: Protection against unintentional or coincidental violation — casual scanning, opportunistic malware.
- SL2: Protection against intentional violation using simple means — a motivated attacker with standard tools and limited ICS-specific knowledge.
- SL3: Protection against intentional violation using sophisticated means — a skilled attacker with ICS-specific knowledge and resources.
- SL4: Protection against state-sponsored or highly sophisticated targeted attacks.
Most industrial IoT applications in manufacturing, utilities, and building automation target SL2. Critical infrastructure (power generation, water treatment) is increasingly specified at SL3. The security requirements that apply to your device depend on which SL your customers are designing to.
We're not saying SL2 is universally sufficient. An attacker with physical access to the device and ICS-specific knowledge can probe beyond SL2 controls. But designing every device to SL3 or SL4 introduces cost and complexity that is not warranted for the majority of industrial IoT deployments. The standard explicitly acknowledges this tradeoff — part of the design work is documenting which SL you're claiming and why.
Scenario: Edge Controller Manufacturer Entering the European Market, 2024
An APAC-based manufacturer of industrial edge controllers — devices that aggregate data from PLCs and forward to cloud SCADA platforms — begins receiving requests from European system integrators for IEC 62443-4-2 SL2 conformance documentation. The devices already have TLS transport and basic authentication, but no device certificates (shared API keys per customer deployment), no secure boot, and no signed OTA updates.
The gap analysis against 62443-4-2 SL2 produces four findings: (1) Device authentication under CR 1.2 is not met — API keys are shared per deployment, not per device. (2) Software and information integrity under CR 3.4 is not met — no firmware signing. (3) The development process has no documented vulnerability disclosure procedure — finding under 62443-4-1 SM-6. (4) No defined OTA update mechanism for security patches — finding under 62443-4-1 SUM-2.
Remediating findings 1 and 2 required adding per-device X.509 certificate provisioning and MCUboot-based secure boot to the next hardware revision. Finding 3 was addressed by publishing a vulnerability disclosure policy page and email alias. Finding 4 required adding signed OTA update support to the device software stack. Total timeline from gap analysis to remediation: approximately 14 months across two hardware revision cycles. The cost of not having built these capabilities in from the start was significant.
Practical Implementation Steps for New Products
For teams starting a new IIoT product that will eventually need 62443-4-2 SL2 conformance, the architecture decisions that must be made in hardware revision 1 are:
Cryptographic hardware: Does the MCU or SoC include a hardware-accelerated cryptographic engine and a mechanism for hardware-bound key storage? This cannot be added after silicon selection. For Cortex-M33-based designs, TrustZone + internal SRAM key isolation is the baseline. For higher assurance, a discrete security element (e.g., Infineon OPTIGA Trust or Microchip ATECC series) provides hardware-bound key storage without requiring the main MCU to support TrustZone.
Firmware signing key infrastructure: Decide during hardware design whether to use MCUboot or a proprietary bootloader, what signing algorithm (ED25519 is preferred for constrained devices — smaller key and signature than RSA-2048), and where the signing keys will live in the manufacturing and CI/CD pipeline.
Certificate provisioning point: Factory provisioning (during PCB test/assembly) is strongly preferred over first-boot provisioning for IIoT devices, because factory provisioning is audit-traceable and the certificate-to-serial binding can be verified in the production system before the device ships.
Vulnerability disclosure process: Publish a security.txt file and email alias before your first device ships. This is a one-hour task that will show up as a gap in every 62443-4-1 audit if it's missing.
The standard is detailed and the certification process is not trivial — but the underlying security properties it specifies are engineering-good practices regardless of whether a formal audit is on the roadmap. Treating 62443-4-2 as a checklist to game is the wrong approach. Treating it as an articulation of what a well-engineered industrial device should be able to do defensively produces better devices and, as a side effect, makes certification easier.