IoT pentest or embedded pentest: what are the differences?
“We want an IoT pentest of our product.” Behind this request, two customers almost never expect the same thing. The first wants to know whether the firmware can be extracted from their board. The second wants to know whether an attacker can take over their entire fleet from the cloud.
Both requests are legitimate. They call for neither the same tools, nor the same skills, nor the same budget. Confusing them when scoping is the leading cause of disappointing audits.
Two scopes, one boundary
An embedded pentest focuses on the device itself. The auditor holds the object, opens it, and looks for what an attacker with physical access can get out of it.
An IoT pentest focuses on the device within its ecosystem. The equipment is only one link among others: radio link, gateway, mobile app, API, cloud platform, update mechanism.
The boundary is not watertight. A secret extracted from the firmware (embedded pentest) is often an entry point to the cloud (IoT pentest). That is exactly why you need to know where to set the cursor.
The embedded pentest: the device on the bench
What is tested
- Debug interfaces. A UART port left enabled, or an unlocked JTAG or SWD, gives access to a console, the memory or the complete firmware. See our article on exposed UART.
- Internal buses. I2C and SPI often carry cleartext exchanges between the microcontroller and a memory, a sensor or a security component.
- Storage. Direct reading of a flash memory or an EEPROM, with or without desoldering.
- Firmware. Extraction, static analysis, secret hunting, verification of the signature and the boot chain. See Secrets in the firmware: three flaws, one root cause.
- Hardware protections. The microcontroller’s read protection level, secure boot, resistance to glitching for the most sensitive targets.
The toolkit
Multimeter, logic analyzer, USB-to-serial adapter, debug probe, memory programmer, soldering station. On the software side, extraction and reverse engineering tools.
The profile
An auditor comfortable with electronics, who reads a datasheet, spots a component on a board and understands a microcontroller architecture.
The IoT pentest: the device within its ecosystem
What is tested
- Radio links. Bluetooth Low Energy, Wi-Fi, LoRaWAN, Zigbee, proprietary protocols. Pairing, encryption, replay, spoofing. See our article on Bluetooth Low Energy weaknesses.
- Application protocols. MQTT, CoAP, HTTP. Broker authentication, topic isolation, transport encryption.
- Cloud and APIs. Tenant isolation, predictable identifiers, exposed tokens, escalation from one device to the whole fleet.
- The mobile app. Local storage, embedded secrets, communication with the device and with the cloud.
- Updates. Authenticity and integrity of distributed firmware, possibility of rolling back to a vulnerable version.
- Enrollment and lifecycle. Identity provisioning, revocation, factory reset, resale of a device.
The toolkit
Radio capture dongles, software-defined radio, interception proxy, API testing tools, mobile analysis environment.
The profile
An auditor able to move from a radio capture to an API request, and to connect a local weakness to an impact on a whole fleet.
The comparison
| Embedded pentest | IoT pentest | |
|---|---|---|
| Question asked | What can be obtained from a device you own? | What can be done to the system from an entry point? |
| Scope | Board, components, firmware | Radio, gateway, mobile, API, cloud, updates |
| Attack assumption | Physical access to the device | Within radio range or remote |
| Typical impact | Theft of secrets, cloning, tampering with a device | Mass compromise, data leak, remote takeover |
| Customer prerequisites | Several units, some of them expendable | Test environment, accounts, data flow documentation |
| Dominant skill | Electronics and reverse engineering | Radio, web and architecture |
Which one to choose?
Your product is deployed in publicly accessible places or resold second-hand. Start with embedded. An attacker will have the device in hand, and any secret shared between units becomes a risk for the entire fleet.
Your main risk is a remote attack on the whole fleet. Start with IoT, especially the cloud, the APIs and the update process.
You are preparing a product launch subject to the Cyber Resilience Act. Both are needed. The essential requirements cover device protection as much as the security of updates and communications.
Your budget only allows one audit. Have the scope defined by someone who masters both. An embedded audit that ignores the cloud, or the other way around, gives a reassuring and false picture.
In every case, four points must appear in the specification: the exact scope, the number of devices provided, the level of information given to the auditors, and the skills expected from the people involved.
Train and get certified
The last point is the hardest to check. An experienced web auditor is not automatically at ease in front of a printed circuit board, and an electronics engineer is not necessarily at ease in front of an API.
This is why the new DVID certification path offers, after a common core, two distinct specializations: DVID Embedded Pentest Expert and DVID IoT Pentest Expert. Both are validated by a 24-hour hands-on exam followed by a graded report, and are linked to the Penetration Tester profile of the European ECSF framework.
For details of the path, see IoT security certification: the new DVID path. For a quick reference of the techniques mentioned here, see our IoT pentest cheatsheet.
Further reading
Learn more: https://dvid.eu
Contact us: https://dvid.eu/#contact
Follow our news: https://www.linkedin.com/company/dvid/