Mapping an IoT Attack Surface
A connected product’s attack surface is larger than any single component, spanning the hardware in someone’s hand, the firmware inside it, the radios it speaks, the network it joins, and the cloud it phones home to. Mapping all of it before testing is what keeps an assessment from being thorough on the silicon and blind to the API. Here is how to map the whole thing.
The Attack Surface Is the Whole Product
It is tempting to think of a connected device as just the box on the bench, but an attacker thinks of the entire system: the physical device, the wireless protocols, the companion app, the cloud backend, and the links between them. Any 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 assessment. A test that deeply examines the firmware but never touches the cloud API has covered one face of a many-sided object. The map is the inventory of every face, so the testing that follows can be honest about what it did and did not cover.
Why Map Before You Test
A map turns testing from a wander into a plan. With every entry point listed, you can decide which to probe first, ensure none is forgotten, and report coverage honestly. Without a map, testing follows whatever the tester finds interesting, which leaves predictable gaps in the unglamorous corners.
The map is also a communication tool. It shows the client the full extent of their product’s exposure, often surfacing surface they had not considered, a debug port, a third-party SDK phoning home, a forgotten cloud endpoint. That shared picture is valuable on its own, before a single test runs.
The Physical Surface
Start with what an attacker holds. The physical attack surface is every interface and component reachable with the device in hand: debug ports, test points, external connectors, the flash and other chips, and the buses between them. This is the surface a determined attacker with the device will explore exhaustively.
PHYSICAL SURFACE - Debug: JTAG, SWD, UART consoles, test points - Storage: SPI flash, eMMC, NAND (chip-off readable) - Buses: SPI, I2C, parallel (sniffable) - Ports: USB, serial, expansion headers - Components: secure element, sensors, radios (FCC internals)
Each item is a potential way to read firmware, inject code, or recover secrets. The physical surface is the one that feels safest to teams, because it needs the device in hand, and the one attackers exploit most thoroughly, because once they have the device, nothing stops them from trying everything on this list.
The Firmware Surface
The firmware is both a target and an attack surface in its own right. It contains the parsers that handle every input, the update mechanism, the stored secrets, and any debug hooks. Every place the firmware accepts data, from a radio, a bus, a file, an update, is a point where a flaw becomes an entry.
Mapping the firmware surface means enumerating its inputs and the code that handles them: the command parser, the network stack, the update verifier, the configuration loader. Those handlers are where memory-corruption and logic bugs live, and listing them tells the firmware-analysis phase exactly which code paths deserve the hardest look.
The Wireless and Radio Surface
Every radio is attack surface reachable without wires: Wi-Fi, Bluetooth and BLE, Zigbee, Z-Wave, LoRa, cellular, and proprietary RF. Each protocol has its own pairing, authentication, and encryption, and each is reachable by anyone in range, which makes the radio surface uniquely exposed for a physical-world attacker who never touches the device.
RADIO SURFACE - 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, sensors (replay, rolling codes) - Cellular: if present, the widest-reach surface of all
The radio surface is often the least tested and the most exposed, because it feels invisible and requires 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. Mapping each radio and its trust model is essential.
The Network and Service Surface
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. These are reachable from anywhere on the same network and sometimes from the internet, and they carry the same risks as any networked service plus the fragility of an embedded stack.
Port scanning and service enumeration map this surface, and the embedded twist is that the services often run on a constrained stack that was never hardened. An undocumented management port, a web interface with default credentials, or a discovery protocol that leaks device details all live here, and all are reachable without the device in hand.
The Cloud and Backend Surface
Most connected products depend on a cloud backend, and that backend is part of the attack surface even though it runs on a server. The device-to-cloud API, the cloud-to-device control channel, the user account system, and the third-party integrations are all places an attacker can target to reach the device or the fleet.
The cloud surface matters because it scales: a flaw in the backend can affect every device at once, not just one in hand. Testing the API the device uses, the authentication between device and cloud, and the way the backend authorizes commands is as important as anything done on the bench, and it belongs on the same map.
The Companion App Surface
The mobile or desktop app that controls the device is its own surface, running on a platform you do not control. It holds credentials, speaks to both the device and the cloud, and often contains hardcoded secrets, hints about the protocol, or weak certificate handling that an attacker extracts by decompiling it.
The app frequently leaks the keys to the rest of the system. A hardcoded API key, a disabled certificate check, or a documented-by-accident protocol in the app’s code can hand an attacker what they need to attack the device or the cloud directly. Mapping the app as attack surface, and decompiling it, is a high-value and often-skipped step.
The Supply Chain Surface
A subtler surface is the supply chain: the manufacturing line that provisions keys, the third-party components and SDKs baked into the firmware, and the update infrastructure. A compromise here crosses into every device, and it is surface the product team often does not think of as theirs to defend.
Mapping it means asking where trust is placed in parties you do not fully control: a contract manufacturer that could harvest keys, an SDK that could carry a vulnerability or a backdoor, an update server that could be hijacked. These are real entry points, and listing them on the map ensures the assessment at least asks the questions even when full testing is out of scope.
Build the Inventory
Pull all of this into a single inventory, organized by surface, with each entry point named and its exposure noted, physical, local-radio, network, or internet. The inventory is the deliverable of the mapping phase and the reference the test plan works from.
ATTACK SURFACE INVENTORY (excerpt) SURFACE ENTRY POINT EXPOSURE PRIORITY physical open UART shell device-in-hand high radio BLE pairing in-range high network web admin (default) LAN/internet critical cloud device API auth internet critical app hardcoded API key app extract high
With exposure noted per entry, the priorities sort themselves: the internet-reachable and in-range items outrank the 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.
Use the Map to Drive Testing
The finished map tells the test plan what to cover and in what order. Internet-facing and radio-reachable surface gets tested first because it is most exposed; physical surface gets the depth its threat model justifies. Nothing is skipped silently, because skipping it now is a documented decision rather than an oversight.
The map also frames the final report. Coverage can be stated per surface, this is what we tested on the radio, the network, the cloud, and the device, which lets the client see the whole picture and trust that the assessment matched the product’s real exposure rather than just the part that was fun to poke at.
Keep the Map Alive
A connected product’s surface grows with every feature, integration, and connected service, so the map is never finished. A new API endpoint, a new radio, a new third-party SDK each adds surface, and revisiting the map as the product evolves catches exposure that a single point-in-time assessment would miss.
For a product team, maintaining the map is a security practice in itself. Knowing the full, current attack surface, and watching it grow, is what lets you decide deliberately what to expose and what to close, rather than discovering 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 the rest of the testing 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.