Security Checklist for IoT Devices

It's difficult to secure a device the business doesn't know it has. A working inventory records every IoT device, its network location, its current firmware version, and what it's allowed to talk to — this is the baseline both NIST's IoT device cybersecurity guidance and the OWASP IoT Top 10 identify as a foundational step, since an untracked device is invisible to every other control on this list.

This inventory needs a named owner and a review cadence, not a one-time spreadsheet made during installation and never revisited. Devices get added by different vendors and contractors over time, and an inventory that isn't kept current quietly stops being useful within a few months.

Every device should get a unique password or certificate at setup — never a shared default that's the same across every unit of that model, which is one of the most common weaknesses the OWASP IoT Top 10 flags, and one of the easiest for an attacker to exploit at scale once it's known publicly for a given device model.

IoT devices generally belong on their own segmented part of the network, separate from office computers and core business systems, so that a compromised sensor can't be used as a stepping stone into the rest of the network. This segmentation is a standard recommendation, not a nice-to-have reserved for larger organisations.

Firmware updates should come only from a verified source and be applied over an encrypted connection — an update mechanism that can be intercepted or spoofed is effectively an open door. Communications between the device and its gateway or the cloud should be encrypted in transit, not sent in plain text because it's "just a temperature reading."

Management interfaces — a web login on the device itself, remote configuration ports — should be disabled if they're not actively needed, and reachable only from the segmented network, not the open internet. Consider a textile mill running IoT-connected dyeing machines: leaving a machine's management port reachable from outside the plant network is a common and avoidable way for a device to be found and probed by automated internet scans.

Physical access to a device is often easier to get than network access on a factory floor or an outdoor site, so tamper-evident mounting and restricting who can physically reach a device matter as real controls, not afterthoughts. Logging device activity — connections, configuration changes, failed login attempts — gives the business something to check when a device starts behaving oddly.

When a device is decommissioned, its credentials should be revoked and any stored data wiped before disposal, the same discipline applied to an old laptop or phone. A retired sensor still holding valid network credentials, sitting in a scrap pile, is a real and easily overlooked risk.

Testing IoT devices for vulnerabilities — whether an internal review or an external assessment — needs to be planned with the people who run the underlying equipment, since some tests can disrupt a live device or the process it's controlling. This is an implementation consideration to plan for, not a substitute for a qualified security professional's own assessment of your specific environment.

A testing plan should specify which devices can be tested while live, which need a maintenance window, and who has authority to stop a test immediately if it affects production. Skipping this coordination in the interest of speed is how a routine security check turns into an unplanned outage.