Security Checklist for IoT Devices

A working inventory records every IoT device with its network location, current firmware version and the systems it is allowed to talk to. Both NIST’s IoT guidance and the OWASP IoT Top 10 treat this as foundational, because an untracked device is invisible to every other control.

Give the inventory a named owner. A one-time spreadsheet made at installation and never reopened goes stale within months, because different vendors and contractors keep adding devices that nobody records.

Every device needs a unique password or certificate, since a default shared by every unit of a model is a weakness the OWASP IoT Top 10 flags. Public defaults are easy prey.

IoT devices belong on their own network segment, separate from office computers and business systems, so a compromised sensor cannot become a stepping stone into accounts or payroll. Segmentation is not a luxury. Small sites need it too.

Firmware should come from a verified source and be applied over an encrypted connection, because an update channel that can be intercepted or spoofed is an open door. Traffic between a device and its gateway or the cloud should also be encrypted in transit, even when the payload is “just a temperature reading.”

Management interfaces, meaning the device web login and remote configuration ports, should be disabled when unused and reachable only from the segmented network. Take a textile mill with connected dyeing machines, where a management port reachable from outside the plant lets internet scans find and probe a machine.

On a factory floor or an outdoor site, physical access is often easier to get than network access, so tamper-evident mounting and locked enclosures are real controls. Log connections, configuration changes and failed login attempts, so there is something to check when a device starts behaving oddly, ideally before it affects production.

When a device is decommissioned, revoke its credentials and wipe any stored data before disposal, exactly as you would for an old laptop or a phone. Scrap piles hide live credentials.

Vulnerability testing, whether an internal review or an external assessment, must be planned with the people who run the equipment, because some tests disrupt a live device. This is an implementation point, and it does not replace a qualified security professional’s review of your own network and devices as they actually run.

A testing plan should say which devices can be tested live and which need a maintenance window, and name who may stop a test once production is affected. Skipping it invites an outage.