01Five Attack Surfaces, One Ecosystem
A connected product is rarely a single test object. The scope covers the hardware (debug and memory interfaces, component population), the firmware (boot chain, file system, embedded secrets), the radio interfaces (including Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, LoRaWAN, cellular and proprietary sub-GHz protocols), the cloud backend with its APIs, and the accompanying mobile or web app. This breakdown is mirrored exactly in the five requirement categories of the OWASP ISVS – IoT Ecosystem, User Space Application, Software Platform, Communication and Hardware Platform. Testing individual layers in isolation typically misses the transitions between them, such as the onboarding of a device into a user account.
02Hardware Analysis: UART, JTAG, SPI
Hardware analysis starts with identifying components and test points on the circuit board. In practice, serial consoles (UART) frequently expose boot logs, bootloader access or an inadequately protected shell; debug interfaces such as JTAG or SWD allow, depending on the controller's lock state, halting the CPU as well as read and write access to memory. External flash chips on SPI or I2C can in many cases be read out in-circuit or after desoldering. The assessment therefore checks not only whether such access paths exist, but whether debug ports are disabled or authenticated in production, whether secure boot is enforced and whether sensitive parameters are stored encrypted or in a secure element.
03Firmware Extraction and Analysis
Firmware is obtained via vendor downloads, captured update processes or a memory dump and then unpacked. Static analysis looks for hard-coded credentials, private keys and certificates, insecure configurations and outdated components, which are matched against known vulnerabilities via a software bill of materials (SBOM). This is complemented by dynamic analysis on the running or emulated system. The OWASP Firmware Security Testing Methodology (FSTM) describes this approach in nine phases, from information gathering through extraction and emulation to verification of the findings. The central test question remains updateability: is the signature of an update actually verified, and can a downgrade to an older, vulnerable version be prevented?
04Test Catalogues: OWASP ISVS and ISTG, ETSI EN 303 645
Open catalogues are available for both requirements and test execution. The OWASP ISVS bundles security requirements for IoT ecosystems into five categories and is publicly available as Release Candidate 1.0RC; since its version 1.0 of March 1, 2024, the OWASP ISTG adds a pentest methodology with a device and attacker model plus a test case catalogue covering, among other things, radio interfaces, processing units, device memory, internal and physical interfaces, and the firmware and update mechanism. At product level, ETSI EN 303 645 in version V3.1.3 (2024-09) defines a baseline for consumer IoT with 13 topic areas – from eliminating universal default passwords through handling incoming vulnerability reports to the secure storage of security-relevant parameters – complemented by a chapter on data protection provisions. The corresponding assessment methodology is provided by ETSI TS 103 701 (V2.1.1, 2025-05) with test cases per provision; the BSI bases its IT Security Label for smart consumer devices on both documents. A first self-evaluation along the ISVS is possible via the freely available self-assessment at isvs.vamisec.com.
05Regulatory Framework: RED Delegated Act and CRA
Delegated Regulation (EU) 2022/30 makes the cybersecurity requirements of Article 3(3), points (d), (e) and (f) of the Radio Equipment Directive 2014/53/EU applicable to certain categories of radio equipment – internet-connected devices, devices processing personal data (including childcare products, toys and wearables) and devices processing virtual currency or monetary value; products covered by sector-specific regulation, such as medical devices and aviation or automotive equipment, are exempt. The requirements have applied since August 1, 2025, after Delegated Regulation (EU) 2023/2444 postponed the original date by twelve months. EN 18031-1, -2 and -3 are listed in the Official Journal as harmonised standards (Implementing Decision (EU) 2025/138 of January 28, 2025) – albeit with restrictions, including for configurations in which users can choose not to set a password; on these points, the presumption of conformity does not apply. In parallel, the Cyber Resilience Act (Regulation (EU) 2024/2847) takes effect: reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026, the remaining obligations from December 11, 2027; with effect from that date, the Commission has decided to repeal Delegated Regulation (EU) 2022/30 to avoid double regulation.
06A Typical Test Workflow
An IoT penetration test starts with scoping: test objects, the device and attacker model (physical access and authorisation level), the number of test samples and the risks of destructive teardown are defined, complemented by joint threat modelling. This is followed by information gathering, hardware and interface analysis, firmware extraction with static analysis, and the assessment of radio and network protocols as well as the cloud API, onboarding process and app – each with verification of the findings on the running device. The result is a report with reproducible evidence, a traceable risk assessment and a list of measures prioritised by effort and impact; a retest demonstrates the effectiveness of remediation. For manufacturers, this documentation also serves as compliance evidence: Annex I Part II of the Cyber Resilience Act requires effective and regular tests and reviews of product security as well as the identification and documentation of vulnerabilities and components, including a machine-readable bill of materials.
