IoT Security: What Every Product Team Needs to Know

Web security and IoT security share some vocabulary, but they are fundamentally different disciplines. A compromised web application can leak data and damage reputation. A compromised IoT device can unlock a door, disable a safety sensor, manipulate industrial equipment, or become part of a botnet that attacks other systems — all while sitting physically in a user’s home or on a factory floor with no visible indication that anything is wrong.

The stakes are different. The threat model is different. And the standard web developer approach to security — handle auth, encrypt in transit, patch promptly — is necessary but not sufficient for connected devices.

This post covers what makes IoT security distinct, where most teams get it wrong, and what to build from day one rather than bolt on after your devices are already in the field.

Why IoT Security Is Different

Physical access changes the threat model. A web server lives in a data centre with controlled physical access. An IoT device lives in a warehouse, a patient’s home, an outdoor enclosure, or on a factory machine. An attacker with physical access to a device can extract firmware, read memory, manipulate hardware inputs, or intercept communications at the board level. Physical access controls that web teams take for granted do not exist for deployed devices.

Firmware updates are not automatic. Web applications update silently every time users visit. IoT devices run firmware that was flashed at manufacturing or provisioning time, and may run that same firmware for months or years — especially in industrial, medical, or consumer environments where automatic updates are disabled, unsupported, or simply not implemented. A vulnerability discovered in 2025 may be running on devices in the field until 2030.

Long device lifetimes create long exposure windows. Enterprise software has a typical lifecycle of a few years. IoT devices in industrial settings often operate for 10–15 years. The cryptographic algorithms, communication protocols, and software libraries that are secure today may have known vulnerabilities within that window. Device longevity requires forward-thinking security design, not just current-state protection.

Heterogeneous, unmanaged fleets. A typical deployed IoT fleet contains devices running different firmware versions, different hardware revisions, and connected over different network conditions. Centralised fleet management is not a given. Security policies must be enforceable across this diversity.

The Most Common Attack Vectors

Hard-coded credentials. This is the single most pervasive IoT security failure. Default usernames and passwords baked into firmware, API keys embedded in code, admin interfaces with credentials that cannot be changed. These credentials are often the same across every unit of a product line, meaning a single disclosure compromises the entire deployed fleet. Default credential scanning tools exist specifically to find these — and attackers use them.

Unencrypted communications. Many IoT devices communicate over HTTP, MQTT without TLS, or custom binary protocols without encryption. An attacker on the same network — or a compromised router between the device and cloud — can observe all traffic, inject commands, and replay packets.

No firmware signature verification. If a device will accept and flash any firmware image presented to it over an update channel, an attacker who can reach that channel can install arbitrary code. Firmware signing — where the device only accepts updates signed by a known private key — prevents this class of attack. It is not difficult to implement, but many teams skip it.

Exposed debug interfaces. UART serial ports, JTAG headers, SWD interfaces — standard hardware debugging tools left enabled in production hardware. These provide direct access to firmware, bootloaders, and sometimes running process memory. Devices shipped to end users with accessible debug interfaces have been compromised routinely. The fix at hardware design time is a few dollars or a solder jumper. The fix after devices are manufactured is a recall.

Insecure cloud backend. The device firmware can be secure and the cloud API behind it completely open. Device-side authentication that trusts device-supplied identity claims without proper validation, APIs without authorisation checks, device management endpoints accessible over the public internet — all of these appear in real deployments.

What a Real IoT Security Model Looks Like

Security needs to be designed across four layers simultaneously. A gap in any one layer creates an attack surface regardless of how strong the others are.

Device identity. Every device in the field should have a unique cryptographic identity — an X.509 certificate or equivalent — provisioned at manufacturing time and tied to hardware. Shared secrets across device fleets are a single point of failure. Per-device identity means a compromised device can be revoked without affecting the rest of the fleet.

Secure boot. The boot chain — from the hardware root of trust through the bootloader to the firmware — should be verified at each stage using signed images. This prevents an attacker with physical access from booting a modified firmware image. Hardware security modules (HSMs) or secure elements on the SoC provide the root of trust anchor.

OTA update signing. Every firmware update delivered over-the-air must be signed with a private key that the device has no access to. The device verifies the signature before flashing. This is non-negotiable for any device that will receive remote updates.

Certificate management. TLS certificates expire. Device fleets that shipped with hard-coded certificates that expire five years later will stop working or become insecure without a rotation mechanism. Plan for certificate rotation before you ship.

The Awkward Reality

Most IoT security problems are not discovered during development. They’re discovered after devices are deployed — by security researchers, by customers who notice unexpected behaviour, or by attackers who don’t announce themselves.

The economics are harsh: fixing a security vulnerability in cloud software costs engineering time and a deployment. Fixing the same vulnerability in firmware requires building and distributing an update, getting devices to accept it, and hoping that devices in the field are connected and can complete the update. If the update mechanism itself is broken or the device is offline, you cannot patch it at all.

In industrial and medical contexts, firmware updates require validation and approval processes that can take weeks. There are real-world IoT deployments where a known vulnerability was patched in firmware 18 months before the patch reached all devices in the field — because the update process required manual intervention at each site.

This asymmetry — cheap to fix in design, expensive to fix in the field — is the core reason IoT security has to be a first-class requirement from day one, not a hardening pass before launch.

How to Plan for Security from Day One

Threat model before you write code. For each data flow (device → cloud, cloud → device, device → user interface, maintenance access) ask: who can intercept this? What can they do with it? What’s the worst-case outcome? Document the answers and design against them.

Use platform security features. Modern microcontrollers (STM32, ESP32, NXP i.MX, etc.) include hardware security features: secure boot, flash encryption, secure key storage, TrustZone. These are not expensive to use — they’re included in the silicon. They are almost always underutilised because teams don’t allocate time to configure them.

Treat credentials like they will leak. Hard-code nothing. Use per-device certificate provisioning. Store secrets in secure elements, not in firmware or on-disk. Assume any secret embedded in a shipped device is accessible to a motivated attacker with physical access.

Plan the update story at architecture time. The OTA update mechanism — how updates are delivered, signed, verified, and applied — needs to be designed into the system from the start. It is significantly harder to retrofit a secure update mechanism into a device that shipped without one.

Penetration test the full stack. Device hardware, firmware, the update mechanism, the cloud API, and the mobile or web interface. Each layer has different attack surfaces and requires different testing techniques. Most IoT security issues that make the news were findable with a basic pentest.

Building a connected product and want a second opinion on your security architecture? Write to us at hello@cimpleo.com — we’ve shipped IoT products and know where the real risks are.