IoT Security Fundamentals

The four foundational controls

Per-device identity

The default IoT security model — every device shares the same hardcoded key — is the worst possible. An attacker extracts the key from one device, possibly one they bought legitimately, and can now impersonate any device on the fleet and decrypt any traffic from any device.

The right model: each device has its own unique cryptographic identity, typically:

• A per-device certificate signed by a manufacturer or operator CA.
• The private key stored in tamper-resistant hardware (secure element, TPM, ARM TrustZone) where it cannot be extracted.
• Server-side identity database mapping certificate to device record.

Provisioning is harder, but the security model is fundamentally sound: extracting one device's key compromises only that device, and revoking its certificate isolates the damage.

Encrypted transport

Every protocol layer must encrypt. For IP-based IoT, that's TLS (or DTLS for UDP-based protocols like CoAP). For radio protocols, it's the protocol's native encryption (LoRaWAN AES-128, BLE LE Secure Connections, Zigbee link keys, etc.). Plaintext is acceptable only on truly isolated networks where the threat model genuinely doesn't include eavesdroppers.

For resource-constrained devices, modern algorithms reduce the overhead:

• AES-128-CCM/GCM — fast, low memory.
• ChaCha20-Poly1305 — fast in software on devices without AES hardware.
• ECC over RSA — much smaller keys for equivalent security.

Signed firmware updates

A device that cannot be updated is permanently vulnerable. A device that can be updated insecurely is permanently exploitable. Both fail; the only sustainable approach is signed, atomic, fault-tolerant updates.

Requirements:

• Firmware images signed with a private key the device verifies against a public key stored in immutable read-only memory.
• Anti-rollback protection — once updated to version N+1, the device refuses to downgrade to version N (otherwise vulnerabilities patched at N+1 can be reintroduced by forcing a downgrade).
• A/B partitions — install the new firmware to a separate partition; only switch to it once verified. If anything fails, fall back to the working old firmware.
• Resumable updates — devices that lose power or connectivity mid-update don't brick.

Network isolation

IoT devices belong on their own network segment with strict firewall rules. The pattern is identical to business network segmentation applied to IoT:

• Dedicated IoT VLAN with its own subnet.
• Default-deny rules between IoT and other zones.
• Allowlist only the specific cloud endpoints each device needs to reach.
• Block IoT-to-IoT communication unless explicitly required.
• Block inbound from the internet entirely (devices initiate connections, not receive them).

The blast-radius reduction is enormous. A compromised IoT device is contained to its segment.

Common IoT security failures

• Default credentials. "admin/admin" on web management interfaces is still common. Mirai botnet used exactly this.
• Hardcoded fleet-wide keys. One extraction compromises everyone.
• Open management ports. Telnet, SSH, HTTP on internet-exposed devices.
• No firmware updates ever. Vendor abandons the product; security holes accumulate.
• Cleartext protocols. Telemetry over plaintext HTTP, MQTT without TLS.
• Trust-on-first-use with no verification. Pairing accepts whatever cert is presented; MITM trivial.
• Reusable session tokens. One token captured replays forever.

Physical security

IoT devices are often physically accessible to attackers. Mitigations:

• Secure elements for keys. Even with the device opened, the key isn't extractable.
• Disabled debug interfaces. JTAG/SWD/UART blown or password-protected.
• Tamper detection. Optional — device wipes secrets on case open.
• Memory protection. Firmware encrypted at rest; secrets in protected regions.

Perfect physical security is impossible. The goal is to make extraction expensive enough that it doesn't scale to the whole fleet.

Privacy considerations

Many IoT devices collect data far beyond what their stated purpose requires. The principle of least data: collect only what's necessary, retain only as long as needed, expose only what the user controls. Specific concerns:

• Always-listening voice assistants and what they buffer.
• Smart cameras and where footage is stored.
• Health/fitness data leaving the device.
• Location reporting cadence and resolution.

Secure provisioning

Getting initial credentials onto a device safely is its own problem. Approaches:

• Factory injection. Each device gets unique credentials baked in at manufacture. Most secure; requires manufacturer cooperation.
• User-initiated pairing. Device generates credentials on first power-on; user pairs via a trusted channel (Bluetooth, QR code, app).
• Zero-touch provisioning. Device contacts a provisioning service using a manufacturer-installed bootstrap credential, receives operational credentials.

Disclosure and patch lifecycle

Vendors who handle vulnerabilities well have:

• A documented security contact for researchers.
• Clear policies on coordinated disclosure timing.
• Reliable update delivery to the entire deployed fleet (not just future devices).
• Published support lifetimes — "we will provide security updates until at least YYYY."

Buying from vendors without these is taking on uninsured risk for the lifetime of the deployment.

Frequently Asked Questions

Why is IoT security harder than regular IT security?

Three reasons. First, devices are resource-constrained — limited CPU, memory, and battery make strong cryptography expensive. Second, deployment lifetimes are long — devices deployed today may still be running in 15 years, well past vendor support. Third, physical access is often unrestricted — an attacker who can pick up a device can extract firmware, probe debug ports, and analyze hardware. Each constraint shapes what security looks like.

What is per-device identity?

Each device having its own unique credentials (certificate or key pair) rather than sharing a single key across the fleet. With per-device identity, a compromised device exposes only itself; revoking its certificate isolates the damage. Without it, a single key extracted from one device unlocks the entire fleet.

Why are firmware updates so important?

Because vulnerabilities will be discovered after deployment. Devices that cannot be updated remain vulnerable for their entire lifetime. Updates must be cryptographically signed (so attackers cannot push malicious firmware), atomic (so a failed update doesn't brick the device), and reliable (so the update mechanism itself isn't the failure mode that prevents fixing the device).

What does network isolation buy you?

Limits blast radius when a device is compromised. A vulnerable smart camera on its own VLAN can be compromised but cannot reach the corporate file server. A vulnerable camera on a flat home network can pivot to laptops, NAS, and any other device. Isolation is one of the cheapest controls — usually free, just configuration — with one of the largest impacts.

How do I revoke a compromised device?

Through the same identity system you used to provision it. If devices have per-device certificates, you revoke the certificate; the network refuses connections from it. If devices share keys, revocation requires rotating the shared key across the entire fleet — expensive and slow. The choice you make on provisioning determines what revocation looks like.