IoT Penetration Testing: What We Attack and What We Find

An IoT product is never just a device. It is hardware, firmware, a radio link, an app and a cloud service, and an attacker only needs one of them to be weak. An IoT penetration test looks at all of them together, because the interesting attacks usually cross the boundaries.

This is what we actually do in such a test, and what we keep finding.

The five layers we attack

1. Hardware

We open the device first. On the board we look for debug interfaces (UART, JTAG, SWD), test points and the flash chip. A serial console that drops into a root shell is still one of the most common findings in the field.

If the debug port is locked, we try to get the firmware another way: reading the flash chip directly, or glitching the processor into skipping a check.

2. Firmware

With the firmware extracted, we unpack it and read it. Typical questions:

• Are there hard-coded passwords, API keys or private keys?
• Which open-source components are inside, and how old are they?
• Is there a secure boot chain, and does every stage really verify the next one?
• How are updates checked? Signed, or just compared against a checksum?

3. Radio and local interfaces

Bluetooth LE, Wi-Fi, Zigbee, Thread, LoRaWAN or a proprietary sub-GHz link: we capture the traffic, replay it and change it. Pairing is a favourite target, because many devices accept anyone who asks at the right moment.

4. App

The companion app often knows more than it should. We decompile it, look for secrets and watch how it talks to the device and the cloud.

5. Cloud and APIs

Here we test whether one customer can reach another customer’s devices. Broken access control on device IDs is the classic: change one number in a request and you control someone else’s product.

What we find most often

Finding	Why it matters
Open debug console (UART/JTAG)	Full control with physical access, and a fast way to the firmware
Hard-coded credentials or keys in firmware	One extracted device compromises the whole fleet
Unsigned or weakly verified updates	An attacker can install their own firmware
Outdated components with known vulnerabilities	Public exploits work out of the box
Pairing without real authentication	Anyone nearby can take over the device
Cloud API trusts the device ID	Access to other customers’ devices and data
Same default password on every device	Mass compromise from the internet

None of these need exotic techniques. They need someone who looks.

How a test runs

1. Scoping call. Fifteen minutes to agree on the device, its interfaces and the depth of the test.
2. Teardown and firmware. We get inside the device and extract what runs on it.
3. Attack. Hardware, radio, app and cloud, and then the combinations between them.
4. Report and debrief. Every finding with proof-of-concept, severity and a fix, explained to your engineers.
5. Retest. We check that the fixes hold.

How to prepare

• Send at least two devices. One may not survive.
• Provide a test environment in the cloud, separate from production.
• Give us firmware images and documentation if you have them. It saves days.
• Name one engineer who can answer questions quickly.

Why now

Since 1 August 2025 the cybersecurity requirements of the Radio Equipment Directive apply to wireless devices, and from December 2027 the Cyber Resilience Act applies to almost everything with digital elements. Both expect that products are tested before they ship.

Want to know how your device holds up? See our IoT security testing or get a pentest quote.