Common risks in IoT deployments

Key takeaways

You now understand identity, encryption, and provisioning — the building blocks of IoT security. But knowing how security works in theory is not enough; you also need to know how it fails in practice. This page walks through the most common security risks in real-world IoT deployments, why they happen, and what you can do to prevent them.

What you'll learn

Why IoT devices face risks that traditional IT systems don't

IoT devices combine challenges that data-center systems avoid:

• They are physically accessible, deployed in the field, on poles, in enclosures someone can open.
• They are resource-constrained with limited CPU, memory, and power for security software.
• They are long-lived and expected to run ten to fifteen years, far outlasting typical software support cycles.
• They are deployed at scale where one vulnerability can affect thousands or millions of identical devices.

How physical tampering happens and how to lock it down

When an attacker gets hold of a device, they usually want three things: to pull a removable SIM and clone your network identity, to find active debug ports (JTAG or UART) that open a pipeline into memory and code, and to dump unencrypted flash to reverse-engineer your logic and steal hardcoded credentials. The four-part defense:

• Move to MFF2: A soldered SIM means no slot and no card to extract.
• Sanitization: Disable debug interfaces before the device leaves the factory.
• Flash encryption: Encrypt storage so a physically removed chip is unreadable.
• Secure boot: Ccheck the firmware's digital signature before executing any code; if it has been tampered with, the device refuses to boot.

Why insecure firmware updates are a serious attack vector

Firmware updates patch vulnerabilities, but an insecure update mechanism lets an attacker take control of every device. Things go wrong with unsigned packages (the device cannot verify the source), unencrypted download channels (an attacker can intercept and modify updates), and no rollback (a bad update bricks the device). Mitigations: sign all firmware and verify signatures before installation, download over encrypted channels (TLS/DTLS), implement rollback to the last known-good firmware, and use differential (delta) updates to reduce the data transferred and the attack window.

How to eliminate weak or default credentials

One of the most common and most preventable failures is shipping devices with factory-default passwords like "admin/admin" that are never changed. Attackers scan the internet for these known defaults. Mitigations: generate unique credentials per device at manufacturing, force credential rotation on first boot, prefer certificate-based authentication (mTLS) over passwords, and never hardcode credentials in firmware. Use the hardware root of trust for key storage.

Why network segmentation and encryption protect the fleet

On a flat network where all devices share the same segment, compromising one device can expose the entire fleet and even backend systems. This is especially dangerous when IoT devices share networks with operational technology (OT) or enterprise IT. Segmentation mitigations: use private APNs to route traffic through an isolated, carrier-managed network; disable unnecessary channels by switching to "packet switched only" mode to remove the SMS and voice attack surface; lock modem frequency bands to known-good bands to avoid rogue base stations; and use static IP assignment to enforce strict firewall allowlists at the perimeter. Encryption is the partner control: some deployments still transmit plaintext because developers skip TLS/DTLS during prototyping, use protocols without encryption by default, or disable it to save battery. Even on a private APN, encryption is essential because network-level isolation does not protect against a compromised base station or core network element, so enforce TLS 1.2 or higher for TCP, use DTLS for UDP, implement certificate pinning, and configure your backend to reject unencrypted connections.

Why lifecycle management and defense-in-depth tie it all together

Devices are often deployed and forgotten, but security is not a one-time event. Neglect shows up as expired certificates (devices lose connectivity or fall back to insecure modes), unpatched firmware (known vulnerabilities pile up over years), and missing end-of-life planning (credentials never revoked, data never wiped). Mitigations: monitor certificate expiration and automate renewal, build secure over-the-air (OTA) update capability from day one, plan decommissioning during initial design, and maintain an inventory of deployed devices and their firmware versions. Underpinning all of this is defense-in-depth: no single layer is sufficient, so a compromised application certificate can be contained by network isolation and a network breach can be contained by endpoint encryption. When the endpoint, network, and application layers each provide independent controls, a failure at one layer does not cascade into a complete compromise.

Lesson 6.4 Self-assessment

Frequently asked questions