IoT Penetration Testing: A Practical Guide for Embedded Devices

Why IoT Deserves Its Own Methodology

A web pentest assumes one runtime, one identity model, and TCP/IP. An IoT pentest cannot assume any of those. The device may run a real-time operating system on a microcontroller with a few hundred kilobytes of flash. The firmware may be signed, encrypted, or both, or neither. The radio may be Bluetooth Low Energy, Zigbee, Z-Wave, LoRaWAN, Thread, or a proprietary sub-GHz protocol. The cloud side may be a hyperscaler IoT broker, a home-grown MQTT cluster, or a managed fleet platform. Every layer introduces a separate toolchain.

The blast radius is also asymmetric. A single device flaw might affect one customer. A single cloud authorisation flaw might affect every device shipped. Methodology has to recognise that, weight findings appropriately, and prioritise the chokepoints.

For broader programme structure, see vulnerability management programme guide and threat modelling guide.

1. Scoping an IoT Engagement

IoT scoping fails when it is treated like a web scope. A connected product has at least five distinct surfaces and the buyer rarely owns all of them outright. Lock the details down on paper.

• Device inventory: hardware revisions, SoC vendors, firmware versions, bootloader, secure element, and serial numbers of every unit shipped to the tester. Spare units matter; destructive techniques will brick boards.
• Radio surfaces: Wi-Fi, Bluetooth Classic, BLE, Zigbee, Z-Wave, Thread, LoRaWAN, NFC, sub-GHz, cellular. Specify which are in scope and the regulatory region (frequency allocations differ).
• Mobile companions: iOS and Android apps, the versions, the pairing flow, and whether the test team has access to the production backend or only a staging tenant.
• Cloud companions: APIs, MQTT/AMQP brokers, OTA update servers, fleet management consoles, third-party SaaS the device touches. Document tenancy boundaries clearly.
• Destructive scope: agree explicitly which techniques are authorised: UART/JTAG access, chip-off, decapsulation, glitching, side channel. List which units may be destroyed and the chain of custody for the rest.
• Safety boundaries: for medical, automotive, industrial, or smart-home actuators with physical effects, define what cannot be triggered and what must be done in a controlled lab only.
• Authorisation: a signed letter of authorisation, radio operation permissions where required, and named emergency contacts for both device and cloud sides.
• Deliverable expectations: report depth, retest scope, attack chain diagrams, fleet-impact statements, and ongoing portal access. Lock them in the scope of work.

2. Threat Model: Who Is the Attacker?

IoT threat actors range from opportunistic to nation-state. The plausible attacker class for the product determines which techniques are in scope and how findings are weighted.

• Opportunistic remote attacker: exploits exposed cloud APIs, default credentials, and known CVEs. Almost always in scope.
• Local network attacker: on the same Wi-Fi or LAN. Tests segmentation, mDNS/UPnP exposure, local APIs, and pairing flows.
• Proximity radio attacker: within radio range, with SDR or commodity dongles. Tests BLE, Zigbee, sub-GHz, and replay/relay.
• Owner-of-device attacker: has physical possession. Reads firmware via UART, JTAG, or SPI flash, modifies and reflashes. Common for secondary-market or rental scenarios.
• Supply-chain attacker: compromises firmware before it ships, malicious OTA, or build pipeline. Often modelled even if not directly tested.
• High-resource attacker: chip decapsulation, focused ion beam, fault injection, side channel. Reserved for high-assurance products and certifications.

OWASP ISVS and SESIP both define attacker tiers. Pick one explicitly in the scope so findings can be filtered by attacker capability.

3. Hardware Reconnaissance

Open the device. Photograph everything. The faster you map components, the faster you find debug interfaces and silicon reference attacks.

• Identify the main SoC, MCU, radio chip, secure element, and external flash by part number; pull datasheets
• Search for known reference designs, evaluation boards, and reference firmware that may share code
• Locate UART, JTAG, SWD, SPI, I2C, and any unused test pads; trace silkscreen labels with a multimeter
• Probe pads with a logic analyser at common bauds (115200, 230400, 460800, 921600) for serial output
• Check for pin-strap configuration that selects boot source (NOR, NAND, eMMC, SD, network)
• Identify reset, watchdog, and debug-disable straps that may be defeatable
• Check tamper meshes, glue, conformal coating, and epoxy as evidence of intended tamper resistance

Document every component with photographs and datasheets in the evidence pack. Hardware findings without traceability are uncomfortable to defend in retest.

4. Firmware Acquisition

Firmware in hand is the single biggest force multiplier in an IoT test. Try non-destructive methods first.

Vendor downloads

Check the vendor support portal, mobile app resources, OTA endpoints, and HTTP debug interfaces. A surprising number of vendors host unencrypted update images publicly. If so, capture the URL pattern and authentication state.

UART, JTAG, SWD

With UART access, capture boot logs and look for U-Boot or vendor bootloader prompts that allow memory dumps or boot-arg modification. With JTAG or SWD enabled, dump flash via OpenOCD or a compatible probe (J-Link, Black Magic Probe, ST-LINK). Disabled debug is common; verify by attempting connection rather than trusting datasheets.

