Securing IoT: Threat Models, Secure Boot, and TLS in Constrained Devices

IoT security has a reputation for being either nonexistent or overwhelming. The truth is closer to: there is a finite list of things to do, the first five of them prevent most real attacks, and almost no team finishes the list before shipping.

This is the order we apply it on every connected product.

Start with a real threat model

Not the formal multi-page artifact. A whiteboard list. The questions:

• Who would want to attack this device, and why? (Hobbyist tinkering, competitor extracting trade secrets, large-scale botnet, individual targeted attack.)
• What can they reach? (Network, USB port, JTAG header, the device on a shelf with hand tools.)
• What do they get if they win? (Customer data, lateral movement into a home network, ability to ship malicious firmware to other devices, physical safety risk.)

The answers shape every other decision. A consumer plant-watering sensor and an insulin pump need very different bars.

Eliminate default credentials forever

The single highest-leverage IoT security mistake is shared default passwords or factory keys. The fix:

• Per-device credentials, generated at provisioning, never identical across two devices.
• No reachable services with default passwords in production firmware. Disable the bootloader serial console, factory test endpoints, and debug shells, or gate them behind device-specific keys.

If your product can be compromised by a botnet running admin / admin against the IP, no other security work matters.

Lock down the boot chain

Secure boot is the foundation. Every modern MCU family — ESP32, STM32, Nordic, NXP, Silicon Labs — supports it. Use it.

The chain:

1. The chip’s ROM verifies the signature of the bootloader against a public key stored in fuses.
2. The bootloader verifies the signature of the application image.
3. The application verifies the signature of any OTA payload before writing it to flash.

Break any link and the rest is theater. The signing key lives in an HSM or air-gapped signer, not in your CI environment.

Encrypt flash if it matters

If an attacker with physical access can read out flash, they can study your firmware, extract embedded credentials, or clone the device. Flash encryption — built into ESP32 and most modern MCUs — closes this. The cost is one-time provisioning complexity and the inability to recover devices with a corrupted key. The benefit is reverse-engineering deterrent.

For consumer devices where physical compromise is low-stakes, flash encryption is optional. For industrial or medical devices where reverse engineering yields real attacker leverage, it is mandatory.

TLS, even on constrained devices

“Too constrained for TLS” is rarely true in 2026. ESP32, STM32, and Nordic SDKs all ship mbedTLS. RAM and flash budgets are real but manageable.

The minimum:

• TLS 1.3 with a modern cipher suite (or 1.2 if your library forces it).
• The device verifies the server certificate against a pinned root CA. No verify_none in production.
• The server verifies a per-device client certificate. Mutual TLS is the default for IoT, not the exception.

The traps:

• Time. TLS verification needs a roughly correct clock. Devices that boot without a clock need to fetch time over an unauthenticated channel before TLS works — handle this carefully or use an offline-tolerant scheme.
• Memory. The TLS handshake is the peak memory event. Profile it.

Per-device identity, rotated

Every device gets a unique X.509 certificate, provisioned at manufacturing. The private key never leaves the device. Certificates have an expiry — six months to a year — and the device renews them through an authenticated channel before they lapse.

This is more work than a shared API token but turns a fleet-wide compromise into a per-device incident. AWS IoT, Azure IoT Hub, and Google Cloud IoT all support this directly. So do open-source brokers if you self-host.

Disable what you do not need

In production firmware, every reachable service is a possible vulnerability. Audit:

• Debug interfaces (UART, JTAG, SWD) — disabled or password-protected.
• Network services — only what the device actually uses for telemetry and control.
• mDNS, SSDP, UPnP — usually unnecessary on industrial devices and often a leak vector on consumer ones.

The principle: a service that exists is a service that has bugs.

Have an incident response plan

Eventually, something will go wrong. A bug is found. A key leaks. A customer’s device is compromised.

The plan needs to answer:

• How do you push an emergency firmware update? (See our OTA post — your OTA pipeline is your incident response tool.)
• How do you revoke a compromised device’s credentials? (Per-device certificates and a revocation list.)
• How do you notify customers? (Comms template, regulatory obligations, user-facing in-app message.)
• How do you forensic-analyze a compromised device? (Logs, telemetry retention, crash dumps.)

Write this on day one. Test it on day thirty. The first time you need it should not be the first time you read it.

What “good enough” looks like for v1

For a typical consumer-grade connected product, before shipping:

• Per-device credentials and keys.
• Secure boot enabled.
• TLS with mutual authentication and certificate pinning.
• Signed OTA with rollback.
• Debug interfaces disabled.
• Documented incident-response runbook.

The first three are non-negotiable. The next two close 80% of remaining attack surface. The last one keeps you out of headlines on a bad day.

If you would like a security review before launch, we offer them as fixed-scope engagements.