IEC 62443-4-2 Hardware Security Checklist for OT Edge Devices

IEC 62443-4-2 is the part of the IEC 62443 series that sets the technical security requirements for individual industrial automation and control system (IACS) components: the PLCs, gateways, industrial PCs, HMIs, switches and software that a secure system is built from. Where the system-level parts of the series describe how a site is divided into zones and what each zone must achieve, 4-2 describes what each device has to be capable of.

That makes it the standard engineers reach for when a tender asks for “IEC 62443 compliant” hardware. It is also where the line between IT and OT security becomes practical: the same requirements apply to a fanless PC on a DIN rail, an IIoT gateway at the cabinet and the managed switch beside it, but each meets them with different hardware and firmware features.

This guide is the implementation view. It explains how 4-2 is organised, the seven foundational requirements and four security levels, and how it relates to IEC 62443-4-1 and 3-3. Then it maps each hardware and firmware control, from Secure Boot and TPM 2.0 to BIOS lock-down, logging and tamper detection, to the requirements it supports and what to look for on a datasheet. It closes with what “certified” really means and where the EU Cyber Resilience Act and UK rules fit. We are hardware specialists, not assessors, so treat it as a guide to specifying equipment, not as compliance advice.

IEC 62443-4-2 was published in 2019 as “Technical security requirements for IACS components”, with the matching US edition published by ISA as ISA-62443-4-2-2018. It applies to the component, the thing a supplier builds and sells, and it is written for product suppliers, the integrators who select components and the asset owners who set requirements in a specification.

Four component types

The standard splits components into four types, because a requirement such as “protect the boot process” means something different on a switch than on a software package. Each type has its own prefix for requirements that apply only to it.

An industrial PC running Windows or Linux is usually treated as a host device, while a gateway whose firmware the user cannot change may be assessed as an embedded device. The product supplier decides which type it is claiming, so check this on any certificate.

Component requirements and requirement enhancements

Most requirements are common component requirements, numbered CR 1.1, CR 1.2 and so on, which apply to every type. Where a type needs something different, the requirement is written as SAR, EDR, HDR or NDR with the same number, for example EDR 3.14 and HDR 3.14 for the integrity of the boot process. Each requirement can carry requirement enhancements, written RE(1), RE(2), which add strength or scope and are what separate one security level from the next.

Four common component security constraints (CCSC) apply across the standard. A component must not let security functions compromise its essential functions, such as control or safety; it may rely on compensating countermeasures in the system, provided they are documented; it should apply least privilege; and it should be developed under a secure development process to IEC 62443-4-1.

IEC 62443 groups every security requirement under seven foundational requirements (FRs). The same FRs organise the system requirements in 3-3 and the component requirements in 4-2, which is what lets a system integrator trace a zone’s target down to the devices in it.

FR1 and FR3 carry most of the hardware-related requirements, because identity, keys and boot integrity depend on what is built into the board and the firmware. FR5 is mostly a network device concern, and FR6 depends on the device being able to report events somewhere useful.

Security levels describe how capable an attacker the protection is meant to resist. The definitions come from the standard; the hardware column is our illustration of what tends to change as the level rises, not a list of requirements.

Capability, target and achieved

The series uses three related terms. The capability security level (SL-C) is what a component can deliver when configured as its supplier documents. The target security level (SL-T) is what the asset owner’s risk assessment says a zone needs, set under IEC 62443-3-2. The achieved security level (SL-A) is what the zone actually delivers in operation. A component rated SL-C 2 helps a zone reach SL-A 2 only if it is installed and configured as documented, and only alongside the other measures in that zone.

SL2 is a common baseline in industrial tenders, but it is not a default. The right level comes from the risk assessment for each zone, and different zones on the same site often need different levels.

IEC 62443 is a family of documents, each written for a different role. For hardware selection, three parts matter most, and they are easy to confuse because they share the same foundational requirements.

The simplest way to hold them together: 3-3 says what a zone must achieve, 4-2 says what each component must be capable of so the zone can get there, and 4-1 says how the supplier must develop and maintain the product so those capabilities stay trustworthy. Each system requirement in 3-3 has a matching component requirement in 4-2, so SR 3.4 software and information integrity becomes CR 3.4 at the device. A 4-2 certificate normally assumes the product was developed under a 4-1 process, which is why the two are often assessed together.

The table maps each hardware or firmware control to the IEC 62443-4-2 requirements it supports, as numbered in the 2019 edition, and to what you can check on a datasheet, in the BIOS or with the manufacturer. A control usually supports a requirement rather than meeting it outright: the requirement also covers documentation, configuration and how the feature behaves under test.

