IoT penetration testing and hardware hacking: from the chip to the device cloud

A connected device is much more than its app: it has a board with debug ports, a memory chip holding its firmware, a radio and a cloud that receives data from the whole fleet. We test all of it in our lab, the way an attacker with the device in hand would, and deliver every finding with its proof of concept and its reference to the OWASP IoT Top 10, EN 18031 and the Cyber Resilience Act.

Scope your project · Request an IoT assessment

Rather talk it through? Call us at +34 960 730 013

Chip to cloud — Hardware, firmware, radio, app, API and OTA in a single scope
UART · JTAG · SPI — Debug interfaces and memory chips tested in the lab
EN 18031 — Findings mapped to the RED standard, the CRA and the OWASP IoT Top 10
Retest — Verification of firmware and backend fixes included

Why an IoT device is a different kind of risk

A server is tested over the network. An IoT device can also be opened up: anyone who buys a unit has its board, its memory and its debug ports on the bench, and whatever they get out of it —a factory password, a private key, a way around authentication— usually works on every unit sold. That's why a flaw in a device is rarely about one device: it's about the whole fleet.

On top of that, the device lives inside the customer's network. A compromised camera, HVAC controller or PLC is a foothold into the corporate network, and in industrial environments the impact can be physical.

And it's no longer just a question of risk. Since 1 August 2025, internet-connected radio equipment sold in the EU must meet the cybersecurity requirements of Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive, with the EN 18031 standards as the way to demonstrate it. The Cyber Resilience Act requires actively exploited vulnerabilities to be reported from 11 September 2026 and becomes fully applicable on 11 December 2027. An IoT penetration test is how you find out, before an attacker or a market surveillance authority does, what can be pulled out of your device.

One device, from the board to the cloud

Explore the board component by component to see what we test on each one, or play a typical attack chain: from the serial console pads to the telemetry of the entire fleet.

UART serial console (OWASP IoT I9 · I10): We identify the TX, RX and GND pads, the line speed and what the console exposes: boot messages, the bootloader and whether it can be interrupted to get a shell. Typical finding: An interruptible U-Boot console or a password-less root shell left in for factory testing.
JTAG/SWD debugging (OWASP IoT I10): We locate the debug points and check whether readout protection is enabled or whether the processor can be halted, its internal memory read and the running code modified. Typical finding: Debug port left open in production: a dump of the microcontroller's internal flash, keys included.
SPI flash memory (OWASP IoT I5 · I7): We read the chip with a SOIC clip or by desoldering it, extract the file system and analyse binaries, configuration and third-party components with their versions. Typical finding: Unencrypted firmware with private keys and passwords, plus libraries with years-old public vulnerabilities.
Processor and secure boot (OWASP IoT I4 · I5): We review the secure boot chain and hardware key protection and, when in scope, test fault injection (glitching) and side-channel attacks. Typical finding: Secure boot disabled or misconfigured: the device runs any firmware it is given.
Radio: Wi-Fi, BLE, Zigbee (OWASP IoT I2 · I7): We capture and analyse wireless communications: BLE pairing and GATT characteristics, Zigbee, Z-Wave or LoRa networks, key reuse and message replay. Typical finding: BLE characteristics writable without pairing, letting anyone nearby unlock, switch on or reconfigure the device.
Network services (OWASP IoT I2 · I9): We review the services the device exposes on the local network and the internet: web panels, Telnet, SSH, UPnP, MQTT or forgotten debug ports. Typical finding: Telnet or a web panel with default credentials, the same on every unit.
Companion mobile app (OWASP IoT I3): We test the app that sets the device up using the OWASP MASVS methodology: storage, communications and how a device is onboarded and linked to an account. Typical finding: The app stores the device key in clear text or lets anyone link someone else's device just by knowing its serial number.
Vendor API and cloud (OWASP IoT I3 · I8): We test how each device authenticates to the cloud, tenant isolation, and the MQTT brokers or APIs that receive telemetry and send commands. Typical finding: One certificate for the whole fleet or MQTT topics with no access control: one device sees everyone's data.
OTA updates (OWASP IoT I4): We check how an update arrives and is verified: signature, encrypted channel, rollback protection and behaviour when an update fails halfway. Typical finding: Unsigned updates or updates served over HTTP: a tampered update installs and survives reboots.

Attack chain

UART console with a root shell: With a USB-serial adapter on the board's pads, the console shows the boot process and U-Boot can be interrupted: changing the boot arguments gives a root shell with no password.
SPI flash dump: A SOIC clip on the memory chip and a programmer read the 16 MB of firmware without desoldering anything. It is not encrypted: the whole file system comes out.
Secrets inside the firmware: The file system holds the device's private key —the same across the batch— and the root password hash, stored with an obsolete algorithm.
Impersonating the device to the cloud: With the extracted certificate, the vendor's MQTT broker accepts the connection and allows subscribing to every device's topics: the entire fleet's telemetry.
Unsigned update: The update server delivers firmware over HTTP and the device only checks a hash sent by that same server: a tampered version would install and persist.

Illustrative chain built from findings that are common in this kind of assessment; it does not describe a specific device or manufacturer. The terminal output is an example.

What an IoT penetration test covers

