ISO/IEC 27402 (IoT device baseline requirements), explained

ISO/IEC 27402:2023, "Cybersecurity — IoT security and privacy — Device baseline requirements," is a 16-page International Standard from ISO/IEC JTC 1/SC 27 that sets a minimum, sector-agnostic set of security and privacy requirements for IoT devices. Published in its First edition on 2023-11-20/21, its catalogue scope statement is compact: "This document provides baseline ICT requirements for IoT devices to support security and privacy controls." The standard is commercial — sold by ISO and IEC rather than published in full for free — so this guide draws on the publicly available catalogue scope and table of contents plus an ISO committee explainer co-authored by the standard's own project leaders, rather than the purchased clause text itself; treat specific requirement wording as to be confirmed against a purchased copy before using it for a conformity claim.

A deliberately small, "horizontal" baseline

ISO/IEC 27402 is designed to be read as a floor, not a ceiling. The ISO committee's own explainer — written by project leaders Elaine Newton (Oracle) and Faud Khan (Sprig/TwelveDot), with ISO/IEC JTC 1/SC 27 Technical Programme Manager Hakim Mkinsi — frames the goal as convergence: the standard "seeks to establish a globally harmonised approach to the baseline security and privacy requirements of IoT devices," positioned as "an initial target for all IoT device developers globally." The same explainer is explicit that sector-specific rules are meant to sit on top rather than inside it: "the requirements in this document are intended as a baseline, upon which vertical markets (such as health, financial services, industrial, consumer electronics and transportation) can build additional requirements for the expected use and risks of IoT devices in their applications." In ISO/IEC JTC 1/SC 27's own vocabulary this is a "horizontal" standard — a small set of fundamental controls meant to apply everywhere — with "vertical" standards left to add anything sector-specific (medical devices, vehicles, and similar) on top.

Clause 5: two requirement groups

Per the standard's published table of contents, after the usual front matter (Scope, Normative references, Terms and definitions, Overview), the substantive requirements sit in Clause 5, split into two subclauses:

Subclause	Covers
5.1 Requirements for IoT device policies and documentation	Risk assessment performed "at the IoT device level in the context of a risk assessment at the system level," with documentation of results maintained for audits; information disclosure (features and capabilities made publicly available); and vulnerability disclosure and handling processes.
5.2 Requirements for IoT device capabilities and operations	Configuration, software/factory reset, user-data removal, data protection, interface access control, secure execution of software/firmware updates (update initiation restricted to authorised entities, validity verification mechanisms, options to configure automatic updates, and considerations for devices with safety-relevant functions), event logging best practice, device identifiers, and user notification of security-relevant events.

An informative annex adds risk-management guidance based on ISO 31000, reflecting the committee explainer's emphasis that "the standard underscores the importance of conducting a thorough risk assessment, best performed at design time," considering "intended outcomes, the needs of interested parties, and the unique constraints of IoT devices, such as computing capabilities and data storage." The resulting risk treatment plan is what "lays the groundwork for implementing crucial features and controls" the device must then carry through its documented, supported lifetime.

Where it sits in the ISO/IEC 27400 family

ISO/IEC 27402 is not a standalone document — it is the device-level member of a growing family rooted in ISO/IEC 27400:2022, "Cybersecurity — IoT security and privacy — Guidelines," which gives higher-level, non-mandatory guidance on IoT risk and controls for an IoT "ecosystem" of service providers, developers and users across a system's full lifecycle. Where 27400 guides, 27402 requires: it narrows that guidance down to a baseline of device-level requirements intended to be auditable rather than purely advisory. The family continues to expand — ISO/IEC 27403:2024 addresses IoT-domotics (connected-home environments) and ISO/IEC 27404:2025 defines a cybersecurity labelling framework for consumer IoT — though this guide has not independently verified those two publications' own primary texts and treats the family map as a guide to the series rather than a clause-level comparison.

Built to harmonise, not compete

A distinctive feature of 27402's development is that it explicitly drew on — rather than duplicated — existing device-baseline work. The ISO committee explainer states: "Development of ISO/IEC 27402 benefited from taking existing standards and best practices into account, such as an interagency report from the US National Institute of Standards and Technology (NIST IR 8259A), the UK's Code of Practice for Consumer IoT (converted to ETSI EN 303 645), and the C2 document on IoT Device Security Baseline Capabilities developed by the Council to Secure the Digital Economy (CSDE) consortium." That lineage matters for anyone already working against one of those baselines: NISTIR 8259A's technical capability baseline (see our NIST IoT device cybersecurity requirements guide) and ETSI EN 303 645's consumer-IoT provisions cover substantially the same ground — device identification, secure update, vulnerability disclosure, secure storage of credentials — as 27402's Clause 5, making a device that already meets one of those baselines a strong starting point for the others rather than a from-scratch exercise.

A workable starting point

1. Treat it as the floor, not the whole program. 27402's own stated design intent is a minimum baseline that "vertical markets" are expected to extend — a medical, automotive or industrial IoT device will typically need sector-specific rules layered on top (see our FDA premarket cybersecurity or IEC 62443 guides for two such verticals).
2. Start the risk assessment at design time, not after. Clause 5.1's documentation requirements and the ISO 31000-based annex both assume the device-level risk assessment happens early and gets maintained through the device's supported lifetime, not retrofitted for a certification audit.
3. Cross-check against NISTIR 8259A and ETSI EN 303 645 if you already hold either. Given 27402's explicit harmonisation intent, overlap with those two baselines is substantial — gap-analyse against 27402's Clause 5.2 capability list rather than starting a parallel compliance program.
4. Confirm exact requirement wording against a purchased copy. This guide is built from the public catalogue scope, table of contents and an ISO committee explainer, not the paywalled clause text — don't cite a specific sub-requirement number as settled without checking the standard itself.
5. Watch the 27400 family for sector-specific additions. If your product sits in a vertical ISO/IEC is actively building out (connected-home via 27403, consumer labelling via 27404), confirm whether a newer, more specific standard now applies on top of 27402's baseline.

SoftWSP's device and firmware security assessments can benchmark a device's documented risk assessment, update mechanism and vulnerability-handling process against ISO/IEC 27402-style baseline requirements alongside NIST and ETSI equivalents: see Device & Firmware Security.

This guide summarises ISO/IEC 27402:2023's publicly available catalogue scope and table of contents (ISO and IEC webstore listings) and an ISO/IEC JTC 1/SC 27 committee explainer written by the standard's own project leaders; it is not a substitute for the full purchased standard and does not constitute compliance or legal advice.