Security at the edge: what most IoT architectures get wrong

The default IoT security pattern: HTTPS for transport, API keys for authentication, a cloud-side firewall. This is wrong in ways that will eventually be expensive.

The threat model is different

Web security assumes the client is untrusted. IoT inverts this — your devices are physical objects that can be stolen, tampered with, cloned. The question shifts from "how do we prevent unauthorised requests?" to "how do we prevent a compromised device from compromising the fleet?"

Certificate-based authentication, not API keys

API keys are secrets stored in firmware. Firmware can be extracted. Device certificates with a proper PKI give you per-device identity that can be revoked individually — revoke device 847 without affecting the other 1,199.

Mutual TLS

Standard TLS proves the server's identity. Mutual TLS proves both sides. In an IoT context, mTLS means a rogue device can't successfully connect to your backend even if it knows the right endpoint. AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all support this natively.

Firmware signing and secure boot

Signed firmware with secure boot means a device will refuse to run firmware not signed by your key. This doesn't make your update infrastructure invulnerable — it makes a successful attack unable to achieve its goal.

The segmentation principle

An industrial sensor node has no reason to initiate outbound connections to arbitrary internet endpoints. Strict egress rules dramatically reduce the blast radius of a compromised device.