An IoT product is not one thing to test — it is a full stack: the physical hardware, the firmware, the wireless and radio protocols, the companion mobile app, and the cloud API behind it. A weakness in any layer can compromise the device or the accounts and data behind it, so we test all of them. That means hardware (debug/UART/JTAG interfaces, chip access, tamper resistance), firmware (extraction, hardcoded secrets, insecure updates, vulnerable components), communications (radio protocols, encryption, authentication), the mobile app, and the cloud API — mapped to the OWASP IoT Top 10. In operational environments, this overlaps with OT/ICS testing, where device fragility and safety add constraints.
// 01 What is IoT penetration testing?
IoT penetration testing assesses the security of a connected device and everything it connects to. What makes it distinctive is that an IoT product is genuinely a system spanning several very different technology layers — a physical object with chips and interfaces, firmware running on it, radio protocols carrying its traffic, an app to control it, and a cloud service tying it all together. Testing only one layer, say the mobile app, leaves the others unexamined, and attackers do not respect those boundaries. A proper IoT assessment therefore works across the whole stack, following the connections an attacker would.
// 02 Why IoT is different
IoT combines disciplines that most security testing keeps separate. It requires hardware skills — finding and using exposed debug ports, reading firmware off chips, assessing physical tamper resistance. It requires firmware analysis — extracting and reverse-engineering the software, finding the hardcoded secrets and insecure update mechanisms that plague embedded devices. It requires low-level protocol knowledge for the wireless and radio communications. And it still requires the familiar mobile-app and cloud-API testing. On top of that, IoT devices are typically long-lived, hard to patch, and shipped with weak defaults, and are often physically accessible to an attacker in a way a server never is — all of which raises the stakes.
// 03 The full stack we test
Hardware
Exposed debug interfaces (UART, JTAG, SWD), chip-level access, physical tamper resistance, and access to storage.
Firmware
Extraction and analysis, hardcoded secrets and keys, insecure or unsigned update mechanisms, and vulnerable components.
Communications
Wireless and radio protocols — encryption, authentication, and susceptibility to interception or manipulation.
App & cloud
The companion mobile application and the cloud API and back-end the device depends on — the accounts and data behind the device.
// 04 What we commonly find
Hardcoded secrets in firmware
Keys, credentials or certificates embedded in the firmware — extractable from one device and often shared across the entire product line.
Insecure firmware updates
Unsigned or unverified update mechanisms that let an attacker push malicious firmware to devices.
Broken authorisation in the cloud API
The API behind the app letting one user access another's devices or data — the same access-control flaw that dominates web and API testing.
Exposed debug interfaces
Live UART or JTAG on the board granting console or memory access to anyone who opens the device.
// 05 Who needs it
IoT testing matters for anyone who builds or deploys connected devices: consumer electronics manufacturers, connected medical device makers and healthcare operators, smart-building and industrial-sensor deployments, and connected products across manufacturing and utilities. In operational and industrial settings, IoT and embedded testing overlaps closely with OT/ICS security — where device fragility and the safety of the physical process demand the same careful, safety-first approach. We map findings to the OWASP IoT Top 10 and, where relevant, to the applicable compliance and sector frameworks.
// 06 Frequently asked questions
What is IoT penetration testing?
A full-stack assessment of a connected device and its ecosystem — hardware, firmware, radio protocols, mobile app and cloud API.
What makes it different?
It combines hardware, firmware, low-level protocol, mobile and cloud skills, and deals with long-lived, hard-to-patch, physically-accessible devices.
What does the full stack cover?
Hardware interfaces, firmware (secrets, updates), communications, the mobile app, and the cloud back-end — mapped to the OWASP IoT Top 10.
Which industries need it?
Device makers, healthcare (medical devices), smart buildings, manufacturing and utilities — overlapping with OT/ICS in operational settings.