IoT Security Best Practices: A Developer's Complete Checklist

IoT devices are among the most targeted assets in the modern threat landscape. They often run outdated firmware, use weak default credentials, communicate over unencrypted channels, and operate for years in physically accessible locations with no human oversight. A compromised IoT device is not just a liability for its owner — it becomes a launch pad for attacks on other systems: DDoS bots, lateral movement into enterprise networks, and data exfiltration at scale.

Security cannot be bolted on after the fact. It must be designed into every layer of the stack from the first day of development. This checklist covers the essential security controls that every production IoT device should implement, organized by development phase.

Hardware Security Foundations

Security starts at the silicon level. Hardware security features are the root of trust for everything that runs on the device, and they cannot be patched in if missing from the hardware selection.

Secure element or hardware security module (HSM): Use a dedicated hardware security element for key storage — either a discrete secure element (Microchip ATECC608B, Infineon SLB9670) or an integrated one (STM32’s STSAFE, nRF9160’s KMU). Private keys stored in a secure element cannot be extracted by software, even if the main MCU is fully compromised. This is non-negotiable for devices that authenticate to cloud services or sign firmware updates.

Secure boot support: Choose MCUs that support hardware-verified secure boot — the ability to cryptographically verify firmware authenticity before execution. STM32L5, STM32H5, nRF5340, and most modern Cortex-M33 devices include this capability. Without secure boot, an attacker with physical access can replace the firmware with malicious code.

Hardware true random number generator (TRNG): Cryptographic operations depend on high-quality random numbers. Use the hardware TRNG, not software pseudo-random generators, for key generation, nonces, and session tokens.

Physical tamper resistance: For devices deployed in accessible locations, consider physical tamper detection — tamper-evident seals, accelerometer-based tamper detection, or secure enclosures that trigger key erasure when opened.

Device Identity and Authentication

Every device in a fleet needs a unique, cryptographically verifiable identity. Without it, there is no way to ensure that commands are directed to the intended device and that data arrives from a legitimate sensor.

X.509 certificates for device authentication: Provision each device with a unique X.509 certificate during manufacturing. The private key is generated on-device in the secure element and never exported. The certificate is signed by your device CA (Certificate Authority), which is registered with your cloud platform (AWS IoT, Azure IoT Hub). Cloud connections require mutual TLS authentication — the device authenticates the cloud server, and the cloud authenticates the device.

No hardcoded credentials: Never hardcode passwords, API keys, or shared secrets in firmware. Every device should have a unique identity credential. OWASP IoT Top 10 lists “Use of Hardcoded, Unchangeable Credentials” as one of the most critical IoT vulnerabilities.

Device certificate lifecycle management: Implement certificate rotation — the ability to revoke and reissue device certificates without physical access. This is essential when a CA key is compromised or when devices transition ownership.

Firmware and Software Security

Minimal attack surface: Disable every peripheral, protocol, and service that is not required for the device’s function. If the application does not need UART debug output in production, disable it. If Bluetooth is not needed after provisioning, disable it. Every enabled interface is a potential attack surface.

Disable debug interfaces in production: JTAG and SWD debug interfaces must be locked or disabled before devices leave manufacturing. Many MCU families support permanent or key-protected debug port disabling. Leaving debug ports open is one of the most common security failures in consumer IoT devices.

Secure OTA firmware updates: OTA update firmware must be cryptographically signed. The device verifies the signature before installing any update. The signature chain: release team signs with private key → device verifies with embedded public key → installation proceeds only on valid signature.

OTA updates should also use:

• Integrity check: Hash (SHA-256) of the full firmware image verified before installation
• Version downgrade protection: Refuse installation of firmware older than the current version (defeats rollback attacks)
• Atomic update: Power-fail-safe installation that reverts to known-good firmware if interrupted

Memory protection units (MPU): Configure the Cortex-M MPU to:

• Mark flash regions containing firmware as execute-only (no read from data regions)
• Mark stack regions as no-execute (prevents stack shellcode)
• Isolate peripheral register regions to privileged access only

Stack canaries and bounds checking: Enable compiler-level protections: -fstack-protector-strong, -D_FORTIFY_SOURCE=2. These detect stack smashing attacks before they corrupt the return address.

Secure Communications

TLS 1.2 or 1.3 everywhere: All communication between devices and cloud services must use TLS. This includes MQTT over TLS (port 8883), HTTPS for REST APIs, and DTLS for UDP-based protocols like CoAP. Never use plaintext MQTT (port 1883) in production.

Certificate pinning: Pin the server certificate or CA certificate in firmware to prevent man-in-the-middle attacks using fraudulently issued certificates. Update the pinned certificate via signed OTA updates when certificate rotation is required.

Minimal cipher suites: Configure TLS to use only strong cipher suites: AES-128-GCM, ChaCha20-Poly1305, ECDHE for key exchange. Disable deprecated algorithms: RC4, DES, MD5, SHA-1, RSA key exchange.

Payload encryption for sensitive data: Beyond transport security, consider end-to-end payload encryption for particularly sensitive data (medical readings, location data). AES-256-GCM with device-specific keys provides defense-in-depth if the cloud endpoint is compromised.

Cloud-Side Security Controls

Device-side security is necessary but not sufficient. The cloud backend must also be secured:

Least-privilege IAM policies: Each device should have AWS IoT / Azure IoT Hub policies that allow only the minimum operations required: publish to specific topic prefixes, subscribe to specific command topics. A compromised device should not be able to read data from other devices.

API rate limiting and anomaly detection: Implement request rate limits per device to prevent compromised devices from being used for DDoS. Monitor for unusual patterns: devices publishing at abnormal rates, messages to unexpected topics, connections from unexpected geographic locations.

Audit logging: Log all device connections, authentication events, certificate issuances, and OTA updates to an immutable audit log. NIST SP 800-213 provides detailed guidance on IoT cloud security controls.

Vulnerability Management

Coordinated vulnerability disclosure: Publish a security vulnerability disclosure policy and contact point. The IoT Security Foundation recommends all IoT vendors maintain a CVD program.

Software bill of materials (SBOM): Maintain a complete inventory of all third-party libraries and OS components in your firmware. Subscribe to CVE notifications for your dependencies. An unpatched vulnerability in a widely used TLS library (like the historical Heartbleed in OpenSSL) can compromise thousands of deployed devices.

Penetration testing before launch: Commission professional IoT security testing before product launch. See our companion article on IoT penetration testing for methodology details.

Conclusion

IoT security is not a single control — it is a defense-in-depth strategy spanning hardware, firmware, communications, cloud, and operational processes. Each layer addresses different attack vectors, and the failure of any single layer should not result in total compromise.

The most common security failures in IoT products are not exotic vulnerabilities — they are basic omissions: hardcoded credentials, missing firmware signing, disabled secure boot, unencrypted MQTT, debug interfaces left open. Addressing these fundamentals with the checklist above puts your product in a dramatically stronger security posture than the majority of IoT devices shipped today.

UABit’s IoT device development team designs security controls into devices from the hardware selection stage. If you need a security architecture review, a penetration test, or help implementing any of the controls above, our security-focused engineers can help.