IoT Penetration Testing: Firmware, Radio, and Physical Attacks

IoT penetration testing is a security assessment of a connected device and everything it talks to: the hardware on the bench, the firmware inside it, the radio and network interfaces it exposes, the mobile app that configures it, and the cloud service it reports to. It differs from every other kind of penetration test in one important way. With a web application, the attacker has to reach your server. With a connected device, you ship the attacker the target, and a flaw found in one unit is usually a flaw in the whole fleet.

This guide covers what an IoT penetration test actually examines, layer by layer, the standards a report should map to, and what manufacturers need to prepare before testing starts.

What counts as IoT

The term covers more than smart plugs. In practice the same testing discipline applies to:

• Consumer devices: cameras, locks, thermostats, wearables, appliances, and the hubs that connect them.
• Building and industrial IoT: access control readers, HVAC and lighting controllers, sensors, gateways, and the programmable logic controllers and human-machine interfaces of plant networks.
• Medical devices: monitors, infusion systems, imaging equipment, and diagnostic devices, which carry their own regulatory expectations (covered in our guide to medical device penetration testing).
• Automotive and telematics: electronic control units, telematics units, infotainment systems, and fleet trackers.
• Payment and kiosk hardware: point-of-sale terminals, self-service kiosks, and ticketing devices.

Our hardware and IoT penetration testing service covers all of these classes, because the attack surface layers are the same even when the standards differ.

The attack surface, layer by layer

A device is not one target. It is six or seven, and an engagement that only scans the device’s IP address has looked at one of them.

Layer	What is there	Typical findings
Physical and debug	Circuit board, chips, UART/JTAG/SWD ports, SPI and I2C flash	Debug ports left enabled, unencrypted flash, no tamper detection
Firmware	Operating system, application logic, keys, credentials, update logic	Hardcoded credentials, shared keys across the fleet, unsigned updates
Radio	Bluetooth Low Energy, Wi-Fi, Zigbee, Z-Wave, LoRa, proprietary sub-GHz	Insecure pairing, replayable commands, no encryption
Network services	Web interfaces, telnet and SSH, MQTT, UPnP, custom TCP services	Default passwords, unauthenticated APIs, command injection
Companion app	iOS and Android configuration app	Secrets in the app, weak device authentication, insecure storage
Cloud and API	Device management backend, telemetry, remote control	Broken object authorization across devices, weak device identity
Update mechanism	Over-the-air and USB update paths	Missing signature verification, downgrade attacks, plaintext delivery

Firmware: where the secrets live

Firmware analysis is the center of most IoT engagements, because the firmware contains the device’s logic, its credentials, and often the keys that protect every other layer.

Extraction. Firmware comes off a device in one of several ways: a debug shell over UART, direct memory access over JTAG or SWD, a read of the SPI or I2C flash chip with a clip or after removing it from the board (chip-off), a captured over-the-air update, or simply a download from the vendor’s support site. A device that makes extraction hard raises the bar; a device that makes it impossible is rare.

Analysis. Once the image is unpacked, the review looks for hardcoded credentials and API keys, private keys and certificates (especially ones shared across every unit), the update verification logic (is the signature actually checked, and against what?), secure boot configuration, the services that start at boot, and the application code’s handling of network input. Cryptographic mistakes concentrate here: keys derived from serial numbers, encryption with a fixed key, and random number generation seeded from something predictable.

Why it matters for the fleet. A hardcoded MQTT password in one unit is the MQTT password for every unit. An update-signing key recovered from one device signs malicious firmware for all of them. Findings at this layer are rated by fleet impact, not unit impact.

Debug ports and the physical layer

Engineering teams leave debug interfaces enabled because they are useful during development and easy to forget before production. On the bench, an open UART console often drops straight to a root shell. JTAG and SWD give read and write access to memory and the ability to halt the processor and bypass boot checks. Fault injection, glitching the power or clock at the right moment, can skip a secure-boot signature check on chips that do not defend against it.

Testing here also covers tamper response (does opening the case erase keys or alert anyone?), whether the secure element, where one exists, is actually used for the operations that matter, and whether side-channel leakage during cryptographic operations is a realistic concern for the device’s threat model. Not every device needs resistance to a well-funded physical attacker, and the report says which of these matter for yours.

Radio: Bluetooth, Wi-Fi, and everything sub-GHz

Radio interfaces are where IoT differs most from conventional network testing, and where tooling has become accessible enough that attacks once reserved for specialists are now routine.

• Bluetooth Low Energy. Pairing mode is the first question: “Just Works” pairing offers no protection against a nearby attacker, and many devices use it. Testing then covers whether GATT characteristics enforce authentication before they accept writes, whether commands can be replayed, and whether the companion app’s session with the device can be hijacked.
• Wi-Fi provisioning. The setup flow, usually a temporary access point or a smart-config broadcast, frequently leaks the home network password or accepts configuration from anyone in range.
• Zigbee, Z-Wave, Thread, and LoRaWAN. Key management during joining, default or well-known network keys, and whether messages are actually encrypted and authenticated.
• Proprietary sub-GHz protocols. Garage doors, sensors, and industrial telemetry often use simple modulation with no authentication. Software-defined radio makes capturing and replaying these commands straightforward.

The general test pattern is the same across all of them: capture, decode, replay, and then modify. A device that survives replay and modification of its radio traffic has done the hard part.

