A prototype usually assumes a trusted bench, a known operator and easy physical access. A deployed device faces unknown networks, unattended resets, ownership changes and years of updates. “It connects securely” is not a release plan. This checklist turns that gap into evidence a small team can verify before shipping and maintain afterward.
List what the device can affect, what data it handles, who can issue commands, how an attacker could reach each interface and what happens if connectivity disappears. A sensor reporting room temperature has a different impact from a relay controlling a heater, door or pump. Scope the checklist to the device's actual risk and fail-safe behavior.
| Layer | Verify before release | Keep as evidence |
|---|---|---|
| Identity and provisioning | Unique device identity; no fleet-wide shared password; authenticated enrollment and revocation. | Provisioning record, credential owner and rotation/revocation test. |
| Boot and firmware | Secure boot where supported; signed update validation; anti-rollback policy appropriate to recovery needs; debug interfaces controlled. | Release digest/signature, build provenance, test result and rollback evidence. |
| Interfaces and network | Disable unused services; authenticate every command; validate topic/API scope; rate-limit reconnects and requests. | Port/service inventory, access policy and negative authorization tests. |
| Data and privacy | Minimize collection; protect credentials and sensitive data at rest/in transit; define retention and deletion. | Data-flow map, key-storage design and deletion/restore test. |
| Backend and operations | Tenant authorization server-side; secrets outside firmware/repository; audit sensitive changes; alert on stale or anomalous devices. | Threat model, access review, incident runbook and owner for vulnerabilities. |
MAC and IP addresses can change, be spoofed or be visible to observers; treat them as network attributes, not credentials. Provision a per-device key or certificate through a controlled flow, restrict its permissions to that device, and revoke it when lost, replaced or retired. Never flash the same private key into every unit. Keep production secrets out of source, screenshots, logs and support bundles.
Do not disable anti-rollback without an explicit recovery reason, but do not ship an irreversible update path that can strand devices either. Security and recoverability have to be designed together.
Use TLS with certificate validation; encryption without peer verification can still connect to an impostor. Authenticate API and broker clients separately from user accounts. Enforce device-to-tenant authorization on the server, validate message size and schema, and make commands expire and carry unique IDs. Backoff should be bounded with jitter so a regional outage does not turn reconnection into a self-made denial of service.
Local safety must survive cloud loss. Define safe mode, physical override and bounded offline behavior for actuators. A smoke alarm, temperature cutoff or emergency stop must not depend on the dashboard being reachable.
Automate what can be automated: reject a release containing known disallowed dependencies, attempt unsigned firmware, try cross-device topic access, replay expired commands, submit oversized/malformed payloads, disconnect the network and interrupt an update. Run the tests on the actual hardware revision. Manual review should cover threat changes, data collection, access roles and support procedures.
Publish a security contact and supported-product window. Define how reports are acknowledged, triaged, patched and communicated. Inventory deployed versions and their last contact so the team can identify exposure. At transfer or retirement, revoke identity, remove account bindings, clear customer data as promised and preserve only justified audit records.
A maker project becomes a maintainable IoT product when identity is unique, interfaces are minimized, updates are authenticated and recoverable, server authorization is enforced, data has a lifecycle and someone owns incident response. Treat each check as a test or record, not a checkbox with no proof.