What an IoT pentest report must contain

Why an IoT report has more structure than a network pentest report

A network pentest report has one surface: the hosts the tester reached, the services they ran and the vulnerabilities those services exposed. An IoT pentest report has four. Firmware, radio interfaces, physical hardware ports and the cloud backend each produce a distinct class of finding, and the evidence for each looks different. A firmware vulnerability is a binary with a hardcoded secret or an outdated library. A radio finding is a captured packet and a replay command. A hardware finding is a JTAG session log. A cloud finding looks exactly like an API pentest finding, because it is one.

The structure of the report needs to reflect this. A flat list of findings that does not group by surface makes remediation harder: the team that patches firmware is not the team that fixes the API gateway, and a single unorganised list means both teams read everything to find what belongs to them. The sections that follow describe what each surface must contribute to the final report, what evidence is required for each finding class and what the retest section must confirm before the engagement closes.

Firmware findings: secrets, components and boot configuration

Firmware findings divide into three groups: hardcoded credentials and secrets, vulnerable software components, and insecure boot configuration. Each has a different owner and a different fix path, so the firmware section of the report is usually the longest and the one that generates the most parallel work across teams.

Hardcoded credentials are the most common finding in this class. Binary analysis extracts the filesystem, and searches over configuration files, startup scripts and compiled strings find passwords, API keys and private certificates baked into the build. As covered in how an IoT pentest is run, the tester captures these during the firmware extraction phase. The evidence for a hardcoded credential finding is the file path, the extracted string and the command used to locate it. The report must also state whether the same credential appears in the cloud backend, because a firmware secret that also authenticates to the cloud API is a critical finding, not a medium one.

Outdated software components are reported at the library or package level, not at the firmware image level. The report lists the component name, its version, the CVE identifiers that apply and the CVSS score for each, following the evidence structure described in NIST SP 800-115. Boot configuration findings state whether secure boot is enabled, whether the bootloader is locked and whether an attacker with physical access can interrupt the boot sequence to gain a root shell or extract the filesystem without the normal authentication path.

Radio and hardware interface findings: evidence the report must carry

Radio findings require captured traffic as evidence. A Bluetooth Low Energy finding includes the raw advertisement or GATT packet dump, the tool and frequency used to capture it, and the replay command that demonstrated the vulnerability. A Zigbee or Z-Wave finding includes the plaintext network key if it was extracted, the capture file and the commands that replayed the frame. Without the capture, there is no evidence the vulnerability is real rather than theoretical, and a remediation team cannot confirm the fix without it.

Hardware interface findings cover JTAG, UART and SPI. A UART finding is a console session log showing what access the interface gave: a root shell, a bootloader prompt or a debug menu that exposes device configuration. The report includes the pin layout, the baud rate and settings used, and a full transcript of the session. For JTAG, the log shows whether code execution was achieved, whether memory was readable and whether the secure boot configuration could be bypassed. Both classes of finding need a clear statement of what an attacker with physical access to the device could accomplish with that access.

Physical findings are sometimes absent from reports that otherwise cover firmware and radio in detail. What your monitoring should catch during an IoT pentest describes the detection signals the hardware attack phase generates. The final report must match those signals to the findings that produced them, so the organisation can confirm which of its controls fired during the test and which did not.

Cloud and API findings: device identity and what the backend validates

The cloud component of an IoT pentest produces findings that map to the API pentest methodology: broken object-level authorisation, excessive data exposure, missing rate limiting and weak token handling. The tester works through the OWASP Testing Guide framework applied to the device's backend, but the attack path is different. API traffic is captured directly from the device, which means the tester can see what the device sends, replay and modify it, and test whether the cloud backend validates device identity properly.

Device identity is the finding class specific to IoT. The report needs to answer whether the cloud endpoint verifies that a request came from an enrolled device, or whether any client holding a valid API key succeeds. It also needs to test whether the platform allows one device to query or modify the data of another. These questions do not arise in a standard API test and need their own section. The evidence is a modified request, the server response that proved the control was absent and a note on which device identity was impersonated. How to buy an IoT pentest covers how to include the cloud backend in the scope so these findings are authorised before the test begins.

Severity ratings and the evidence standard for each finding

Severity ratings on IoT findings must account for physical context. The same firmware vulnerability rates differently in a medical device than in a consumer speaker, not because the vulnerability changes but because the blast radius does. CVSS base scores are the starting point; the report must carry the environmental score adjusted for the deployment context the organisation supplied at scoping. The UAE rules that apply to IoT security testing describe which regimes require documented risk ratings: a report without environmental scores may not satisfy a CBUAE or DESC audit requirement.

The evidence standard for IoT findings is higher than for a network test because the findings are less familiar to most remediation teams. A finding is not evidenced by tool output alone. For every finding, the report needs: the observation, the method used to find it including the tool and command, the evidence file or capture, and the reproduction steps. A finding without reproduction steps cannot be retested, and a retest that cannot be reproduced is not a closed finding.

The retest section: what closed means for each surface

The retest section is the part of the report that a regulator or penetration testing buyer reads to confirm whether the engagement is closed. For an IoT engagement, it confirms which findings were addressed, how the fix was verified and what residual risk remains. A firmware finding fixed in the next build is retested on that build, not on the original. A radio finding addressed by changing the encryption scheme is retested against the new configuration. Retesting the original device after a firmware update does not close a firmware finding: the test must confirm that the updated firmware was examined.

The retest section also identifies findings that were accepted rather than fixed. An organisation may accept a UART debug interface on a device that never leaves a physically secured room, but the report needs to record that decision: what the finding was, what the risk is, who accepted it and why the compensating control is considered adequate. A retest section that states only that all findings were remediated without per-finding confirmation does not close the engagement and will not satisfy a formal audit requirement.

IoT pentest reporting in the UAE context

In the UAE, IoT devices are deployed across sectors that fall under multiple regulatory regimes. A connected medical device in an Abu Dhabi hospital must meet ADHICS requirements under the Department of Health, which includes documented evidence of security testing and remediation. A connected device supplied to a Dubai government entity or its contractors falls under the DESC framework, which requires that third-party security assessments produce reports that evidence both the findings and their resolution.

CBUAE regulated institutions in both Abu Dhabi and Dubai that use IoT devices in payment processing or customer data handling face additional requirements under the CBUAE Technology Risk Management guidelines. For these institutions, a pentest report that lacks environmental severity scores or per-finding retest confirmation may not satisfy an audit. The UAE Information Assurance Regulation, applicable across federal entities, also requires that security assessments produce actionable remediation records.

Procurement teams in both emirates should confirm before signing an engagement that the report format the provider uses covers all four surfaces and carries the evidence standard described here. A report that documents firmware findings only, or that groups all findings without surface-specific evidence, may need to be supplemented at retesting, which adds cost and time to the remediation cycle. The four-surface structure is not a preference: it reflects the attack surface that an assessed device actually presents.

Frequently asked questions