Connected devices sit in homes, factories and public spaces, often for many years, and are rarely touched after installation. That combination makes them attractive targets and hard to fix after the fact. Security has to be designed in before the first unit ships. This checklist gathers durable principles you can apply during design, review and operations.

Security and compliance requirements differ by industry and jurisdiction. Treat this as general engineering guidance and consult qualified security and legal professionals for your specific obligations.

Start With a Simple Threat Model

You cannot defend against everything, so decide what matters. Ask:

• What are we protecting: user data, physical safety, availability, our backend?
• Who might attack: a remote opportunist, a local user with physical access, a malicious insider?
• What is the worst realistic outcome if one device is compromised? If the entire fleet is?

A device that controls a door lock or industrial equipment deserves a stricter bar than one reporting room temperature, though both can be abused as a foothold into a network.

Identity and Authentication

• Give every device a unique identity. Avoid shared secrets across a fleet.
• Never ship default or hard-coded passwords. Require a unique credential or a first-use setup flow.
• Store private keys in protected hardware where the product justifies it.
• Authenticate both directions: the device verifies the server, and the server verifies the device.
• Support revocation, so one compromised device can be cut off quickly.

Communication

• Encrypt traffic in transit with a current, well-reviewed protocol such as TLS, and verify server certificates rather than disabling validation to make testing easier.
• Use current guidance from standards bodies and your platform vendor for acceptable versions and cipher choices, because recommendations change.
• Keep the clock in mind: certificate validation depends on time.
• Minimize listening services on the device. Prefer devices that initiate outbound connections over those that accept inbound ones.

Firmware and Updates

• Verify the integrity and origin of firmware with digital signatures before installing.
• Use secure boot where hardware allows, so the device runs only trusted code.
• Provide a dependable update mechanism with rollback, and decide how long you will support each product with security fixes.
• Track third-party components and their known vulnerabilities, since most firmware is largely assembled from libraries.
• Disable debug interfaces in production units or protect them properly.

Data Protection

• Collect only what you need.
• Protect stored sensitive data on the device and in the cloud.
• Separate tenants’ data cleanly in multi-customer systems.
• Define what happens to data when a device is resold, returned or retired.

Network Architecture

• Isolate IoT devices from critical systems using segmentation.
• Apply least privilege to device permissions: each device should publish and subscribe only to what it needs.
• Rate-limit and monitor device activity to spot anomalous behaviour.
• Avoid exposing management ports to the public internet.

The Checklist Table

Area	Control	Status question
Identity	Unique per-device credentials	Could one extracted secret affect other devices?
Identity	No default passwords	Does every unit require a unique credential?
Transport	Verified TLS	Is certificate validation ever disabled?
Firmware	Signed updates	Would the device accept an unsigned image?
Firmware	Secure boot	Is the boot chain verified?
Lifecycle	Update and support policy	Is a support period defined and communicated?
Access	Least-privilege permissions	Can a device read other devices’ topics?
Operations	Logging and monitoring	Would we notice a compromised device?
Response	Incident playbook	Do we know who acts and how to revoke?

Review the table at design time, before release and after any significant architecture change.

Prepare for Incidents

Assume that something will eventually go wrong. Preparation turns a crisis into a procedure:

1. Keep an accurate inventory of devices, versions and owners.
2. Be able to revoke credentials per device and per group.
3. Be able to push an emergency update, and test that capability before you need it.
4. Publish a way for researchers to report vulnerabilities responsibly.
5. Define who communicates with customers and what they will say.
6. Rehearse the plan occasionally.

A Hypothetical Example

Imagine a team reviewing a connected sensor before launch. The review finds three problems: a debug serial port left enabled, a single shared credential used by all units to reach the backend, and an update path that does not verify signatures. The team disables the debug interface in production builds, moves to per-device certificates issued during manufacturing, and adds signature verification with rollback to the updater. None of these changes adds user-visible features, but together they change the answer to “what happens if one device is stolen and dissected” from “the whole fleet is exposed” to “one device is revoked”.

Frequently Asked Questions

Is encryption enough to secure a device? No. Encryption protects data in transit, but weak identity, unsigned firmware or exposed services can still lead to compromise.

How long should I support a device with security updates? Set a period that matches the product’s expected life and communicate it. Unsupported devices still in the field become long-term risk.

Do small, low-cost devices need strong security? Yes in proportion to what they can affect, including being used as a stepping stone into a network. Hardware constraints change the implementation, not the need.

Should I run a penetration test? It is a valuable complement to design review, especially before launch, when conducted by qualified professionals.

What about regulations? Several regions have rules or guidelines for connected products, and they change. Check current requirements for your markets with qualified advisers.

Next Step

Hold a one-hour review using the table above on your newest product. Mark each control as met, partly met or missing, and fix the missing items related to identity and signed updates first, since they limit the damage of nearly every other failure.