SPI flash desolder or in-circuit

For external SPI/QSPI flash, an in-circuit clip (SOIC8, WSON8) and a flasher (CH341A, Flashrom) often dumps the chip without removing it. Where the SoC drives the same lines hard, desolder the chip. Read with the right voltage; 1.8 V parts are now common and 3.3 V flashers will fail silently.

eMMC, NAND, secure boot bypasses

eMMC reads with an SD adapter for end-points 0, 1, 2 (boot and RPMB). NAND requires bad block handling. Where secure boot blocks naive reads, look for documented vendor bypasses (Kindle, Allwinner FEL, Rockchip MaskROM, NXP SDP, Espressif download mode) and test only what is authorised.

Side channel and fault injection

Voltage glitching with a ChipWhisperer or Pico-based rig can defeat readout protection on many MCUs. Power and EM side channels can recover signing keys from naive implementations. These are advanced techniques; only run them when scope and budget justify it.

5. Firmware Analysis

With an image in hand, identify, unpack, and audit. OWASP FSTM is the canonical workflow.

• Run binwalk, unblob, and entropy analysis to identify file systems, kernels, and bootloaders
• Extract SquashFS, JFFS2, UBIFS, CPIO, romfs, and TAR archives; preserve permissions and symlinks
• Identify the kernel, libc, and userland baseline; cross-reference CVEs and supply-chain components
• Hunt for hardcoded credentials, API keys, signing keys, and TLS certificates with semgrep, trufflehog, and noseyparker
• Audit init scripts, systemd units, busybox shells, telnet/SSH defaults, and listening services
• Check shadow files for crackable hashes; treat any md5crypt or weak hashes as critical
• Locate update verification logic; identify hash, signature, version monotonicity, and rollback protection
• Diff against vendor reference firmware where available to highlight customer-introduced changes
• For RTOS images, identify the linker map, vector tables, and main control loops; reverse with Ghidra or IDA
• Attempt firmware emulation with FAT, firmadyne, or Renode for live testing of services and UI

Run the firmware review like a code review where possible. SecPortal's code scanning (Semgrep-powered SAST and SCA) supports extracted firmware repositories and userland sources, with results landing in the same findings backlog as the rest of the engagement.

6. Radio Testing

Every wireless protocol on the device is a fresh attack surface. Test each on its own terms.

Bluetooth and BLE

Map the GATT services and characteristics with nRF Connect, gatttool, or bleah. Test for Just Works pairing where Numeric Comparison or Passkey is appropriate, MITM via Sweyntooth-class issues, replay of legitimate commands, and authorisation flaws within characteristics. BlueZ tooling on Linux pairs with custom Python via bleak. Capture air traffic with an Ubertooth or nRF52840 dongle running Sniffle.

Zigbee, Z-Wave, Thread, Matter

Capture with KillerBee, ApiMote, or Texas Instruments CC2531/CC2652 dongles. Test join-key handling, network key rotation, and replay across mesh routes. For Matter, verify commissioning, certificate handling, and operational credentials.

LoRaWAN, sub-GHz, proprietary

For LoRaWAN, test OTAA versus ABP, frame counter handling, and join-server isolation. Sub-GHz proprietary protocols often demodulate cleanly with HackRF or RTL-SDR plus GNU Radio. Replay and rolling-code analysis with the Flipper Zero or YARD Stick One is cheap and surprisingly effective.

Wi-Fi and cellular

Wi-Fi: test rogue AP susceptibility, evil-twin behaviour, captive portal pairing, and credential storage. Cellular: validate IMEI/IMSI handling, modem firmware update posture, and SMS-based provisioning where present. Be careful with regulatory implications of test transmitters.

7. Mobile Companion App

The pairing app frequently holds production credentials and ships logic that the device trusts. Treat it as a first-class scope.

• Decompile APK and IPA; recover strings, embedded keys, certificate pins, and obfuscation effort
• Audit local storage: SharedPreferences, Keychain, Keystore, plist, sqlite, and unencrypted caches
• Test deep links, intent filters, app links, and universal links for unauthorised actions
• Intercept TLS traffic with Frida + objection or Charles + bypass; document any pinning
• Audit BLE pairing flows for cleartext keys, weak nonces, and broken handshake state machines
• Replay captured commands with the device offline; verify whether validation lives only in the app
• Test multi-user scenarios: factory reset, account deletion, ownership transfer, secondary user access

For a deeper mobile workflow, see the mobile application penetration testing checklist.

8. Cloud and API Backend

Most fleet-affecting findings live here. The cloud side is where one bug becomes millions of devices.

• Map every API the device calls; capture from a real device with mitmproxy or Burp through a hostile gateway
• Test authentication: device certificates, client credentials, JWT signature validation, mTLS posture
• Test authorisation by device and tenant: can device A read device B, can tenant A act on tenant B
• Validate MQTT, AMQP, or proprietary broker ACLs; test cross-device topic subscription and publish
• Test OTA pipelines: signature verification, version monotonicity, rollback, partial-update handling, mirror-and-replay
• Test fleet management consoles: RBAC, audit logging, ownership transfer, device decommission flows
• Test GDPR-relevant flows: data subject access, deletion, retention; misconfiguration here often grounds wider findings
• Verify rate limiting on enrolment, OTA, and command channels; absence enables fleet-wide DoS

