Technical controls — secure boot, encrypted transport, per-device certificates — are the part of IoT security teams usually get right eventually. The part that decides whether a company has a bad year is organisational: who is responsible, what was promised to customers, how a report from a researcher is handled, and whether anyone is still patching the product in year four.
This guide covers that side of connected product security: threat modelling that fits the business, the obligations that now come with selling a connected device, and the processes that turn security from a launch task into something sustained. For the device-level controls themselves, see IoT device security.
Why Connected Products Change the Risk
A security failure in a web application exposes data. A security failure in a connected product can also open a door, stop a pump, or give an attacker a foothold inside a customer’s network. Three characteristics make the risk different in kind.
- Physical consequence. Devices act on the world, so compromise can cause damage rather than only disclosure.
- Physical access. An attacker can buy your product, open it, and probe it at leisure. Any secret present on one device must be assumed extractable.
- Long life, slow patching. A device shipped today may run for a decade, often unattended, sometimes with no one left responsible for it.
Assume one device will be taken apart by a determined attacker. Design so that this does not compromise the other ten thousand.
That single assumption rules out the most common serious mistake: a shared key or password across a product line, where extracting it from one unit yields control of the fleet.
Threat Modelling That Is Worth the Afternoon
Formal methodologies are useful, but most teams get the majority of the benefit from four structured questions, answered honestly in one session with hardware, firmware, cloud and product people present.
What would an attacker want here?
Data, control of the device, a route into the customer’s network, or free use of a paid service. The answer shapes everything; a product whose value to an attacker is network access needs different defences from one holding personal data.
Where are the boundaries?
List every point where data or commands cross trust lines: device to cloud, app to cloud, device to local network, physical ports, the update channel, and the manufacturing line. Boundaries are where controls belong.
What happens if one device is fully compromised?
Can it read others’ data? Issue commands beyond itself? Impersonate the fleet? If yes to any, the architecture needs per-device identity and authorisation rather than a stronger device.
What is the worst realistic outcome?
A privacy breach, a safety incident, a fleet-wide outage, or a botnet built from your product. Rank by consequence rather than likelihood, because low-probability high-consequence outcomes are what end businesses.
What Selling a Connected Product Now Commits You To
Keeping Security Alive After Launch
Frequently Asked Questions
Conclusion
Securing a connected product is less about any individual control than about sustaining responsibility. The technical measures are well documented and increasingly standard; what separates companies is whether someone owns the posture, knows what is inside the firmware, can ship an emergency patch today, and has told customers how long support lasts.
Assume one device will be fully compromised and design so the fleet survives it. Then treat security as an operating commitment with a name attached, not a milestone that was passed before launch.
The same principles now apply to AI agents that hold credentials and act on business systems. AI agent security shows how least privilege and audit trails carry over.