IoT Security Checklist Before Production: 6 Checks Before You Ship

Shipping an IoT product is not the moment to discover that every device shares one password, unsigned firmware can run, or OTA simply downloads a file and executes it.

This article is the short version. I also made an IoT Security Checklist for Production PDF so you can print the review, assign owners, and record evidence.

How to use the checklist

1. Record the product, hardware revision, and firmware version under review.
2. Mark every item Pass, Fail, or N/A; do not mark Pass without specific evidence.
3. For each Fail, record the root cause, fix plan, owner, and target date in the Remediation Tracker.
4. Sign off only when no CRITICAL item remains open, or an authorized owner has formally accepted the residual risk.

Every security layer needs a clear control, an owner, and evidence before the product ships.

1. TLS/SSL and transport security

“We use HTTPS” is not enough if firmware accepts an invalid certificate or keeps an HTTP fallback. Before shipping, verify that plaintext endpoints are disabled, certificates and hostnames are validated, secrets stay out of logs, and certificate/key rotation has an owner and a test.

2. Password and credential storage

Every device should have its own identity and credential. Do not use a default password or one API key for the whole fleet; do not store passwords or tokens as plaintext; make individual revocation possible; and confirm that factory reset removes credentials, bonds, and account linkage.

Per-device credentials let you revoke one compromised node without affecting the whole fleet.

3. Secure Boot and firmware signing

Secure Boot verifies firmware before it runs, while firmware signing is the release process that creates a trusted image. Prove that unsigned firmware and firmware signed by the wrong key are rejected. Production signing keys should not live in the repository, CI logs, or an everyday laptop.

4. OTA security

HTTPS protects the download path; a firmware signature authenticates the image. Production OTA should verify the signature, write to an inactive slot, run a health check, and roll back when the new firmware cannot boot or reconnect. Test power loss during download and writes, invalid signatures, and anti-rollback.

OTA earns trust only after testing an invalid signature, power loss, and an unbootable new image.

5. Data encryption and minimization

Sensitive data should be encrypted in transit and at rest where appropriate. The first question is whether the product needs to retain it at all. Check key lifecycle, log redaction, retention, and deletion behavior when an account is removed.

6. Debug interfaces and release evidence

UART, JTAG, ROM download mode, and test pads speed development but become entry points when someone has physical possession. Decide which interfaces are locked, which are needed for RMA, and who can restore access.

Do not record only “tested.” Keep the firmware hash, version, TLS/OTA/reset/debug test results, reviewer, review date, and issue link for every open risk.

Download the checklist

If you are preparing to ship, use the full documents:

• Download the v1.1 checklist PDF — printable review and sign-off copy.

The PDF includes CRITICAL / HIGH / MEDIUM / LOW priorities, evidence guidance, a remediation tracker, scoring summary, approval workflow, and final sign-off. It is not a security audit or penetration test, but it helps a team catch baseline controls before shipment.

Conclusion

An IoT product is not production-ready simply because it can connect to the cloud. It needs a unique identity, authenticated connections, a firmware chain of trust, rollback-capable OTA, and lifecycle protection for its data.

If time is limited, I would prioritize removing shared credentials, enforcing TLS correctly, signing firmware, adding OTA rollback, and keeping test evidence.

References

• OWASP IoT Security Testing Guide
• ESP-IDF security examples
• ESP-IDF OTA examples
• NIST IR 8259A