Network services and the local attack surface

Once on the same network as the device, an attacker sees whatever services it runs. Common findings include web management interfaces with default or unchangeable credentials, telnet enabled for “support,” MQTT brokers that accept unauthenticated publish and subscribe, UPnP endpoints that expose the device to the internet, and custom TCP services that parse input without validation. This layer is tested the way an internal penetration test treats any host, with the added question of what the device can reach on the corporate or home network once it is compromised.

Companion apps and cloud backends

Most devices are managed through a mobile app and a cloud service, and most serious IoT breaches go through those rather than through the hardware.

The companion app is tested as any mobile application would be, against the OWASP MASVS: secrets embedded in the app binary, how the app authenticates to the device and the cloud, and whether local storage exposes credentials. Our mobile application penetration testing methodology applies directly.

The cloud backend is tested as an API. The critical question is device identity and authorization: can one device, or one user, read or control another? Predictable device identifiers combined with weak authorization checks are the single most common critical finding in IoT cloud services, and they turn a flaw in your backend into remote control of every customer’s device. See our API penetration testing service for how object-level authorization is tested across tenants and devices.

The update mechanism

Updates are the device’s immune system, and the mechanism that delivers them is a target. Testing verifies that update images are signed and the signature is actually checked before installation, that the check cannot be bypassed by downgrading to an older vulnerable version, that updates travel over authenticated and encrypted channels, and that a captured update cannot be modified and replayed. A device with a weak update mechanism cannot be fixed in the field, which makes every other finding permanent.

Standards an IoT penetration test should map to

Buyers, regulators, and enterprise customers increasingly ask which standard the testing followed. The report should state it, and the right one depends on the device.

• OWASP IoT Security Verification Standard (ISVS) and the OWASP IoT Top 10 are the general baseline for any connected product and structure most of our test plans.
• ETSI EN 303 645 is the European consumer IoT baseline (no universal default passwords, vulnerability disclosure, software updates, secure storage of parameters, and so on) and the reference behind several national labeling schemes.
• IEC 62443 governs industrial automation and control systems, including zone and conduit segmentation and component security levels.
• FDA premarket cybersecurity guidance and section 524B of the FD&C Act apply to medical devices, including software bill of materials and postmarket vulnerability management expectations.
• ISO/SAE 21434 and UNECE R155/R156 cover automotive cybersecurity engineering and software update management.
• The EU Cyber Resilience Act sets security and vulnerability-handling obligations for products with digital elements sold in the EU, with reporting obligations applying from September 2026 and the main obligations from December 2027.
• In the US, the FCC’s Cyber Trust Mark is a voluntary consumer labeling program launched in 2025, built on NIST’s consumer IoT criteria.

Findings in our reports are mapped to CWE and rated with CVSS, with the relevant standard’s requirement cited alongside each one.

What an engagement looks like

Scoping. We need to know the device class, the interfaces it exposes, whether firmware and documentation can be shared, and which of the companion app, cloud backend, and update service are in scope. Most engagements include all of them; the device alone is rarely the whole product.

Logistics. Two or more units ship to our bench, ideally including an engineering sample with debug access so time is spent on testing rather than on getting in. Pre-production prototypes are welcome and are the cheapest point to fix a hardware flaw, since a debug port left enabled is a design change before manufacturing and a recall afterward.

Duration. One to three weeks depending on complexity and the number of interfaces, followed by reporting and a free retest of the fixes.

Deliverables. Findings by layer with reproduction steps, fleet-impact ratings, secure-design guidance for each weakness, and the standards mapping your customers or regulator will look for. Hardware and IoT penetration testing starts at $5,200 for a small device, fixed before work begins.

A pre-testing checklist for manufacturers

Before the engagement, the fastest wins are usually already in your hands:

• Inventory every interface the device exposes, including the ones marked “internal only.”
• Confirm whether production units ship with debug interfaces enabled, and whether they can be disabled by fuse or configuration.
• List every credential and key baked into the firmware, and whether any is shared across units.
• Document the update mechanism: signing, verification, transport, and downgrade protection.
• Identify what the device stores locally (credentials, network keys, personal data) and how it is protected.
• Map what the device can reach on the network it joins, and what the cloud backend allows one device to do to another.
• Assemble a software bill of materials for the firmware, which several regulators now expect and which makes vulnerability tracking possible.

Frequently asked questions

Do we need to send you physical devices? Yes. Hardware testing is hands-on work with the unit on the bench. Companion apps, cloud services, and update infrastructure can be tested remotely alongside it.

Can you test a prototype before manufacturing? Yes, and it is the best time to test. Engineering samples with debug access let us cover the firmware and physical layers faster, and design changes are still cheap.

Is the cloud backend included? It can be, and it should be. Most fleet-wide compromises come through the backend’s authorization model rather than through the hardware.

Which standards do you test against? OWASP ISVS and the IoT Top 10 as a baseline, with IEC 62443, FDA guidance, ISO/SAE 21434, or ETSI EN 303 645 applied where the device class calls for it.

How much does IoT penetration testing cost? From $5,200 for a small device, fixed before work begins, with a free retest included. Larger devices with more interfaces, or engagements that add the app and cloud, are quoted after scoping. Starting prices for every service are on our pricing page.

Shipping a connected product, or connecting one to your network? Scope a hardware and IoT assessment and we will confirm which layers matter for your device and send back one fixed price.