How an IoT pentest is run: firmware, radio, hardware and the cloud side

The four attack surfaces every IoT pentest covers

An IoT pentest is not a single test run against a single target. It is a structured set of tests across four surfaces that appear in almost every connected device: the firmware that runs on the processor, the radio protocols the device uses to communicate, the physical hardware interfaces that service engineers and, sometimes, attackers can reach, and the cloud or mobile infrastructure the device reports back to.

The surfaces interact. A cloud vulnerability can be reached from the device through its API. A UART console can produce the keys that unlock the firmware. A firmware flaw can open the cloud account. A tester who stops at one surface misses the paths that cross between them. The engagement scope and the test order are agreed at the start so that findings on one surface can inform the work on the next.

The right starting point depends on what the vendor can supply. If current firmware is available for download, analysis starts there. If the device is sealed and the firmware is not published, hardware extraction or traffic capture comes first. Either way, the penetration testing scope document names which surfaces are in, which are out, and what constitutes a finding on each.

Firmware: acquiring and analysing the binary

Firmware analysis begins with acquisition. For devices that publish update packages, the binary is downloaded directly. For sealed devices, acquisition goes through the hardware: a SPI or NAND flash chip is read with a clip-on programmer, or the bootloader is interrupted over UART to dump the flash contents. In some cases the firmware arrives as network traffic, served from an unsecured update channel or a vendor cloud endpoint that requires no authentication to download.

Once acquired, the binary is unpacked. Most embedded firmware images are packaged with Squashfs, JFFS2 or a vendor-specific container; binwalk extracts the filesystem. The extracted tree is searched for hardcoded credentials, API keys, private keys, weak cipher configurations and references to internal services. A string search for patterns such as password, secret, BEGIN PRIVATE KEY and RFC 1918 addresses produces the first set of leads. The OWASP IoT Project defines firmware analysis as the primary attack surface and specifies the test cases a tester should work through.

Dynamic analysis runs the firmware in an emulation environment or on a spare unit to observe the process at runtime. qemu-user emulates common architectures; tools such as firmwalker automate the extraction and search steps. A firmware finding at this layer often reaches the cloud directly: a private key embedded in the binary can authenticate to the vendor's device management platform as any registered device.

Radio and wireless: what the device is transmitting

Most consumer and industrial IoT devices communicate over a short-range radio protocol: Bluetooth Low Energy (BLE), Zigbee, Z-Wave, Thread or a proprietary sub-gigahertz band around 433 MHz or 868 MHz. A tester needs equipment suited to the device's operating frequency. For BLE, a standard Bluetooth adapter running btlejuice or gattacker is enough. For Zigbee or proprietary protocols, a software-defined radio receiver such as a HackRF or RTL-SDR dongle captures raw packets for analysis.

The test checks whether the pairing process can be observed and replayed, whether the protocol carries a non-expiring session token, whether commands can be injected without completing the pairing handshake, and whether the link key was transmitted in the clear during provisioning. BLE in particular has a history of pairing modes that transmit the link key unencrypted: a device that completed pairing in a shared space may have exposed its key to any passive listener.

Radio findings connect to the cloud side. A device that accepts replayed commands can be driven by anyone who can relay the packet. A protocol that uses a device-unique identifier as command authorisation creates a path from the radio layer to the device management account, because the same identifier often appears in the cloud API without additional verification.

Hardware interfaces: JTAG, UART and the debug ports left open in production

Most embedded systems include hardware debug interfaces used during development and testing. UART (Universal Asynchronous Receiver-Transmitter) is the most common: a three-pin or four-pin header on the PCB that provides a serial console, often with root shell access and no authentication required. JTAG (Joint Test Action Group) is a boundary-scan interface that allows a debugger to halt the processor, read registers and step through instructions; it is the standard route to extracting firmware from a chip that cannot be read any other way.

Locating these ports on an unfamiliar PCB is a standard step. A multimeter and an oscilloscope identify the UART pins by their idle voltage and activity pattern. A logic analyser or a baud-rate brute-force tool determines the correct speed. Once connected, the device typically responds with a boot log and a login prompt; on development firmware, or firmware shipped without disabling the debug build, the prompt may accept blank credentials or a well-known vendor default. JTAG requires a probe, typically an FT2232H-based adapter, and a debugging environment such as OpenOCD to set up the connection.

