IoT penetration testing assesses a connected device as a whole system, not just its app. A single smart lock, camera, or industrial sensor exposes a web interface, a mobile app, cloud APIs, firmware on a flash chip, exposed debug ports, and one or more radios. Each layer is its own attack surface, and the interesting bugs usually sit where two of them meet.
This guide follows the layers an assessor actually works through: recon and network services, firmware extraction and analysis, hardware interfaces like UART and JTAG, and radio. It maps the work to the OWASP IoT Top 10 and names the tools (binwalk, EMBA, flashrom, Bus Pirate, RTL-SDR) you reach for at each step.
IoT penetration testing is a security assessment that covers every layer of a connected device: its network services, web and mobile interfaces, cloud APIs, firmware, hardware interfaces, and wireless radios. The goal is to find how an attacker with physical access, network access, or just the companion app could compromise the device or the accounts behind it.
It blends disciplines. You will do web and API testing against the management interface, mobile testing against the companion app, plus hardware and RF work that has no equivalent in pure software engagements. Because the firmware and hardware are physically in your hands, IoT testing is unusually white-box compared with other types of penetration testing.
The OWASP IoT Top 10 is the reference list of the most common IoT security weaknesses, and it frames the scope of most engagements. It starts with weak, guessable, or hardcoded passwords, which remain the single most exploited IoT issue, and moves through insecure network services, insecure ecosystem interfaces, and lack of secure update mechanisms.
The remaining items cover insecure or outdated components, insufficient privacy protection, insecure data transfer and storage, lack of device management, insecure default settings, and lack of physical hardening. Map each finding to an item so the client can compare against an industry baseline, the same way you would anchor a web engagement to the network and service controls you assess elsewhere.
Firmware analysis usually starts before you touch hardware: pull the firmware image from the vendor's update server or support download, then unpack it. binwalk identifies and extracts embedded filesystems (commonly SquashFS or JFFS2), bootloaders, and compressed blobs. firmware-mod-kit helps rebuild images, and EMBA automates a deep static analysis pass over the extracted filesystem.
Once the filesystem is mounted, you are hunting for the same kinds of secrets as any code review: hardcoded credentials in /etc/passwd and /etc/shadow, private keys and certificates, API endpoints and tokens, backdoor accounts, and outdated binaries with known CVEs. grep, strings, and a quick check of busybox and OpenSSL versions go a long way. This is firmware-flavored static analysis, close in spirit to the AI-assisted review we describe in our agentic pentesting guide.
UART and JTAG are debug interfaces on the board that often give direct, authenticated-free access to the running system. UART (a serial console) frequently drops you straight to a root shell or a bootloader prompt. JTAG gives low-level CPU debug access for reading and writing memory and halting execution. Finding them is half the work.
Open the case and look for headers or test pads, then identify pins with a multimeter and a logic analyzer. For UART, connect a USB-to-TTL adapter (matching the device's voltage, usually 3.3V) to TX, RX, and GND, then attach with screen or minicom at a baud rate you find by trial (115200 is common). JTAGulator helps locate JTAG pinouts automatically. From a UART root shell you can read firmware live and dump secrets without ever touching the flash chip.
When debug ports are disabled, you go straight for the storage. Most IoT devices keep firmware on an external SPI flash chip (often a Winbond 25-series in an SOIC-8 package). Dumping it gives you the full firmware image even when the vendor never published one. You read the chip with flashrom driving a hardware programmer.
Connect with an SOIC-8 test clip so you do not have to desolder, wire it to a Bus Pirate, a CH341A programmer, or a Raspberry Pi acting as the SPI master, then run flashrom to read the chip into a file. Feed that image back into binwalk and your firmware workflow. If the chip is powered by the board during reads, you may need to isolate it to avoid the main CPU contending for the bus.
Radio testing captures and analyzes the wireless protocols the device uses, which can include Wi-Fi, Bluetooth Low Energy, Zigbee, and sub-GHz bands like 433 MHz. A cheap RTL-SDR dongle turns into a software-defined radio receiver that, with rtl_433 or GNU Radio and a tool like Universal Radio Hacker, lets you sniff, decode, and replay signals.
The classic finding is an unauthenticated replay attack: capture the signal a remote or sensor sends, retransmit it, and trigger the action (unlock, open, arm) without any rolling code or authentication. For application-layer IoT protocols, test MQTT and CoAP brokers for missing authentication, open topics, and cleartext transport, since an exposed broker often exposes every device on it at once.
Report each finding against the layer it lives on and the OWASP IoT Top 10 item it maps to, with the access level required (physical, local network, or remote) made explicit, because that drives real-world risk. A root shell over UART matters less if the device is in a locked enclosure than a remotely exploitable network service does.
Prioritize by exploitability and blast radius: a hardcoded key shared across every shipped unit, or an exposed MQTT broker, affects the whole fleet, not one device. Where the same bug class recurs across firmware versions, recommend a secure update pipeline so fixes can actually ship. For organizations running fleets, fold this into the kind of continuous validation we cover in our network testing guidance.
