IoT Device Penetration Testing for Connected Devices

A connected device is a distributed system compressed into a product. Testing it like a web application misses most of what matters.

A multi-layered attack surface

Every IoT product combines several attackable layers: the physical hardware and its debug ports, the embedded firmware, the wireless protocols it speaks, the companion mobile app, and the cloud services it talks to. A weakness in any one can compromise the whole, and real attacks routinely chain across layers.

Constraints that breed insecurity

Embedded devices face constraints that IT systems do not — limited memory and compute, long field lifespans, intermittent connectivity, and cost pressure. These constraints frequently produce insecure shortcuts: default passwords, disabled encryption, no secure boot, and no update mechanism.

Physical access is realistic

Unlike a server in a locked data center, IoT devices sit in homes, factories, hospitals, and public spaces. An attacker can often buy one, take it apart, and study it at leisure. The threat model must assume the adversary has the hardware in hand.

Assume the attacker owns a copy of your device, has opened it, and has all the time in the world. If your security still holds, you have designed well.

IoT assessment begins with understanding the device physically. The circuit board is a map of the attack surface.

Component identification

Open the enclosure and identify the main components: the microcontroller or SoC, flash and EEPROM memory, radio modules, and sensors. Datasheets for these parts reveal capabilities, debug interfaces, and known weaknesses.

Finding debug and test interfaces

Manufacturers leave debug interfaces on production boards far more often than they should:

• UART — a serial console that frequently offers an unauthenticated shell or boot log.
• JTAG / SWD — hardware debug ports that can allow full memory read/write and firmware extraction.
• SPI / I2C — buses to flash chips from which firmware can be dumped directly.

Extracting firmware from hardware

Where firmware is not otherwise available, it can often be read straight off the flash chip using a programmer, or captured over UART/JTAG. This physical extraction frequently defeats software protections entirely and is a cornerstone of IoT testing.

An enabled UART console or unlocked JTAG port often turns a hard problem into a trivial one. Hardware review is not optional in IoT testing.

Firmware is where a device's secrets and logic live. Following the OWASP Firmware Security Testing Methodology, analysis moves from extraction to deep inspection.

Unpacking and inspection

Extracted firmware images are unpacked to reveal the filesystem, kernel, and applications. Automated tooling identifies the format, carves out embedded filesystems, and highlights interesting artifacts.

Hunting for secrets

Firmware routinely contains what it should not:

• Hardcoded credentials, API keys, and private certificates.
• Cryptographic keys that are shared across every unit shipped.
• Backdoor or debug accounts left in for manufacturing.
• Sensitive URLs and cloud endpoints.

Analyzing binaries

Beyond secrets, static and dynamic analysis of the binaries reveals vulnerable logic, unsafe functions, outdated third-party libraries with known CVEs, and weak update-verification routines. Emulation lets testers run and probe firmware without the physical device.

Secure update as a control

A critical question is whether the device verifies the authenticity and integrity of updates. A device that accepts unsigned firmware can be permanently backdoored, making secure boot and signed updates among the highest-value controls to test.

Shared cryptographic keys are one of the most damaging IoT findings: break one device and you have broken the entire fleet.

IoT devices talk constantly — to hubs, phones, and clouds — over a mix of wireless and application protocols. Each channel is a test target.

Wireless protocols

Depending on the device, testing may cover Wi-Fi, Bluetooth Low Energy, Zigbee, Z-Wave, or cellular. Common weaknesses include unencrypted pairing, weak key exchange, replayable commands, and susceptibility to jamming or spoofing. Radio capture and analysis tools let testers observe and manipulate this traffic.

Application protocols

At the application layer, IoT devices commonly use MQTT, CoAP, or HTTP-based APIs. Testers check for:

• Missing or weak transport encryption (TLS not enforced or poorly validated).
• Absent authentication and authorization on message brokers or endpoints.
• Commands that can be captured and replayed to control the device.

Man-in-the-middle testing

By intercepting traffic between the device, app, and cloud, testers reveal what data is exposed, whether certificate validation is enforced, and whether the device can be tricked into trusting a rogue endpoint. Devices that skip certificate validation — a frequent shortcut — are trivially intercepted.

Encryption that is present but unvalidated is a false sense of security. Confirm the device actually checks who it is talking to.

The device is only part of the product. Most IoT ecosystems route control and data through a mobile app and a cloud backend that are often softer targets than the hardware.

Mobile companion apps

Mobile apps frequently embed the keys to the kingdom. Testing, guided by the OWASP Mobile Application Security standards, looks for hardcoded API keys and secrets, insecure local storage of tokens, weak certificate pinning, and logic that trusts the client. Decompiling the app often reveals how the entire ecosystem authenticates.

Cloud APIs and backend

The cloud backend is where fleet-wide compromise happens. Key tests include:

• Broken object-level authorization — can one user access another user's device or data by changing an identifier?
• Weak device identity — can an attacker impersonate a device or register a rogue one?
• Insecure APIs — the standard web and API vulnerabilities, now controlling physical devices.

The systemic risk

A single authorization flaw in the cloud API can expose or control every device in the field simultaneously — a far greater risk than any single-device hardware attack. GuardsArm's penetration testing engagements treat the cloud tier as a first-class target for exactly this reason.

The scariest IoT bug is rarely in the device. It is the cloud API that lets one attacker command every device at once.

A pile of findings is not an assessment. Value comes from translating discoveries into prioritized, actionable risk that a product team can fix.

Map to a recognized standard

Frame findings against the OWASP IoT Top 10 and established baselines such as NIST guidance for IoT device manufacturers and the ETSI EN 303 645 consumer IoT standard. This gives stakeholders a common language and demonstrates coverage.

Prioritize by exploitability and impact

Not all findings are equal. A hardcoded shared key exploitable remotely outranks a UART console that requires disassembly. Rate each issue by realistic attacker effort, required access, and business impact, and tie it to a concrete attack scenario.

Practical remediation guidance

• Eliminate default and hardcoded credentials; enforce per-device unique secrets.
• Implement secure boot and cryptographically signed firmware updates.
• Enforce validated TLS on every communication channel.
• Disable or lock down production debug interfaces.
• Fix authorization flaws in cloud APIs and companion apps.

Retesting

Security is not one-and-done. Retesting after remediation confirms fixes are effective and did not introduce regressions. For products with long field lifespans, periodic reassessment keeps pace with new threats.

The best IoT report reads like a plan, not a catalog — every finding paired with the attacker scenario it enables and the specific fix that closes it.