Embedded Device Penetration Testing: Why a Web Pentest Isn’t Enough

A connected product ships with a cloud API, a companion app, a radio link, firmware and a circuit board. When the budget line says "penetration test", the scope it buys is usually the API and the app. The test finds real issues, and the product still gets compromised through the layers nobody looked at. The web interface is one interface. The product is all of them.

This note lays out what an embedded product assessment covers, layer by layer, and why each layer produces findings the one above it cannot see.

The product is a stack, not a website

Product security testing starts from a different unit of work than a web pentest. The unit is not an application; it is the product: hardware, firmware, radio, companion app, cloud backend, and the seams between them. An assessment that covers only one layer tests the seam against nothing. Attackers, meanwhile, prefer the seams: they pair with the device over BLE to reach the provisioning API, they pull keys from flash to talk to the backend, they use the app to put the device into states its designers never exercised.

The coverage map above is the honest summary of most "we already had a pentest" conversations: the layers with HTTP in them were tested, the layers with solder in them were not.

Hardware: the layer that re-ranks everything else

Physical access is the entry point most product teams systematically underweight, because it feels like it requires capabilities nobody has. In practice: flash chips are read with clip probes and a flashrom invocation; UART pads are found by measuring continuity to ground on unpopulated header footprints; JTAG is often enabled in production silicon because disabling it was someone's todo. From a dump, we take certificates, tokens, keys, configuration and version history directly, offline, at leisure, with no rate limit and no logs.

Hardware findings re-rank every other layer. The "properly hardened" backend session token means something different once the token is extractable from every unit. The secure boot chain means something different once the unsigned recovery image boots from SD.

Firmware: the evidence layer

Firmware analysis is both an attack surface and an evidence source. As a surface: parsers for update packages, protocol handlers, management interfaces, the update state machine itself, code that runs with full privileges on the device. As evidence: firmware contains the backend endpoints, the protocol implementation to diff against, the hardcoded secrets, the version and patch level of every third-party component. A product assessment without firmware is an assessment conducted with the lights off.

Radio: the interface without a gatehouse

BLE, LoRa/Wi-Fi or proprietary sub-GHz links are the only interfaces an attacker can reach without opening anything, which makes them the cheapest attack surface on the product. Pairing flows, replay behavior, session key handling and the protocol state machine are the standard findings: pairing methods without MITM protection (see BLE Pairing), commands that re-enter privileged states without re-authentication, and protocol parsers that trust the radio for field lengths. Web scope never sees any of this, because there is no HTTP involved.

How to prepare so the budget buys findings

The difference between an expensive checklist and a productive assessment is mostly preparation:

• Test units, not production rejects. Devices that boot, connect and update. Two or three, plus debug access if you can provide it, locked units are a legitimate finding, but they should be the only reason we stop.
• Documentation under NDA. Protocol descriptions, flash maps, update package layout, expected pairing flows. Reverse engineering your own product costs budget you wanted to spend on findings.
• A backend scope that includes device-facing endpoints. The API surface the devices use is the interesting surface.
• A contact who can answer engineering questions within a day. Every day spent waiting is a day not spent testing.

What results should look like

A serious product assessment delivers findings ranked by what an attacker actually gains, chained across layers, with reproduction steps, and with the evidence trail: which dump, which capture, which request. It also delivers the negative results that matter: what was tested and held, so the next release can diff against it. If the report only lists web findings against a product that ships hardware, you did not test the product. You tested a URL that happens to be sold with a device.