Hardware reconnaissance: identifying components, datasheets, traces and test points on the board
Debug and internal communication interfaces: UART, JTAG, SWD, SPI and I2C
Firmware extraction and analysis: memory reads, file system, binaries, embedded secrets and third-party components (SBOM)
Secure boot, key protection and, when in scope, fault injection and side-channel attacks
Wireless communications: Wi-Fi, Bluetooth Low Energy, Zigbee, Z-Wave, LoRa and proprietary protocols
Device network services: web panels, Telnet, SSH, UPnP, MQTT and CoAP
Companion mobile app, following OWASP MASVS
Vendor cloud APIs and brokers: device authentication, tenant isolation and remote commands
OTA update mechanism: signature, channel, rollback protection and recovery
OT/ICS environments: assessment against IEC 62443 and segmentation by Purdue Model levels

Methodology

Scope and threat model: We agree which layers are in scope (hardware, firmware, radio, app, cloud), how many units are available and which attacker is simulated: someone on the network, someone nearby with a radio or someone with the device in hand.
Device reconnaissance: We open the unit, identify components and test points, and map interfaces, protocols and services. Non-destructive work comes first.
Firmware: We extract the firmware by the least invasive route possible and analyse the file system, binaries, configuration, embedded secrets and components with known vulnerabilities.
Communications and ecosystem: We capture radio and network traffic and test the companion app, the cloud API and the update mechanism, which is where a flaw becomes a fleet-wide problem.
Exploitation and attack chains: We chain findings together to show the real impact: from the board to the cloud, or from the device into the corporate network or the control system.
Report and retest: We deliver every finding with a proof of concept, severity and a recommendation for the firmware and backend teams, mapped to the OWASP IoT Top 10, EN 18031 and IEC 62443, and we verify the fixes.

Deliverables

Executive report with the risk to the product and the fleet, prioritised
Technical report with a proof of concept for each vulnerability and steps to reproduce it
Map of the device's attack surface: interfaces, services, protocols and ecosystem
Findings classified by the OWASP IoT Top 10, with references to the applicable EN 18031 or IEC 62443 requirements
Inventory of third-party components found in the firmware, with their known vulnerabilities
Remediation recommendations for hardware, firmware, communications and backend
Retest of the fixes and support for the manufacturer during remediation

Use cases

Manufacturers that need security evidence before launching a product or for their Radio Equipment Directive or Cyber Resilience Act technical file
Companies that integrate third-party devices (cameras, controllers, sensors) and want to know what they are putting on their network
Industry with PLCs, SCADA or OT networks connected to the corporate network
Critical infrastructure operators: energy, water and transport
Manufacturers and hospitals with connected medical devices
Home automation, smart locks and building management systems (BMS)
Hardware startups that need to pass a customer or investor due diligence

What each approach covers

Many "IoT pentests" stop at the network or the app. What you see, and what you miss, depending on how far the test goes.

	Network scanner	App and API pentest	Full IoT pentest
Debug ports (UART, JTAG)	No	No	Yes, in the lab
Firmware and embedded secrets	No	Only what the app exposes	Full extraction and analysis
Radio (BLE, Zigbee, LoRa)	No	Partial	Capture, pairing and replay
Vendor app and cloud	No	Yes	Yes, chained with the above
OTA updates	No	Partial	Signature, channel and rollback
Evidence for EN 18031 and the CRA	Minimal	Partial	Findings mapped to the requirements

Compare with

IoT penetration testing FAQ

Do you need physical access to the device?

For a full test, yes. The cloud API, the mobile app and network communications can be tested remotely, but hardware and firmware analysis needs the device in our lab.

How many units do you need?

Ideally two or three: some hardware tests may require desoldering components or may leave a unit unusable. If there is only one, the plan starts with non-destructive techniques and any step that could damage it is agreed with you first.

Do you need the firmware or the source code?

It's not essential: extracting the firmware from the board itself is part of the test, because that's what an attacker would do. If you provide it, along with schematics or code, the analysis goes further in the same time.

What does the Radio Equipment Directive require of a connected device?

Since 1 August 2025, Delegated Regulation (EU) 2022/30 requires radio equipment that connects to the internet, and some that processes personal data or enables payments, to meet cybersecurity requirements. The EN 18031-1, -2 and -3 standards are the route to a presumption of conformity. A penetration test provides technical evidence that those requirements are actually met, beyond the paperwork.

And the Cyber Resilience Act?

The CRA applies to almost any product with digital elements sold in the EU. From 11 September 2026 manufacturers must report actively exploited vulnerabilities to ENISA, and on 11 December 2027 it becomes fully applicable, with requirements for security by design, vulnerability handling and updates throughout the product lifetime.

Can you run the test without affecting industrial production?

Yes. In OT environments we work with the plant team to set maintenance windows, favour passive techniques and run the most invasive tests on spare equipment or a test bench, never blindly against a live process.

Can the report be used in the product's technical file?

Yes, as evidence of security testing: each finding states what was tested, how, the result and the reference to the relevant standard, and the retest documents that the fixes work. The conformity assessment itself is carried out by the manufacturer or, where required, a notified body.

How long does an IoT penetration test take?

It depends mainly on how many layers are in scope (hardware, firmware, radio, app, cloud) and how many units there are. We set it in the proposal, with fixed scope and price, after a first call in which we look at the device and its ecosystem.

Regulation for manufacturers

Hardware analysis series

Industry and real cases

Sources

Ready to protect your business?

Answer the scoping form at your own pace and we'll use it to prepare your proposal. If you'd rather talk first, book a free 30-minute call.

Scope your project · Request an IoT assessment