IoT security for product teams: the basics that prevent most incidents

Connected devices combine the risks of web software with physical access, long lifetimes and limited ability to patch. Many real-world IoT incidents trace back to a small set of avoidable design mistakes.

The mistakes that keep recurring

• Default or shared credentials. The same password on every unit means one leak compromises the fleet.
• No update mechanism, so a discovered vulnerability stays forever.
• Unencrypted communication, so traffic can be read or altered on the network.
• Open management ports and services left enabled from development.
• Overly broad cloud permissions, so one stolen device credential can read other customers' data.
• Secrets stored in firmware in plain form, retrievable by anyone with the device.

Build in these fundamentals

Unique device identity. Give every device its own identity and credentials, ideally anchored in a secure element or trusted hardware where the product warrants it. Provision them securely at manufacture or first use, and support revocation of a single device.

Encrypted, authenticated communication. Use TLS or equivalent for all device-to-cloud traffic, validate certificates properly, and authenticate both sides. Do not disable certificate checks to make something work.

Secure boot and signed updates. Devices should run only firmware signed by you, and verify signatures before installing. Updates must be possible, staged, and recoverable if they fail.

Least privilege in the cloud. A device should be able to publish and subscribe only to topics or endpoints tied to its own identity. Apply the same principle to services and humans.

Minimise the attack surface. Disable debug interfaces and unused services in production builds, close unneeded ports, and lock down physical debug headers where the threat model includes physical access.

Protect data. Collect only what you need, encrypt sensitive data at rest on the device and in the cloud, and be clear about retention and deletion. Personal data triggers legal obligations that vary by region.

Think about lifecycle

Security does not end at launch.

• Support period. Decide how long you will provide security updates, and be honest with customers about it.
• Vulnerability handling. Publish a way for researchers to report issues, and have a process to triage, fix and communicate.
• Dependency tracking. Know which open-source components are inside the firmware so you can react when one is found vulnerable. A software bill of materials helps.
• End of life. Plan how devices are retired, wiped and removed from the system.

Threat model early

Spend an hour asking: who might attack this, what do they want, what can they reach, and what is the worst outcome? A baby monitor, a door lock and an industrial sensor have very different answers. A simple threat model guides where to invest.

Test it

Include security testing in the plan: review of firmware and cloud configuration, penetration testing before launch for higher-risk products, and automated dependency scanning in the pipeline.

What to take away

Give each device a unique identity, encrypt and authenticate everything, sign and stage updates, restrict cloud permissions and plan the support lifecycle. These basics prevent the majority of avoidable IoT incidents, and they are far cheaper to design in than to retrofit.