A connected device is four attack surfaces in one plastic shell

IoT security assessments go wrong in a predictable way: someone tests the mobile app and the cloud API, finds them reasonable, and signs off. Meanwhile the device has an unfused UART header, a firmware image with a hardcoded key, and a pairing process that accepts a replayed packet. The product is four surfaces, and an attacker only needs the weakest.

Hardware: the ports the vendor forgot

Open the case and look for test points. UART frequently gives an unauthenticated console. JTAG or SWD gives debug access to the processor. SPI flash can be desoldered or clipped and read directly, which usually yields the firmware regardless of what the update server allows. The countermeasure is not secrecy — it is disabling debug in production, fusing what can be fused, and encrypting what sits on flash.

Firmware: where the secrets are

• Extracted images routinely contain API keys, certificates and Wi-Fi credentials that were meant to be per-device.
• Filesystems reveal the update mechanism, and update mechanisms without signature verification are a full compromise path.
• Hardcoded default credentials survive far longer than anyone believes, because they are shared across a product line.
• Debug and manufacturing interfaces are commonly left enabled in shipped builds.

Radio: pairing is the weak moment

BLE, Zigbee, LoRa and Wi-Fi all have secure modes and all have implementations that skip them. The recurring findings are pairing flows that can be forced back to an insecure mode, replayable commands, and identifiers that let a passive listener track a device or its owner. Testing here needs a radio and patience, and it is where assessments most often stop short.

Cloud and app: authorisation, not authentication

Device APIs usually authenticate correctly and authorise carelessly. The classic finding is an endpoint that accepts any valid device token and any device identifier, letting one customer read or control another customer device. Provisioning flows deserve the same scrutiny — how a device proves it is itself, and what stops an attacker from claiming a device they do not own.

Regulation is closing the gap

ETSI EN 303 645 and NIST IR 8259 have set baseline expectations for years, and the EU Cyber Resilience Act turns much of that into a market-access requirement with obligations across the product lifecycle, including vulnerability handling and update support periods. Products designed now will be judged against it.

If your device can be updated but the update is not signature-verified, nothing else in your security design matters.