Physical access requirements affect the scope. A device in a locked enclosure is harder to reach than a consumer appliance left in a communal space. The test is not purely an exercise in physical access, though: the question is whether the debug interface is present and functional in production firmware, because a device returned for warranty service, recovered from decommissioning or handled in a shared location exposes the same ports. MITRE ATT&CK documents physical access as an initial access technique under both the ICS and enterprise frameworks, and IoT engagements map their hardware findings to those technique IDs.

The cloud and mobile backend: where a single finding reaches every device

Almost every IoT device reports to a cloud platform and is controlled through a mobile companion app. These backends are tested as part of the IoT engagement because a vulnerability there can affect every device on the platform. A broken object-level authorisation flaw in the device management API can allow one registered user to read the telemetry of any other device. A missing check on the device-side endpoint can allow a device to update its own firmware record without the vendor's signature.

The cloud and API pentest work follows the same methodology as a standalone API engagement: endpoint inventory, authorisation testing by account role, token scope validation, rate limit checks and injection tests. The mobile companion app is in scope wherever it is a primary control path; if the app is the main interface to the device, a mobile app pentest runs in parallel. The combined scope is declared at the start, because testing the device without testing the cloud it trusts is testing half the attack surface.

A frequent finding is that the device uses a shared secret to authenticate to the cloud rather than a per-device certificate. A shared secret means that a compromised device exposes the credential for every device on the same platform. The firmware holding that secret can be extracted through the hardware interface covered in the previous section, completing an end-to-end chain that runs from a UART pin through the binary to the cloud account.

What to prepare before testing starts

An IoT engagement needs physical hardware. At least two production units of the device under test: one for static work and one to run live tests against, so that a hardware modification does not leave the engagement without a working target. If the device operates as part of a larger system, the test environment should include any pairing device, gateway or hub that sits between the device and the cloud. Firmware binaries for all versions currently deployed should be provided, because a vulnerability patched in the latest release may still be present on devices that have not received the update.

Cloud access is needed in a non-production environment that mirrors the production configuration. A sandbox where test devices can register, receive commands and report telemetry without reaching real users is the standard arrangement. If the cloud environment cannot be replicated, the scope document records what was not tested and what residual risk that creates. NIST SP 800-115 sets out the technical planning baseline for security test engagements; the scoping structure for an IoT engagement follows that same framework, extended to cover the four surfaces described above.

The scoping call covers which radio protocols are in scope, whether physical access to the PCB is authorised, what firmware versions are current, and which cloud regions are in scope. An infrastructure pentest of any on-premise components, such as a local gateway or management server, may run alongside the device work if those components are in scope. An OT/ICS pentest is a separate engagement when the device connects to industrial control systems rather than a consumer or enterprise cloud platform.

IoT security testing in the UAE market

The UAE has seen rapid IoT deployment across smart city infrastructure, healthcare facilities, financial services and building management. Abu Dhabi's smart city programmes and Dubai's infrastructure initiatives have connected large numbers of devices to managed platforms, many running embedded firmware that predates current security standards. These devices sit alongside regulated systems: ADHICS in Abu Dhabi healthcare, CBUAE for financial institutions and DESC for Dubai government entities and their suppliers.

None of the four UAE regulatory regimes that address cybersecurity testing name IoT pentest as a specific requirement in the way they name penetration testing or red teaming. However, the general obligation to secure systems that process personal data or handle regulated transactions applies to connected devices on those networks. A CBUAE-regulated institution operating IoT payment terminals or access control devices is expected to demonstrate that those devices are tested as part of its overall security programme.

Procurement in Abu Dhabi and Dubai for regulated deployments now routinely requires evidence of security testing before deployment approval. A vendor supplying devices to a Dubai government entity covered by DESC, or to an Abu Dhabi healthcare provider covered by ADHICS, may be required to present a test report as part of the technical evaluation. The IoT pentest report is the document that satisfies that requirement, provided it covers the cloud backend and the device firmware as well as the physical unit.

Frequently asked questions