Read the right-hand column as questions for the supplier. A datasheet line such as “TPM 2.0” tells you the hardware is there; it does not tell you whether the BIOS can lock it to your configuration, whether firmware updates are signed or how long updates will be published. Those answers decide whether the feature helps you meet the requirement.

FR3 system integrity starts before the operating system loads. If an attacker can change the firmware or boot loader, every control above it can be bypassed, so most of the hardware-specific requirements in 4-2 sit here.

Secure Boot and measured boot

Secure Boot is a UEFI feature that only lets boot code signed with a trusted key run, which supports the boot integrity requirement EDR/HDR 3.14. Measured boot goes further: each stage records a hash of the next into the TPM, so the device can prove later what it booted. Secure Boot blocks unknown code; measured boot gives evidence for remote attestation and for releasing keys only when the boot chain is unchanged. For your own signed images, check that the BIOS lets you enrol your own keys rather than only the manufacturer’s defaults.

TPM 2.0, fTPM and Intel PTT

A Trusted Platform Module holds keys and certificates in hardware, so they cannot be copied off the disk, and stores the measurements from measured boot. It is the usual way to provide the hardware roots of trust in EDR/HDR 3.12 and 3.13 and to protect device credentials under FR1. A discrete TPM is a separate chip; a firmware TPM runs inside the processor, as Intel PTT or AMD fTPM. Both implement TPM 2.0. Discrete TPMs are often preferred where a specification asks for an independently certified security chip, but IEC 62443-4-2 is technology-neutral and does not name the TPM at all.

Signed firmware and updates

Requirement 3.10, support for updates, expects a component to accept updates and to check that they are authentic and unchanged. On an industrial PC that means signed BIOS and firmware images, with the update tool rejecting anything unsigned, and the same for the BMC, network controllers and any switch firmware. Ask the manufacturer how long it will publish BIOS and firmware updates, and how it tells customers about vulnerabilities, because 4-2 assumes the 4-1 process behind it.

BIOS and UEFI lock-down

A BIOS left open undoes the rest. Set a supervisor password, fix the boot order, disable booting from USB and the network unless they are needed, and turn off unused controllers. Save the settings as a profile so every build is the same, which also helps with CR 7.6 network and security configuration settings and makes an audit straightforward.

FR1 and FR2 are mostly about people and processes: who can log in, what they can change, and what is left switched on that nobody uses.

Account management and authentication

Every human user should have a named account, with no shared or hard-coded default passwords on the operating system, the BIOS, the BMC or the switch. CR 1.7 covers password strength, CR 1.11 limits unsuccessful login attempts, and CR 2.1 expects permissions to follow roles so an operator cannot change security settings. At SL3 and above, requirement enhancements add multi-factor authentication for some access, which usually means a central identity service rather than local accounts.

Least functionality

CR 7.7 least functionality is one of the easiest requirements to meet with hardware choices. Disable USB ports that are not needed, or restrict them to keyboards and approved storage; turn off unused serial, wireless and Bluetooth; and stop services such as Telnet, HTTP, unauthenticated discovery and older SNMP versions. Requirement 2.13 covers physical diagnostic and test interfaces such as JTAG and debug headers, which should be disabled or protected in production. A device that never needs a network connection at all may be better as an air-gapped computer.

Network devices

Switches are components in their own right, assessed against the NDR requirements. Many of the managed industrial switches in our range list 802.1X port authentication, RADIUS and TACACS+ central login, access control lists, IP source guard and ARP inspection, alongside VLANs for segmentation under FR5. Our guide to managed vs unmanaged industrial switches covers why an unmanaged switch cannot meet most of these requirements. Switch off discovery protocols such as LLDP on ports that face untrusted equipment.

The remaining controls make a device visible, recoverable and hard to tamper with. They matter most on equipment in remote or unattended cabinets.

Audit logging and time synchronisation

CR 2.8 asks for auditable events such as logins, configuration changes and failures, and CR 6.1 for those logs to be readable by monitoring systems, which in practice means syslog export to a central collector. Logs are only useful if the clocks agree: CR 2.11 asks for timestamps, so specify a battery-backed real-time clock and an NTP source, or IEEE 1588 PTP where the sequence of events across machines matters.

BMC and out-of-band management

