IoT penetration testing checks the firmware, wireless protocols, cloud APIs and companion apps behind a connected device — not just the web dashboard most testers default to. If your product ships with a chip, a radio, and an app, a standard web app pentest misses most of the attack surface that matters in 2026.
Why this matters
A connected device that ships in 2026 usually touches four separate systems: an embedded chip running firmware, a wireless radio (Wi-Fi, Bluetooth, Zigbee, LoRa, or cellular), a cloud backend with an API, and a mobile app that talks to both. Attackers pick the weakest link, not the one you tested hardest.
Most generic pentest quotes are scoped like a web app engagement — external IP, a login form, maybe an API. That misses firmware extraction, radio replay attacks, and the trust relationships between device and cloud that account for a large share of published IoT CVEs. Buyers who don't specify scope end up with a report that says "low risk" while the actual attack path — a debug UART left exposed on the PCB — never gets touched.
Who this is for
This guide is for hardware and IoT product teams — smart device manufacturers, industrial sensor vendors, connected health device makers, and SaaS companies shipping a companion app alongside physical hardware — who need a penetration test that actually covers their product, and who need the results to hold up against Cyber Essentials Plus, ISO 27001, or a customer security questionnaire. If you're scoping your first IoT test, or replacing a vendor whose last report only covered the web dashboard, start here.
What to look for in IoT penetration testing
Firmware and hardware access
A tester who won't touch the physical device is scoping a web app test with an IoT label on it. Firmware extraction — via JTAG, UART, SPI flash dump, or OTA update interception — reveals hardcoded credentials, weak encryption keys, and debug interfaces that never should have shipped. Ask for a firmware analysis line item, priced separately, before you agree to a scope.
Wireless and radio protocol testing
Bluetooth Low Energy, Zigbee, Wi-Fi, and cellular each carry their own known attack classes — pairing downgrade, replay, and rogue base station attacks among them. A device that only gets network-layer testing on its Wi-Fi interface leaves BLE pairing and Zigbee mesh traffic completely untested. Confirm the tester names the exact protocols your device uses, not a generic "wireless testing" line.
Cloud API and backend authorisation
Most connected devices phone home to a cloud API that authenticates the device and the user separately. Broken object-level authorisation here — one device reading another customer's data — is the single most common finding in published IoT breach post-mortems. This is standard web application and API testing territory, and it should sit inside your IoT scope, not be quoted as a separate engagement.
Companion app security
The mobile app is often the easiest way into the device — hardcoded API keys, insecure local storage, and certificate pinning that's missing or trivially bypassed. A tester should decompile the app (with your permission and NDAs in place) and check what it exposes before a single packet touches the device itself.
Update and provisioning mechanism
How does the device get its firmware updates, and how does it prove the update is genuine? Unsigned or unverified OTA updates are a direct path to persistent compromise across your entire fleet, not just one unit. This is the finding that turns a single-device bug into a product recall — test it before a customer does.
Reporting mapped to a known framework
A report that lists findings without severity ratings or a reference framework is hard to act on and harder to hand to an auditor. Look for findings mapped against OWASP's IoT Top 10 — a published list of 10 vulnerability classes — so your remediation plan has a structure a security team or customer can actually follow.
Top picks: what to prioritise in scope
Firmware and hardware extraction — the non-negotiable. One spec that matters: whether the tester dumps flash memory and reverses the binary, or just scans open ports. Verdict: Buy — this is the line item that separates an IoT-specific test from a relabelled web app test, and it's where hardcoded secrets get found in 2026-era devices.
Wireless protocol fuzzing — the underrated pick. BLE and Zigbee testing needs specialist tooling most generalist firms don't carry as standard kit. Verdict: Buy if your device pairs over Bluetooth or mesh radio; Skip only if your device is wired-only with zero radio interfaces.
Cloud API and authorisation testing — the safe pick. This overlaps with standard web application and API testing, so most competent testers already have the methodology. Verdict: Buy — it's the cheapest surface to test properly and the one attackers hit most often per published IoT incident writeups.
Companion app decompilation — the wildcard. Some vendors quote this as an add-on rather than a default. Verdict: Consider — mandatory if the app handles authentication tokens or personal data, optional if the app is a thin display-only client with no local storage.
Physical tamper resistance testing — the specialist pick. Checking whether the enclosure can be opened to access debug pins without triggering a tamper flag. Verdict: Consider for devices deployed in unmonitored physical locations (retail floors, public infrastructure); Skip for devices that stay inside a locked data centre or controlled office environment.
What to avoid
- A quote that only lists "network penetration test." That phrase almost never includes firmware extraction or protocol-specific radio testing — ask directly what's in and out of scope before signing.
- A report with no severity scoring or remediation timeline. If findings aren't ranked, you can't tell your board or your ISO 27001 auditor what to fix first — see how to scope a penetration test before you buy one for the questions to ask upfront.
- Treating Cyber Essentials as IoT-complete. Cyber Essentials checks basic cyber hygiene controls; it doesn't touch embedded firmware or wireless protocol security at all. Use it as your baseline, not your finish line, and budget separately for IoT-specific testing.
Get compliance evidence sorted first
OneClickComply automates the certification paperwork so your team can focus the budget on the actual pentest.
Verdict comparison table
| Test surface | Why it matters | Verdict |
|---|---|---|
| Firmware/hardware extraction | Finds hardcoded credentials and debug interfaces | Buy |
| Wireless/radio protocol testing | Covers BLE, Zigbee, Wi-Fi attack classes | Buy (if radio-equipped) |
| Cloud API authorisation | Most common IoT breach vector per published incidents | Buy |
| Companion app decompilation | Reveals hardcoded keys, weak local storage | Consider |
| Physical tamper resistance | Relevant for unmonitored deployment locations | Consider |
Frequently asked questions
One last thing
The finding that shows up most often in published IoT breach reports isn't a zero-day — it's a debug UART or JTAG header left active on the production PCB, giving root access to anyone with physical proximity and a $20 adapter. Ask your tester directly whether they check the board for exposed debug interfaces before you sign the scope in 2026 — it's a five-minute check that catches a disproportionate share of real-world compromises.