For the broader API workflow, see the API security testing checklist and cloud penetration testing checklist.

9. Over-the-Air Updates

OTA is the single most consequential channel on the device. Test it deliberately.

• Verify image signing: key strength, algorithm, public key storage, anti-rollback counters, version pinning
• Test update transport: TLS posture, pinning, certificate validation, downgrade resistance
• Test for arbitrary URL injection, partial-image acceptance, and resumable-download abuse
• Probe the bootloader for fault-injection windows during signature verification (where in scope)
• Validate dual-bank or A/B update integrity; recover from interrupted updates without security regression
• Look for backdoor update channels: vendor maintenance servers, hidden keys, recovery modes that skip verification
• Confirm device telemetry on update success/failure cannot be spoofed to mask a malicious deployment

A flawed OTA channel is rarely fixed in a single release. Track findings as their own workstream with explicit retest gates in the portal.

10. OWASP IoT Top 10 Coverage

Every IoT engagement should map findings to the OWASP IoT Top 10 so buyers can compare tests over time.

11. Reporting and Remediation Tracking

IoT findings often span hardware, firmware, mobile, and cloud. A list of isolated CVSS scores hides the chain. Structure the deliverable so engineering can act on the chokepoints first.

• Executive summary with business impact, attacker class, fleet exposure, and chokepoint findings
• Per-finding evidence: hardware photographs, firmware offsets, captured radio frames, mobile decompilation, cloud HTTP transcripts
• CVSS 3.1 base scores validated using the CVSS calculator, adjusted with environmental metrics and EPSS where relevant
• Prioritisation using CVSS plus EPSS plus asset tier, with cloud-fleet impact always weighted above single-device impact
• OWASP IoT Top 10 and OWASP ISVS section mapping per finding
• Mapping to applicable regulation: ETSI EN 303 645, IEC 62443, UK PSTI, EU CRA, PCI DSS or HIPAA where relevant
• Remediation guidance distinguishing root cause from compensating control, with retest gates
• Delivery in a portal that supports retest workflows and persistent remediation status, not just a static PDF

SecPortal's findings management ships with templates that suit IoT workstreams (firmware, hardware, radio, mobile, cloud), CVSS 3.1 scoring, attachment-friendly evidence, AI-generated executive and technical reports, and a branded client portal so device, mobile, and cloud teams remediate without losing context. See the report template for the full structure.

12. Between Engagements: Continuous Posture

A point-in-time IoT pentest cannot follow firmware drift across releases. Pair the engagement with continuous controls so the next test does not surface the same drift.

• Track firmware SBOMs and re-scan with SCA on every build; treat upstream CVEs in third-party SDKs as first-class
• Integrate SAST and SCA against the firmware repository and supporting services
• Schedule recurring external scans against cloud and OTA endpoints, and authenticated scans behind device or fleet logins
• Use continuous monitoring for endpoint changes and certificate renewals; OTA endpoints quietly drift
• Run a coordinated vulnerability disclosure programme; consumer IoT regulation increasingly requires one
• Plan firmware end-of-life and security update support windows; communicate them in product documentation

For programme-level structure, see building continuous security monitoring and the vulnerability disclosure programme guide.

The Quick IoT Pentest Checklist

A condensed version to use during the engagement.

1. Lock scope to device units, radios, mobile apps, cloud APIs, OTA channels; document destructive authorisation
2. Confirm signed authorisation, radio operation permission, and named emergency contacts before any traffic
3. Photograph and inventory the board; identify SoC, MCU, radio, secure element, and external flash
4. Probe UART, JTAG, SWD, SPI test pads; capture boot logs at common bauds
5. Acquire firmware non-destructively first (vendor downloads, OTA capture, in-circuit SPI, JTAG dumps)
6. Unpack firmware with binwalk and unblob; identify file systems, kernel, libc, third-party components
7. Hunt hardcoded credentials, signing keys, and TLS material; cross-reference CVEs in dependencies
8. Audit init scripts, listening services, default users, and shadow file hashes
9. Reverse update verification logic; test signature, version monotonicity, rollback protection
10. Map and test every radio (BLE, Zigbee, Z-Wave, LoRa, sub-GHz, Wi-Fi, cellular) on its own terms
11. Test mobile companion: decompile, audit storage, intercept TLS, replay commands offline
12. Map and test cloud APIs; cover device-to-device, tenant-to-tenant, and fleet management authorisation
13. Test OTA pipeline end to end: signing, transport, rollback, partial updates, vendor backdoor channels
14. Map findings to OWASP IoT Top 10 and ISVS; weight cloud-fleet impact above single-device impact
15. Validate every destructive technique was authorised in writing; document chain of custody
16. Score with CVSS plus EPSS plus asset tier; deliver in a portal that supports retest and persistent state
17. Schedule continuous SAST, SCA, external, and authenticated scanning between assessments

Frequently Asked Questions About IoT Penetration Testing