Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 27402:2023 — IoT Devices and Gateway Security Requirements
Baseline security requirements for IoT devices and gateways with capability class framework
1. Overview of ISO/IEC 27402:2023
ISO/IEC 27402:2023 specifies baseline security requirements for IoT devices and IoT gateways. Unlike the guideline-level 27400, this standard defines concrete, auditable requirements organised into security capability classes. It targets manufacturers, system integrators, and procurement organisations who need verifiable security assurances for IoT components deployed across consumer, commercial, and industrial environments. The standard is structured to be used as a procurement specification, a product development target, and a conformity assessment benchmark against which independent laboratories can evaluate products.
The standard addresses the fundamental problem that IoT devices vary enormously in their security capabilities, making it difficult for buyers to compare products or for manufacturers to know what level of security to target. By defining three distinct capability classes with clear requirements for each, 27402 enables a tiered approach to IoT security that matches protection levels to deployment risk profiles and cost constraints. This class-based approach is also designed to evolve as threat landscapes change, with mechanisms for periodic review and update of class requirements.
When specifying IoT devices for procurement, use the capability class system in 27402 to match security levels to deployment risk. A smart thermostat in a home (Class 1) has very different requirements than an industrial gateway controlling a production line (Class 3). Using Class 3 for all devices would be unnecessarily expensive; using Class 1 for critical infrastructure would be dangerously insufficient.
2. Security Capability Classes
The standard defines three security capability classes that allow organisations to select appropriate security levels based on risk assessment. Each class builds upon the requirements of the previous class, ensuring upward compatibility:
| Class | Security Level | Typical Use Case | Key Requirements | Hardware Dependency |
|---|---|---|---|---|
| Class 1 | Basic | Consumer IoT (light bulbs, smart plugs, sensors) | Unique device identity, secure boot, TLS encryption, OTA updates, no default passwords | Minimal — achievable with secure MCU |
| Class 2 | Enhanced | Commercial IoT (access control, building management, retail) | Hardware root of trust, mutual authentication, intrusion detection logging, secure key storage, signed firmware enforcement | Requires TPM or secure element |
| Class 3 | High | Industrial IoT (SCADA gateways, medical devices, automotive) | Tamper-resistant hardware, certified cryptographic modules, real-time monitoring, fail-safe modes, physical attack response | Requires HSM, tamper-responsive enclosure |
Do not assume that higher class always means better. Class 3 requirements impose significant cost and complexity including certified hardware security modules, tamper-responsive enclosures, and more rigorous testing. Select the class that matches the actual threat model for your deployment context.
3. Detailed Device Security Requirements
For each device, the standard mandates several core security controls. First, a unique and unclonable device identity must be provisioned during manufacturing, typically implemented as an X.509 certificate bound to a hardware security module or trusted platform module. This identity is used for all subsequent authentication operations throughout the device lifecycle. Second, a secure boot process must cryptographically verify each stage of the firmware before execution, using a chain of trust rooted in immutable hardware. This prevents unauthorised or modified code from running on the device. Third, secure firmware update mechanisms using signed and versioned update packages with anti-rollback protection must be implemented, ensuring that devices cannot be downgraded to vulnerable firmware versions. Fourth, the attack surface must be minimised by disabling debug interfaces (JTAG, UART, SWD) in production units through physical fuse blowing or secure configuration locking. Fifth, all cryptographic keys must be stored in hardware-backed keystores rather than filesystem-based storage, preventing key extraction through software exploits.
4. Gateway Security Requirements
IoT gateways receive additional requirements because they aggregate multiple device connections and bridge between IoT and enterprise networks. The standard requires gateways to enforce network segmentation between IoT device segments and corporate networks, preventing lateral movement from compromised IoT devices. Gateways must perform protocol-aware deep packet inspection to detect malicious payloads in IoT protocols such as MQTT, CoAP, and Modbus TCP. Rate limiting and anomaly detection for connected devices must be implemented to identify and isolate devices exhibiting unusual behaviour patterns. Gateways must maintain an up-to-date firmware manifest for all downstream devices, enabling verification that all connected devices are running authorised and current firmware versions. Finally, a secure enrolment mechanism must be provided for new devices joining the network, using techniques such as out-of-band secret sharing, PKI registration, or zero-touch provisioning with manufacturer-issued credentials.
A well-architected IoT gateway implementing 27402 Class 2 requirements can substantially reduce the risk of an IoT botnet originating from your deployed devices. The gateway acts as both a security enforcement point and a centralised management interface, providing visibility and control that individual devices cannot achieve alone.
A practical implementation consideration is that many IoT gateways run Linux-based operating systems. The standard provides specific guidance for securing Linux-based gateways including kernel hardening (removing unnecessary kernel modules, enabling SELinux or AppArmor), filesystem integrity monitoring (using AIDE or Tripwire), and minimising the userland to essential services only. Containerised gateway deployments should implement image signing, vulnerability scanning, and runtime security monitoring using tools such as Falco or Tracee.
Q1: Can a device meet 27402 requirements purely through software?
A: Class 1 requirements can largely be met through software-only approaches such as secure bootloaders and software-based key storage. However, Class 2 and Class 3 require hardware-backed security features such as TPM, secure element, or hardware security module (HSM) for key protection and trusted execution.
A: Class 1 requirements can largely be met through software-only approaches such as secure bootloaders and software-based key storage. However, Class 2 and Class 3 require hardware-backed security features such as TPM, secure element, or hardware security module (HSM) for key protection and trusted execution.
Q2: How does 27402 relate to the IoT Security Compliance Framework (IoTSF)?
A: ISO/IEC 27402 provides an internationally recognised certification-oriented approach with clearly defined capability classes, while IoTSF offers a broader compliance checklist. Both align on core principles, but 27402 provides clearer audit criteria and a more structured progression path.
A: ISO/IEC 27402 provides an internationally recognised certification-oriented approach with clearly defined capability classes, while IoTSF offers a broader compliance checklist. Both align on core principles, but 27402 provides clearer audit criteria and a more structured progression path.
Q3: Does 27402 address cloud backend security?
A: No, 27402 focuses solely on device and gateway security. Cloud security requirements for IoT are covered by complementary standards such as ISO/IEC 27017 (cloud security controls) and ISO/IEC 27018 (PII protection in public cloud).
A: No, 27402 focuses solely on device and gateway security. Cloud security requirements for IoT are covered by complementary standards such as ISO/IEC 27017 (cloud security controls) and ISO/IEC 27018 (PII protection in public cloud).
Q4: How often should device security be re-evaluated?
A: The standard recommends re-evaluation whenever the device firmware is significantly updated, when new threats emerge that affect the device threat model, or at minimum every 12 months for Class 2 and Class 3 devices.
A: The standard recommends re-evaluation whenever the device firmware is significantly updated, when new threats emerge that affect the device threat model, or at minimum every 12 months for Class 2 and Class 3 devices.
