An IoT device is a small computer that is cheap, numerous, physically exposed, rarely watched, and connected to a network. Each of those properties is a security problem on its own. Together they explain why connected devices have been the raw material for some of the largest attacks on the internet, and why IoT security is now a matter of law in several jurisdictions.
The good news is that the threats are well understood and the defenses are mostly known. The hard part is applying them consistently across a product’s whole life, from the factory line to the day it is decommissioned.
This guide walks through the attack surface of a typical device, the attacks that actually happen, and the layered defenses that reduce them.
The attack surface of a connected device
Think of a device as a set of doors. The firmware is one: if it contains a bug, an attacker with network access can exploit it. The network services it exposes are another: a web interface, a Telnet port, an MQTT client. The cloud account it talks to is a third, since a stolen credential there can reach every device. Physical ports on the board are a fourth: debug interfaces such as JTAG or a UART console often give full control to anyone holding the device. The update mechanism is a fifth, and the mobile app and its API are a sixth.
Then add the supply chain. A device is built from third-party chips, a vendor’s SDK, open-source libraries and a contract manufacturer’s production line. Any of these can introduce a weakness the product team never sees.
The attacks that actually happen
Default and weak credentials
The Mirai botnet of 2016 did not use a clever exploit. It scanned the internet for devices accepting Telnet logins and tried a short list of factory usernames and passwords. It found hundreds of thousands of cameras and routers and used them for DDoS attacks that took large services offline. Default credentials remain the single most common way devices are compromised, which is why the UK and EU rules now ban universal default passwords outright.
Unpatched vulnerabilities
Devices ship with known bugs in their network stacks, web servers and libraries, and many never receive an update. A CVE published against a common TCP/IP library can apply to millions of units across hundreds of brands that have no idea they share the code. Without a software bill of materials, the vendor cannot even tell whether it is affected.
Insecure updates
An update mechanism that fetches firmware over plain HTTP and installs whatever arrives is an attacker’s gift: intercept the download and the device runs your code with full privileges. Updates without signature checks, or with a signing key stored in the firmware itself, are variants of the same problem.
Exposed services and cloud misconfiguration
A device that opens a port to the internet to make remote access easy also opens it to everyone. On the other side, a cloud backend with an unauthenticated API, overly broad device permissions, or a shared secret across the whole fleet means one compromised device can read or control the rest.
Physical attacks
With the device in hand, an attacker can dump the flash memory, read keys, modify firmware, or probe the board. For consumer products this is a limited concern; for devices in public spaces, such as smart meters, parking sensors or EV chargers, it is the main one. Side-channel attacks that recover keys from power consumption or timing are a specialist concern for high-value targets.
Defense in depth: the device
No single control fixes this. The usual layering starts at the hardware.
A root of trust, ideally in a secure element or the SoC’s protected area, holds keys that firmware cannot extract. Secure boot uses it to verify each stage of the boot chain, so modified firmware simply does not run. The same signing discipline applies to every OTA update: images are signed by a key kept offline, verified on the device, and installed with a fallback slot so a bad update does not brick the unit.
Each device gets its own device identity, typically an X.509 certificate with a private key generated on the device and never exported. Shared fleet secrets are avoided. Debug ports are disabled or locked in production. Unused network services are removed, not just turned off, and the ones that remain run with the least privilege the operating system allows.
Finally, the firmware is built like software, not like a one-off: dependencies are tracked in an SBOM, scanned for CVEs, and updated. A watchdog timer and crash reporting give the vendor a chance to notice when something goes wrong in the field.
Defense in depth: the network and the cloud
Every connection uses TLS or DTLS with mutual authentication: the device proves who it is with its certificate, and the server proves who it is with one the device trusts. Authorization is scoped so a device can publish to its own topics and nothing else; an MQTT broker policy that lets any client subscribe to everything is a breach waiting to happen.
On local networks, network segmentation keeps devices away from laptops and servers, so a compromised camera cannot reach the finance database. In industrial settings this is formalized in IEC 62443 zones and conduits. Remote access goes through a VPN or a cloud relay rather than inbound ports. Monitoring watches for devices that start talking to unexpected addresses or at unexpected volumes, which is how botnet recruitment often shows up first. The zero trust principle applies: location on a network grants nothing, identity and policy grant everything.
Defense in depth: the organization
Technology alone fails without process. A published vulnerability disclosure policy lets researchers report problems instead of selling them. A stated support period tells buyers how long updates will arrive. Penetration testing before launch finds the obvious holes. A plan for end of life ensures devices are not left online, unpatched, forever.
These are exactly the obligations that the Cyber Resilience Act, the PSTI Act and ETSI EN 303 645 now impose, so building them in early is both good engineering and regulatory preparation.
A practical starting checklist
For a team shipping its first device, the priorities in order are: unique credentials per unit and no default passwords; signed and verified firmware updates; TLS with device certificates; no exposed inbound ports; a tracked dependency list; and a disclosure policy with a contact address. Secure boot and a hardware root of trust come next, and they are much easier to add before the hardware is finalized than after.
Where to go next
- Device identity, certificates and PKI for IoT goes deep on the credential system that most of these defenses rely on.
- IoT security regulation explains what the CRA, PSTI, the Cyber Trust Mark and ETSI EN 303 645 require.
- Device management and over-the-air updates covers how to ship fixes safely to a fleet.
Topics: IoT security, threats, attack surface, botnets, secure boot