Mapping an IoT Attack Surface
A connected product’s attack surface is larger than any single component. It spans the hardware someone holds, the firmware inside it, the radios it speaks, the network it joins, and the cloud it reports to. Mapping all of it before a single test runs is what separates a thorough assessment from one that goes deep on the silicon and stays blind to the API.
An Attacker Sees the Whole System
It is tempting to picture a connected device as the box on the bench. An attacker pictures the entire system: the physical device, the wireless protocols, the companion app, the cloud backend, and every link between them. Any one of these can be the way in, and a weakness in one often unlocks the others.
Mapping the full surface first is what prevents a lopsided test. Examining the firmware deeply while never touching the cloud API covers one face of a many-sided object. The map is the inventory of every face, and it doubles as a conversation with the client, who often has not pictured the debug port, the third-party SDK phoning home, or the forgotten endpoint until they see it written down.
Start Where the Attacker’s Hands Are
Begin with what an attacker can hold. The physical surface is every interface reachable once the device is on a bench.
| Class | What an attacker can reach with the device in hand |
|---|---|
| Debug | JTAG, SWD, UART consoles, test points |
| Storage | SPI flash, eMMC, NAND (chip-off readable) |
| Buses | SPI, I2C, parallel (sniffable in transit) |
| Ports | USB, serial, expansion headers |
| Components | Secure element, sensors, radios (FCC internals) |
Each row is a way to read firmware, inject code, or recover a secret. Teams tend to treat this surface as the safe one because it needs physical possession; attackers treat it as the thorough one, because once the device is theirs, nothing stops them from trying everything on the list.
Firmware Is Both Target and Surface
The firmware is a target and an attack surface in its own right. It holds the parsers that handle every input, the update mechanism, the stored secrets, and any debug hooks left behind. Every place it accepts data, a radio frame, a bus message, a file, an update, is a point where a flaw becomes an entry.
Mapping it means enumerating those inputs and the code behind them: the command parser, the network stack, the update verifier, the configuration loader. That list tells the firmware-analysis phase exactly which code paths deserve the hardest look.
The Radios Anyone in Range Can Reach
Every radio is surface reachable without wires, and each protocol carries its own pairing, authentication, and encryption.
| Radio | Trust model and exposure |
|---|---|
| Wi-Fi | AP / station, provisioning, WPS, captive portal |
| BLE | Pairing / bonding, GATT services, characteristic permissions |
| Zigbee / Z-Wave | Join process, network-key handling |
| Proprietary RF | Remotes and sensors: replay, rolling codes |
| Cellular | If present, the widest-reach surface of all |
This is often the least-tested and most-exposed surface at once, because it feels invisible and needs special tools. An attacker in range can sniff, replay, or join, and a weak pairing or an unencrypted protocol is a finding that needs no physical access at all.
Network, Cloud, and the App It Trusts
Once on the network, the device exposes services: open TCP and UDP ports, a web interface, APIs, and discovery protocols like mDNS, SSDP, and UPnP. They carry the usual risks of any networked service plus the fragility of an embedded stack that was never hardened, and an undocumented management port or a default-credentialed admin page lives right here.
Most connected products lean on a cloud backend, and that backend is part of the surface even though it runs on a server. The device-to-cloud API, the control channel, the account system, and third-party integrations all scale: a single backend flaw can reach every device at once, not just the one on the bench.
The companion app is its own surface, running on a platform you do not control. It frequently leaks the keys to everything else: a hardcoded API key, a disabled certificate check, a protocol documented by accident in its own code. Decompiling it is a high-value step that assessments skip more often than they should.
Do Not Forget the Supply Chain
A subtler surface is the supply chain: the manufacturing line that provisions keys, the third-party components baked into the firmware, the update infrastructure. A compromise here crosses into every device, and it is the surface a product team is least likely to think of as theirs to defend. Listing it on the map at least forces the questions, even when full testing is out of scope.
Turn the Map into a Ranked Inventory
Pull all of it into one inventory, organized by surface, each entry point named and its exposure noted: physical, local-radio, network, or internet.
| Surface | Entry point | Exposure | Priority |
|---|---|---|---|
| Physical | Open UART shell | Device in hand | High |
| Radio | BLE pairing | In range | High |
| Network | Web admin, default creds | LAN / internet | Critical |
| Cloud | Device API auth | Internet | Critical |
| App | Hardcoded API key | App extract | High |
With exposure recorded per entry, the priorities sort themselves: internet-reachable and in-range items outrank device-in-hand ones, because more attackers can reach them. The inventory turns mapping into a ranked work list, which is exactly what the testing phase needs to spend its time well.
From Map to Test Plan
The finished map tells the test plan what to cover and in what order, and it frames the final report: coverage can be stated per surface, so the client sees the whole picture instead of just the part that was fun to poke at. Nothing gets skipped silently, because skipping something becomes a documented decision rather than an oversight.
And the map is never finished. Every feature, integration, and connected service adds surface, so revisiting it as the product evolves catches exposure a point-in-time test would miss. For a product team, keeping the map current is a security practice in itself: it is what lets you decide deliberately what to expose and what to close, rather than learning of new surface only when an attacker finds it first.
Where This Fits
Mapping the full attack surface is the foundation of a product security assessment and the first thing that makes everything after it trustworthy. If you want a complete map of how your connected product can be reached, across hardware, radio, network, and cloud, that is the kind of work we do at Berkner Tech.
