How to buy an IoT pentest: scope, handover and what the proposal must say

Define the scope before you send the brief

An IoT pentest is not a single engagement with a fixed scope. Before a tester can quote the work, you need to decide which of the four attack surfaces are in scope: the device firmware, the physical hardware interfaces, the radio protocols the device uses, and the cloud or API backend it connects to. Each surface requires a different skill set and a different set of test cases. A brief that says 'test our device' is too open to quote accurately or run safely.

Firmware covers the OS, the application layer, the boot chain and any persistent credentials baked in at manufacture. Hardware interfaces include JTAG, UART, SPI and I2C, which give a tester either a debugging channel or direct flash access. Radio covers Bluetooth Low Energy, Zigbee, Z-Wave and proprietary RF protocols the device uses to communicate locally. The cloud side covers the API the device calls home through, the provisioning flow and the device management console. The article How an IoT pentest is run maps each surface to the techniques a tester will use.

A complete scope statement names each surface, the firmware version under test, the device model and revision, the cloud environment in scope (production, staging or a dedicated test tenant), and which test cases are excluded. Exclusions matter: a tester running fuzzing against a production provisioning endpoint can affect live devices. If staging does not exist, document the constraints and agree them before the engagement letter is signed.

What to hand over before the engagement starts

An IoT pentest is not a standalone penetration testing exercise in the way a web application or infrastructure test is: the physical artefacts you provide shape what is testable. The quality of what you hand over directly determines how much of the engagement time is spent finding the test surface rather than testing it. At minimum: one or more physical devices with debug interfaces accessible, a copy of the current firmware image, architecture documentation showing the device's communication flows, and credentials or API keys for the cloud environment you have agreed to include in scope.

For firmware, hand over the version you want tested, not the latest candidate build unless that is the agreed target. If you can supply a debug-enabled build, do so: a firmware image without accessible JTAG or UART takes longer to analyse because the tester has to extract the filesystem from flash directly. Cloud access should be scoped to the environment and the principal the tester needs, typically a test tenant with device provisioning rights, not production admin credentials.

Architecture documentation does not need to be a formal specification. A network diagram showing what the device calls, which backend services it authenticates to, and what protocol each call uses, is enough to let the tester build an attack model before picking up the hardware. The companion mobile application, if one exists, is a separate mobile app pentest engagement costed separately. State whether it is in or out of scope when you send the brief.

What a proposal must state about methodology

A proposal that lists 'firmware analysis, hardware testing, radio testing, cloud API testing' without saying how each will be approached tells you nothing about whether the team can run the engagement. For firmware, the methodology should name whether static analysis, dynamic analysis or both will be used, and which tooling. For radio, it should name the protocols in scope and the equipment the tester will bring, not generic capability claims.

A capable IoT pentest requires a team with at least three overlapping skill sets: embedded systems and firmware engineering, radio frequency testing including hardware and protocol analysis, and cloud or API security. A team strong in web application security but with only one firmware specialist will run out of depth quickly on a device with a complex boot chain. The proposal should name the individuals who will do the work and describe their background in each area, not just list tools or certifications.

The methodology should also reference an established testing standard. NIST SP 800-115 defines the technical methodology for security testing and is the basis most structured engagements build from. For the adversarial modelling layer, MITRE ATT&CK provides the technique catalogue an experienced tester will map findings against. A proposal that references neither is not necessarily weak, but ask what framework the team is using and why.

Three questions that reveal a team's IoT capability

Three questions tell you more about a team's IoT capability than any certification list. First, what is their process for extracting a filesystem from a locked device? A tester with real firmware experience will name a specific technique: binwalk for a known filesystem format, QEMU for emulation, or a direct SPI flash read-out depending on the device class. The technique matters because a locked production unit is the normal case, not an edge one.

Second, what radio equipment will they bring? An engagement covering Bluetooth Low Energy and Zigbee requires a BLE sniffer, a Zigbee analyser and the associated tooling for protocol replay. Ask the team to confirm they own or have access to the hardware for the protocols your device uses. Third, who handles the cloud side? If the team routes cloud testing through a web application team, verify that those individuals have worked on device-to-cloud APIs, not just browser-facing applications.

The infrastructure pentest skill set overlaps with the network layer of the cloud backend, and the API pentest skill set covers the device API surface, but neither alone covers the embedded and radio layers. A capable IoT team draws on all three, and the proposal should show how those skills are distributed across the engagement rather than naming a single generalist to cover all four surfaces.

What the report must contain to be usable

A finished IoT pentest report should contain findings written to the level of detail needed to reproduce each one: the firmware version tested, the hardware revision, the tool or technique used, the exact command or sequence of steps, and the response that confirms the finding. A finding documented as 'weak firmware encryption' without the cipher, the key size or the supporting evidence tells the development team nothing they can act on. Each finding should identify the component it affects: firmware, radio, hardware interface or cloud backend.

Risk ratings should follow a defined scoring scheme. CVSS from FIRST is widely used and gives a reproducible numeric score that a development team can rank against other findings without needing to interpret prose. Beyond the score, each finding should carry a remediation recommendation specific to the technology: 'upgrade the TLS version on the provisioning endpoint' rather than 'improve encryption'. The remediation advice is the part of the report a development team will use most directly.

The report should also carry a test coverage summary that maps what was tested against what was in scope. If a radio protocol was de-scoped during the engagement because the device revision handed over did not support it, that fact should be in the report, not assumed to be understood. Any finding that surfaced in monitoring during the pentest should be cross-referenced with the tester's record to confirm it was documented and rated consistently.

IoT security testing in the UAE: which regulator applies

IoT security testing in the UAE sits within several regulatory frameworks depending on the sector deploying the device. The UAE Information Assurance Regulation, published under TDRA, sets baseline security requirements for government entities and critical infrastructure operators, which includes connected hardware deployed in smart city initiatives and building management systems. Organizations subject to this regulation should treat IoT security testing as part of their periodic assessment programme. The UAE rules that apply to IoT security testing maps each of the four main UAE regimes to the relevant device security obligations in detail.

In Dubai, the DESC framework applies to government entities and their direct suppliers. Any supplier providing connected hardware into a Dubai government environment should expect IoT security testing to be part of the compliance evidence required. In Abu Dhabi, ADHICS covers healthcare entities including hospitals and clinics: connected medical devices fall within its device security controls, and a pentest report is the standard evidence for any finding on a device connected to the clinical network. CBUAE requirements for banks and financial institutions extend to connected infrastructure, and a bank deploying IoT-class hardware on its network should assess it against the same standard it applies to other networked assets. Both Abu Dhabi and Dubai are expanding smart infrastructure at scale, and procurement teams buying connected devices for public or regulated environments should build IoT security testing into the vendor qualification process rather than commissioning it after deployment.

Frequently asked questions