Your field guide to IoT firmware security and the most common IoT vulnerabilities we uncover during audits. Apply these IoT security best practices for a secure IoT deployment.
The IoT attack surface is growing faster than most engineering teams can keep up with. By mid-2026, the number of connected IoT devices worldwide has surpassed 30 billion, and the volume of IoT-targeting malware has increased by over 400% since 2023. From botnets recruiting vulnerable thermostats into DDoS armies to attackers extracting production firmware from smart locks, the threat landscape is both real and accelerating.
Over the past several years, our team at Aletheia Tech has conducted dozens of firmware audits and penetration tests across industrial controllers, medical devices, smart building systems, and consumer IoT products. Despite the variety of verticals, we keep seeing the same mistakes. Here are the eight most critical — and how to avoid each one.
The Mirai botnet of 2016 should have been a permanent wake-up call. It infected hundreds of thousands of IoT devices by simply trying factory-default username and password combinations. Yet almost a decade later, devices still ship with admin:admin, root:root, or no authentication at all on local interfaces.
How to fix it: Enforce password change on first boot. Generate a unique random device password printed on the packaging rather than a shared default. For headless devices, require the user to set credentials during initial provisioning via a companion mobile app or web portal. Audit your supply chain — white-label firmware from ODM partners often ships with hardcoded default credentials that are documented in public SDK datasheets.
A device that cannot be patched is a permanent liability. When a vulnerability is discovered — and it will be — devices in the field become a lasting attack vector. We've audited products still running Linux kernels from 2015 with dozens of known CVEs, simply because the vendor never implemented OTA updates.
How to fix it: Build OTA update capability into your firmware architecture from day one. Use signed update images verified against a public-key signature stored in read-only memory. Implement A/B (redundant) partition schemes so that a failed update can be rolled back. Support staggered rollouts to catch issues before they reach your entire fleet. For constrained MCU-class devices, consider delta updates to minimize bandwidth usage. For a complete implementation guide, see our ESP32 OTA updates guide.
Many IoT protocols have no built-in encryption. MQTT, CoAP, and Modbus all transmit data in plaintext by default. We've intercepted telemetry data — including patient vitals from medical devices and access codes from smart locks — simply by sniffing the local network during an audit.
How to fix it: Encrypt everything in transit. Use TLS 1.3 for MQTT (with MQTT over TLS on port 8883) and HTTPS for REST APIs. For CoAP, enforce DTLS. Never fall back to an unencrypted channel. Validate certificates on the device side and pin the server certificate where possible. On constrained devices, consider hardware cryptographic accelerators to reduce the TLS handshake overhead. For a detailed comparison of encryption algorithms, see our AES-256-GCM vs ChaCha20-Poly1305 guide.
If an attacker gains physical access to your device and the flash storage is unencrypted, the firmware can be dumped, reverse-engineered, and cloned. We've extracted complete firmware images, including proprietary algorithms and hardcoded secrets, from production devices using nothing more than a logic analyzer and an open-source flash reader.
How to fix it: Implement secure boot that verifies each stage of the boot chain against an immutable root of trust stored in one-time-programmable (OTP) fuses. Encrypt the flash storage using on-die AES engines available on modern SoCs (ESP32, STM32, NXP i.MX). Store encryption keys in a dedicated secure element or trusted platform module (TPM), never in firmware.
Cloud-connected IoT devices talk to backend APIs, and those APIs are often the weakest link. Common findings include missing authentication on device registration endpoints, no rate limiting allowing credential stuffing, and SQL injection or command injection in device-reported telemetry fields.
How to fix it: Authenticate every API request — device-to-cloud and cloud-to-device. Use API keys rotated on a regular cadence, combined with mutual TLS (mTLS) for device authentication. Implement strict rate limiting per device and per IP. Validate and sanitize all input fields server-side. Use a Web Application Firewall (WAF) and run regular API security scans as part of your CI/CD pipeline.
Placing IoT devices on the same flat network as critical business systems is a disaster waiting to happen. Once an attacker compromises a single IoT device — perhaps through a vulnerable web interface on a smart camera — they have a foothold from which to pivot to databases, file servers, and internal tools. In one assessment, we reached a hospital's patient record system through an unsecured HVAC controller.
How to fix it: Segment IoT devices onto dedicated VLANs with strict firewall rules that block all unsolicited inbound traffic. Use a zero-trust model: devices should only be able to reach specific cloud endpoints on specific ports. Deploy network access control (NAC) to authenticate devices before granting network access. For industrial environments, use IEC 62443-compliant network architecture with OT-specific DMZs.
Recommendation: For teams starting from scratch, we recommend a four-zone network architecture: (1) IoT device VLAN, (2) management VLAN for provisioning and OTA servers, (3) application backend VLAN, and (4) corporate IT VLAN. Each zone is firewalled from the others with explicit allow rules only.
Without adequate logging, you cannot detect a breach in progress or conduct a post-mortem after an incident. We've worked with clients whose devices had been exfiltrating data for months with no alarms triggered because no baseline of normal behaviour had been established and no logs were being collected.
How to fix it: Implement structured logging on the device for boot events, connection attempts, OTA results, and authentication failures. Ship those logs to a centralized Security Information and Event Management (SIEM) system. Set up automated alerts for anomalous patterns: repeated failed login attempts, unexpected outbound connections to unfamiliar IPs, and deviations from normal telemetry intervals. Use a cloud-based IoT monitoring platform that provides device health dashboards and anomaly detection.
Hardcoding API keys, TLS private keys, database credentials, or certificate authorities directly into firmware is alarmingly common. Once firmware is extracted — see Mistake 4 — those secrets are compromised for every device in the fleet. In one engagement, we found the same AWS IAM key hardcoded across 50,000 deployed devices, providing broad access to a cloud-hosted backend.
How to fix it: Never store secrets in firmware binaries. Use a hardware secure element (SE) or TPM to store private keys in a way that they can be used for cryptographic operations but never extracted. For cloud credentials, use a secure provisioning service (e.g., AWS IoT Core credential provider, Azure DPS) that issues short-lived, device-specific tokens at boot time. Inject secrets during manufacturing using a secure provisioning server that writes directly to OTP memory or a secure element, never to flash that can be read out via JTAG.
The Pattern: Mistakes 4 and 8 compound each other. If flash is unencrypted, secrets are exposed. If secrets are hardcoded, they can be extracted from decrypted firmware. Solving both — encrypted flash with hardware-backed key storage and dynamic credential provisioning — eliminates the entire class of vulnerability.
The common thread across all eight mistakes is that security was treated as an afterthought — something to address after the hardware was chosen, the firmware was written, and the cloud backend was deployed. Retrofitting security is always more expensive, more complex, and less effective than building it in from the start.
A security-by-design approach means:
No device is ever perfectly secure, and no audit can eliminate every risk. But eliminating these eight common vulnerabilities dramatically reduces your attack surface and raises the bar for attackers — who will move on to easier targets. The goal is not perfection; it is making your system sufficiently hard to compromise that the cost of attacking it outweighs the value of what the attacker would gain.
Security is a process that must be maintained across the entire product lifecycle: from secure manufacturing provisioning, through regular OTA updates, to eventual decommissioning and secure erasure of cryptographic material. Each of these phases requires deliberate engineering investment.
At Aletheia Tech, we help teams at every stage of this journey — from architecture reviews and threat modelling to full firmware audit and security remediation. If you are building an IoT product and want to avoid these mistakes, get in touch.
Strengthen your IoT security and encryption knowledge.
