The first thing to understand about IoT security is what makes IoT different from IT. An IoT device runs on a budget — of memory, of power, of CPU, of unit cost. A smart sensor that has to last five years on a coin battery cannot wake up, complete a TLS handshake, validate a cert chain, and reply, every time something happens. The protocols it uses, the cryptography it can afford, and the update model it can support are all shaped by those constraints.
The constrained-device spectrum
"IoT" covers everything from a $2 disposable sensor to a $5,000 medical imaging device. RFC 7228 formalizes three tiers based on RAM and code memory — you'll see these numbers in vendor specs and security standards.
| Class | RAM | Flash | Power | Realistic example |
|---|---|---|---|---|
| Class 0 | < 10 KB | < 100 KB | Coin battery | Disposable temperature beacon, BLE tag. |
| Class 1 | ~10 KB | ~100 KB | Coin or AA | Door sensor, smart bulb, smoke alarm. |
| Class 2 | ~50 KB | ~250 KB | Wall power or large battery | Smart thermostat, camera, voice assistant. |
A typical TLS 1.3 implementation needs roughly 50-100 KB of code and tens of KB of RAM for buffers and session state. That eliminates Class 0 entirely and stresses Class 1. So the industry built lighter alternatives: pre-shared-key (PSK) modes of TLS, datagram TLS (DTLS) for unreliable links, and entirely different application protocols (MQTT, CoAP) that aren't HTTP at all.
The wireless stacks below WiFi
WiFi is too power-hungry for most IoT. Battery-powered devices use lower-power protocols at the cost of throughput. The four you must know:
Zigbee
Mesh network on 2.4 GHz (sometimes 868/915 MHz). Designed for sensors and lighting. Hue bulbs, SmartThings sensors, many home automation systems. Up to ~250 kbps. Mesh routing — bulbs forward each other's packets.
Security: AES-128 symmetric. Network key shared by the whole network. Famous attack: Z-Shave-style key extraction during pairing. Trust-center commissioning with install codes mitigates.
Z-Wave
Star network (with optional repeaters) on sub-GHz (US: 908 MHz). Better wall penetration than Zigbee, but lower data rates. Common in alarm systems and "professionally installed" smart home.
Security: Z-Wave S2 (since 2016) uses ECDH for pairing. Earlier S0 had a famous key-extraction window (Z-Shave, 2018). Modern devices ship with S2.
Thread
IPv6-based mesh on the same radio as Zigbee, but with a real IP stack (6LoWPAN). Backed by Google/Nest, Apple, Samsung. The underlying transport for Matter. Self-healing mesh, ~250 kbps.
Security: mTLS (DTLS 1.3) for commissioning. Per-device certificates. The first IoT stack designed from scratch in the post-Mirai era; security is much better.
LoRaWAN
Long-range, low-power (kilometers of range). Sub-GHz. Designed for utility metering, agriculture, asset tracking. Very low data rates (hundreds of bytes per day). One gateway covers a city block.
Security: AES-128 with per-device NwkSKey + AppSKey. Often poorly deployed with shared keys or weak random session generation. LoRaWAN 1.1 fixed many issues; 1.0.x deployments are still in the field with their issues.
Two more you'll hear about: BLE Mesh (which we covered last page — competes with Zigbee for home automation), and NB-IoT / LTE-M (cellular IoT, useful where range and existing cell coverage matter more than power).
Application protocols: MQTT and CoAP
Above the radio, IoT doesn't usually speak HTTP — HTTP is fat. Two lighter application protocols dominate:
MQTT
Devices publish messages to topics on a broker; subscribers receive them. Topics are hierarchical strings like home/kitchen/temperature. Tiny header overhead (2 bytes). One broker can fan out to thousands of subscribers.
Security: MQTT itself has username/password auth and optional TLS. Default deployments often run unencrypted on port 1883 with no auth. Shodan finds tens of thousands of open MQTT brokers. The MQTT-over-TLS port is 8883.
CoAP
Looks like HTTP (GET/PUT/POST/DELETE on URIs) but runs over UDP. ~10-byte header. Designed for devices that can't keep TCP sessions open. Supports multicast. Specified in RFC 7252.
Security: Uses DTLS (datagram TLS), commonly with PSK rather than full cert validation due to memory constraints. Often deployed unauthenticated on local networks.
Matter · the standards consolidation
For over a decade, smart-home IoT was fragmented: a Hue bulb spoke Zigbee, a Sonos speaker spoke WiFi, a Nest thermostat spoke its own thing, and getting any of them to work together required a hub with seven radios in it. Matter (originally "Project CHIP," launched October 2022) is the industry's attempt to fix this.
- Transport: Matter runs over either WiFi or Thread. Discovery via mDNS/Bluetooth.
- Security: Every Matter device ships with a certificate signed by the Matter Distributed Compliance Ledger (DCL). Commissioning uses Password-Authenticated Session Establishment (PASE), then upgrades to certificate-authenticated session establishment (CASE).
- Local-first: Devices communicate directly on the LAN; cloud is optional, not required.
- Backed by: Apple, Google, Amazon, Samsung, plus the Connectivity Standards Alliance (formerly Zigbee Alliance).
Matter doesn't replace Zigbee or Z-Wave overnight — existing devices keep working — but new smart-home products in 2024+ are launching as Matter-native, often with backwards compatibility to older protocols via the hub. This is the first IoT consolidation that has a chance of actually happening.
Why "just put a cert on it" doesn't work
Every IoT security guideline says use device certificates. In practice this is much harder than it sounds.
- Storage. A cert chain is 2-4 KB. Many Class 0 devices have less than that of free flash.
- Validation. Full cert-chain validation requires storing a root CA and supporting ASN.1 parsing, which is heavyweight code.
- Time. Cert validation requires a reliable clock to check NotBefore/NotAfter. Many IoT devices have no RTC and no NTP path.
- Rotation. Certs expire. If a device can't be updated, an expiring cert is a hard outage. Long expiration windows (10+ years) become normal — which weakens the model.
- Manufacturing. Each device needs a unique cert provisioned at factory, which adds cost. Vendors who skip this end up with identical pre-shared keys across their entire fleet, defeating the purpose.
The update problem
Industry consensus is that IoT vulnerabilities are inevitable; the real test is whether vendors can ship fixes. OTA (over-the-air) updates are non-trivial:
- Bandwidth budget — a 500 KB firmware update over LoRaWAN at 50 bps takes ~22 hours of continuous transmission.
- Reliability — the device must be able to roll back if the update bricks it, which means dual-bank flash, which means more flash.
- Authenticity — updates must be signed, which means storing a verification public key, which means key rotation eventually.
- Vendor lifetime — a 10-year medical device may outlive its manufacturer. What happens then?
The 2022-2024 wave of IoT regulation (EU CRA, UK PSTI, NIST IR 8425) all require minimum support windows from vendors. We'll come back to those defenses on the next page.
IoT is constrained by physics: memory, power, cost, lifespan. The protocols that make economic sense at scale (Zigbee, Z-Wave, LoRaWAN, MQTT, CoAP) made different security trade-offs than enterprise IT. "Just use TLS" doesn't fit on a smart bulb. The industry response — PSK modes, DTLS, Matter's hybrid commissioning — works but assumes the vendor cares enough to implement it.
The single most useful framing for IoT security work: identify which protocol the device speaks, what crypto that protocol supports, and whether the vendor enabled it. The named attacks on the next page mostly target devices that didn't.
Sources
- Bormann, C., Ersue, M., & Keranen, A. (2014). RFC 7228: Terminology for constrained-node networks. IETF. https://www.rfc-editor.org/rfc/rfc7228
- Connectivity Standards Alliance. (2024). Matter 1.3 specification. https://csa-iot.org/all-solutions/matter/
- Shelby, Z., Hartke, K., & Bormann, C. (2014). RFC 7252: The Constrained Application Protocol (CoAP). IETF. https://www.rfc-editor.org/rfc/rfc7252
- OASIS. (2019). MQTT version 5.0. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
- Vidgren, N., Haataja, K., Patino-Andres, J. L., Ramirez-Sanchis, J. J., & Toivanen, P. (2013). Security threats in ZigBee-enabled systems. HICSS. https://ieeexplore.ieee.org/document/6480181
- LoRa Alliance. (2020). LoRaWAN 1.0.4 specification. https://lora-alliance.org/resource_hub/lorawan-104-specification-package/