IoT device hardening: a practical checklist

Published Nov 2026•Hardware security

Connected devices fail in predictable ways. The same handful of mistakes turn up across cameras, routers, meters and sensors, and most large botnets built from such devices exploited nothing more exotic than a shared password. This checklist is ordered by what to fix first, so a small team with limited time can reduce the most risk early.

1. Unique per-device credentials

Remove default passwords entirely. Every unit should leave the factory with its own random credential, printed on the label or provisioned during first setup, and the product should force a change or require physical access to activate remote login. A fleet that shares one login is a fleet that is compromised in one step. Also remove hidden maintenance accounts and hard-coded keys from the firmware image.

2. Minimal network services

List every listening port and delete what is not needed. Telnet, unauthenticated web consoles, debug daemons and discovery protocols exposed to the internet are the usual culprits. Bind management services to the local network only, and do not open inbound ports through the home router automatically. A service that does not run cannot be exploited.

3. Signed firmware and secure boot

Sign every firmware image with a private key that never leaves a controlled signing system. The device should verify the signature before it runs anything. Build the chain from an immutable first-stage loader in ROM or locked flash, which checks the second stage, which checks the operating system and application. If any link is unverified, an attacker who reaches storage can persist forever.

4. Signed, rollback-protected updates

Updates are the only way to fix what you get wrong, so protect them carefully. Require a valid signature on every update package, deliver it over an authenticated channel, and keep a monotonic version counter in tamper-resistant storage so that an attacker cannot install an older, vulnerable release. Use a dual-bank or recovery layout so a failed update does not leave a brick.

5. Secrets storage

Do not keep keys, tokens or certificates in plain flash or in the firmware image. Use a secure element, a trusted execution environment or at the very least hardware-backed key storage where the chip offers it. Keep a separate key per device, so that extracting one unit does not break the others. Lock debug access, as described in the companion note on debug interfaces.

6. Secure communication

Use current TLS with certificate validation for every connection to a cloud service, and do not ship with validation switched off for convenience. Authenticate the device to the server with its own identity rather than a shared token.

7. Logging and monitoring

Record authentication failures, update attempts, reboots and configuration changes, and send them somewhere the device cannot erase. Keep logs free of passwords and personal data. Without logs, an incident cannot be scoped.

8. Vulnerability disclosure

Publish a security contact, a simple policy that promises not to pursue good-faith researchers, and an expected response time. Publish a support period stating how long updates will be provided. Researchers will find issues eventually; a clear channel decides whether you hear about them privately or from a public post.

How to use the list

Treat the order as a default, then adjust it to the product: a device with no internet exposure may promote secure boot, while a cloud-connected one should never delay the first two items.

Items 1 and 2 cost almost nothing and prevent the commonest attacks. Items 3 to 5 depend on silicon choices made early in the design, which is why they should be decided before the board is laid out, not after.