IoT Pentest (IOT VAPT)

An IoT pentest covers five surfaces: the firmware, the hardware interfaces on the board, the radio protocols, the mobile companion app and the cloud backend they all talk to.

Firmware

Extracted and unpacked for embedded credentials, keys, certificates, debug functionality, cryptographic use and unsafe update handling.

Hardware interfaces

UART, JTAG, SWD, SPI flash and any populated header or test pad left on a production board. Populated headers and readable flash are the most common way in.

Radio

Pairing, authentication, replay, interception and range on whichever protocol the device uses.

Companion app

The mobile application that pairs and controls, tested as a full mobile assessment.

Cloud backend

Device identity, credential scope per unit, the provisioning flow and the fleet management API.

Testing any one alone misses the point, because the interesting attacks cross the boundaries between them.

An IoT pentest needs two or three units of the same model, shipped to our lab.

Hardware work can be destructive, and having a spare means a bricked unit does not end the engagement halfway through. One unit takes the hardware work, and an intact unit is needed for radio, local network and companion app testing against a device that still behaves normally.

Send them with whatever documentation you can: schematics, a firmware image, the provisioning procedure and test accounts on the backend. Each one shortens the time spent discovering and lengthens the time spent testing.

An IoT pentest may destroy one device, and we tell you at scoping which steps carry that risk before taking any of them.

Chip-off flash reading and some probing are destructive by nature. Desoldering a flash chip to read it, or lifting a pad to reach a test point, cannot be undone. We do not take those steps without your agreement, and we try the non-destructive routes first: a populated UART or JTAG header, an in-circuit read of the flash, or an update image obtained from the backend.

Physical possession is the threat model, so what a destructive step yields matters even if you would rather we did not take it. If a key comes out of the flash, an attacker with a soldering iron gets the same key.

Yes, an IoT pentest includes the cloud backend and the mobile companion app, and it should, because the most consequential findings only appear when they are tested with the device.

Cloud backend

The most consequential IoT finding we report is a device credential scoped to the whole fleet rather than to one unit. It is only visible when a credential pulled from one device is tried against the API on behalf of another. Provisioning, device identity and the fleet management API are tested as part of the same engagement.

Companion app

The mobile app is tested as a full mobile assessment within the same engagement. It is usually where pairing secrets and backend credentials are handled, so excluding it leaves a large gap. Its own storage, transport and backend are in scope.

An IoT pentest covers BLE, Zigbee, Z-Wave, LoRa and proprietary sub-GHz radio.

For each protocol we test pairing and authentication, replay, interception and range. The typical finding is not a broken protocol but a device that accepts a pairing it should have refused, or a command that can be recorded and played back without the key.

If your device uses something unusual, tell us at scoping so we can confirm we have the hardware for it, instead of discovering that mid-engagement. Range is tested because an attack that needs the attacker in the room is a different finding from one that works from the street.

No, secure boot on its own is not enough to pass an IoT pentest, though it raises the bar considerably and it is worth having.

What we test is whether it is actually enforced in the shipped configuration, whether rollback to an older signed image with a known flaw is possible, and whether debug paths bypass it. Available and enabled are different things, and a board with secure boot left unenforced and a populated JTAG header has neither.

The update path is tested alongside it: whether an update is signature-verified, whether the verification can be skipped, and whether an unsigned image can be made to run.

An IoT pentest typically takes three to four weeks including firmware, hardware, radio, the backend, the companion app and reporting.

Unfamiliar architectures or heavy obfuscation extend it, because time then goes into reverse engineering instead of into findings. A firmware image and schematics supplied at the start have the opposite effect.

Lab time and shipping are part of the plan. Devices come to us, and the timeline starts when they arrive, not when the order is signed. A retest of open findings once fixes land is quoted up front with the engagement, so it is a known cost.

The best time for an IoT pentest is before you ship, at the design or pre-production stage.

Findings at that stage cost a firmware change. The same findings after shipping cost a recall or a fleet update, if a fleet update is even possible, and a hardware finding on a shipped product cannot be fixed in the field at all.

Shipped products are still worth testing. A device already in the field is exactly the device an attacker holds, and knowing what it yields lets you fix the backend side, which is where the fleet-wide damage would be done.

An IoT pentest assumes physical possession, because somebody will buy your device and open it, so any control that depends on them not looking is not a control.

Hardware debug ports

A populated UART or JTAG header gives a shell or a debugger on the running device. From there the filesystem, the running processes and whatever is in memory are readable, and that is often the whole product.

Firmware extraction

Readable SPI flash, in circuit or chip-off, yields the firmware image. Unpacked, it typically exposes embedded credentials, keys, certificates and the update mechanism, and a key extracted from one unit is often the key every unit uses.

The report states plainly what possession yields: whether it stops at one device, or reaches the fleet through a shared secret and the backend.

An IoT pentest is grey box by default, with documentation and a couple of units, and white box with firmware source and schematics gets materially deeper.

Black box

Devices only, as an attacker who bought one would have them. Honest but slow. The budget goes into reverse engineering, not into findings.

Grey box

Devices, documentation, a firmware image and test accounts on the backend and app. The practical default, and enough to reach the cross-surface findings that matter.

White box

Firmware source and schematics as well. Materially deeper on secure boot and update handling, because we can read what the bootloader checks instead of inferring it from behaviour.

The deliverables of an IoT pentest are findings across all five surfaces with severity and reproduction, an assessment of what physical possession yields, backend findings, and remediation split between firmware and hardware.

Firmware remediation

What a firmware update can fix: embedded secrets, unsafe update handling, exposed services, radio pairing logic and most cryptographic misuse. These can reach the fleet, if the update mechanism is sound.

Hardware remediation

What needs a board change or a manufacturing change: populated debug headers, readable flash, secure boot not enforced, and test pads. These only reach the next revision, so they are called out separately and early.

Each finding carries a named owner. Once fixes land we retest, quoted up front, and issue an attestation of what was tested and found, not a certificate.

An IoT pentest follows the same six phases as every RedTeam Security engagement, with device findings written against the OWASP ISVS and mapped to MITRE ATT&CK where a technique applies.

The UAE regimes that reach a connected device are the ones that govern the data it handles. Abu Dhabi healthcare providers under ADHICS must protect health information across its lifecycle, with testing designed so clinical availability is never at risk. Federal entities and critical national infrastructure operators evidence IAS control families through testing. Dubai government entities and their suppliers test proportionately to the information classification under the DESC ISR.

A connected device in front of patient or government data is part of the system the obligation covers, and the report is written so an assessor can follow it from scope to retest.