A baseboard management controller or Intel AMT on a vPro processor gives out-of-band management: power control, console access and sensor data even when the operating system has stopped. That is valuable at a remote site and a risk if left with default credentials. Put it on its own management network, give it unique accounts, use encrypted protocols and update its firmware with the BIOS. If it will not be used, disable it, which is what CR 7.7 expects.

Encrypted storage and secure erase

An edge computer in an unlocked cabinet can be removed and its drive read elsewhere. Full-disk encryption with the key sealed in the TPM, such as BitLocker on Windows or LUKS on Linux, supports CR 4.1 information confidentiality. CR 4.2 information persistence covers what happens at the end of life: plan a secure erase or a cryptographic erase before a device is returned, repaired or scrapped.

Watchdog, backup and recovery

FR7 resource availability covers keeping essential functions running. A hardware watchdog timer restarts a device whose software has hung, and backup and recovery under CR 7.3 and CR 7.4 mean a known-good image and configuration can be restored quickly. Store recovery images where they cannot be changed by the running system.

Physical tamper and ports

Requirement 3.11 covers physical tamper resistance and detection. On industrial PCs this usually means chassis intrusion detection, which records or alerts when the case is opened, together with a lockable cabinet and blanked or disabled external ports. Higher security levels expect the device to respond, for example by alerting or refusing to release keys, not only to record the event.

The hardware controls above give the operating system something to build on. On Windows, Windows IoT Enterprise LTSC adds lockdown features such as write filters and application control that support protection from malicious code under requirement 3.2, and our guide to Windows 11 IoT Enterprise covers its TPM 2.0 and Secure Boot requirements. On Linux, a minimal embedded Linux image with a read-only root file system and signed updates reduces what can be changed at all. Either way, the image should match the configuration a certificate or test report was based on, or you lose the link between the document and the device.

Protocols need the same care. Our comparison of OPC UA and MQTT covers certificate management, broker access rules and IEC 62443 zones and conduits for the data that edge gateways carry.

Supplier claims about IEC 62443-4-2 range from an independent certificate to a single line on a datasheet. They are not equivalent, and specifications often fail to say which one they require.

Certification schemes include ISASecure, run by the ISA Security Compliance Institute, whose component scheme assesses products against 4-2 and their development against 4-1, and the IECEE scheme, under which certification bodies issue IEC 62443 certificates. A certificate applies to the configuration that was assessed. Change the firmware, the operating system image or the security settings and the device may no longer match it, which is one reason to keep build records.

We do not certify products or issue compliance statements. Where a manufacturer holds a certificate for a model we supply, the manufacturer’s certificate is the evidence; where it does not, we can tell you which security features the hardware has, as listed by the manufacturer, and configure them. Selecting hardware with the right features supports a project’s IEC 62443 work, but whether a system meets its target security level depends on the whole design and how it is operated.

IEC 62443 is a voluntary standard, but regulation is starting to point at the same requirements. The summary below is for orientation only; we are hardware experts, not lawyers, and the legal position for your product depends on what it is and where it is sold.

What the EU Cyber Resilience Act asks for

The Cyber Resilience Act, Regulation (EU) 2024/2847, sets cyber security requirements for products with digital elements sold in the EU, including much industrial hardware and software. It entered into force on 10 December 2024. Manufacturers’ obligations to report actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and most other obligations from 11 December 2027. Its essential requirements, such as secure-by-default configuration, protection against unauthorised access, integrity of software and data, and security updates for a defined support period, overlap heavily with the foundational requirements in 4-2. Harmonised European standards for the Act are still being developed, and the IEC 62443 series is widely expected to inform those for industrial products. Until they are published, treat 4-2 as useful preparation rather than a guarantee of conformity.

UK position

The UK does not apply the Cyber Resilience Act, although UK manufacturers selling into the EU must meet it. The Product Security and Telecommunications Infrastructure regime, in force since April 2024, is aimed at consumer connectable products and bans universal default passwords, among other things; most industrial equipment falls outside it, but its rules are a sensible baseline. Operators of essential services under the NIS Regulations are assessed against the NCSC Cyber Assessment Framework, which looks at outcomes for the whole organisation, and a Cyber Security and Resilience Bill introduced in 2025 proposes to widen that regime. In both cases component requirements such as those in 4-2 are one input among many.

The four products below show how the checklist reads against real datasheets. None is listed as IEC 62443-4-2 certified in our catalogue; each carries features from the checklist, taken from the manufacturer’s specification.

Our wider ranges of industrial IoT gateways, DIN rail PCs and managed industrial switches cover more combinations. We configure every computer with the BIOS settings, TPM, Secure Boot and operating system image you specify, then test it before it ships.