IoT Security: Secure Boot, Provisioning & Device Hardening

IoT Security

IoT security differs from application security in one decisive way: the attacker has the device. They can buy one, open it, read the flash, probe the buses, glitch the power rail, and take as long as they like — offline, undetected, with no rate limiting. Anything embedded in the firmware is effectively public, and any secret shared across the fleet is one extracted device away from compromising all of them.

The consequences of failure are also unusual. A compromised device is a foothold on the owner's network, a node in a botnet, and sometimes a physical hazard. Mirai demonstrated the scale in 2016 by doing nothing more sophisticated than trying default credentials against internet-exposed cameras and routers, and it produced the largest DDoS attacks recorded at the time. Devices also live for years or decades, so a vulnerability shipped today needs a working update path for its entire deployed life.

TL;DR

Assume physical access. Firmware can be extracted, buses probed, and debug ports found.
Per-device secrets, always. A shared key or default password means one extraction compromises the fleet.
Secure boot — the device runs only signed firmware. Without it, every other control is bypassable.
Flash encryption protects secrets and IP at rest; pair it with a hardware-backed key.
TLS everywhere, with certificate validation actually enabled. Constrained devices can afford it.
No default passwords — this is now a legal requirement in several jurisdictions, not just good practice.
A working OTA path is a security control, and the most important one.
Disable debug interfaces (JTAG/SWD) in production, or gate them behind authentication.
Minimize attack surface: closed ports, no unnecessary services, no debug backdoors, no hidden accounts.

The Threat Model

Cost matters when prioritizing. Reading an unprotected SPI flash chip costs about ten dollars and five minutes; power glitching costs a few hundred dollars and some skill; decapping and microprobing costs tens of thousands. Defend against the cheap attacks universally, and against the expensive ones only when the asset justifies it.

Quick Example

Provisioning a device with a unique identity — the foundation everything else rests on:

The difference is operational as much as cryptographic: with per-device credentials you can revoke one compromised device. With a shared secret, your only remedy is a fleet-wide firmware update — assuming the compromise didn't break the update path.

Core Controls

Secure boot

Secure boot establishes a chain of trust from immutable ROM through every stage of firmware:

Without it, an attacker with physical access replaces the firmware entirely, and your application-level signature checks never execute because your application never runs. Every other software control assumes secure boot underneath it.

Both secure boot and flash encryption are typically one-way eFuse operations — enable them and they cannot be disabled. Test the entire process on sacrificial hardware before enabling in production, and keep an unfused development fleet, because a mistake here bricks the unit permanently.

Key storage

A secure element is a few dollars and the most cost-effective security upgrade available for a product handling real value: the private key is generated inside the chip, cannot be read out by any interface, and signing happens on-chip. Firmware extraction yields nothing usable.

Transport security

Disabled certificate validation is the most common IoT TLS mistake, usually introduced during development to make something work and never reverted. It reduces TLS to encryption against a passive observer while providing no protection against an active one — which is the threat that matters.

TLS on a constrained device costs 30–60 KB of flash, RAM for handshake buffers, and handshake time and energy. Mitigate with session resumption, hardware crypto acceleration (present on the ESP32 and most modern parts), and PSK cipher suites where a full PKI is impractical. Cost is not a justification for shipping cleartext.

Certificate lifetime is a genuine planning problem: a device deployed for ten years will outlive most CA certificates. Plan for certificate rotation over the air from the start, or you'll have a fleet that stops connecting on a known date.

Attack surface reduction

Every disabled interface is an entire attack class removed. The debug UART is the most commonly forgotten — a serial console that drops into a shell is a complete bypass of everything else, and it's often left enabled because it was useful during development.

Secure defaults

Regulations now mandate what was already best practice:

No universal default passwords. Either a unique per-device credential printed on the label, or mandatory setup on first use.
Fail closed. A device that can't verify a server should refuse to proceed, not fall back to plaintext.
Minimum privilege. Services run unprivileged; on Linux devices, read-only root with a separate writable data partition.
A published vulnerability disclosure policy and a stated support period.

Fleet-Level Security

Provisioning

Getting a unique identity onto each device is a manufacturing problem as much as an engineering one:

The pattern that avoids the worst risks is on-device key generation: a key that never exists outside the chip cannot be leaked by a contract manufacturer, a provisioning database, or a compromised build server. Where devices must be provisioned in bulk, treat the provisioning infrastructure with the same care as a signing key.

Revocation and rotation

Assume some devices will be compromised, cloned, or stolen. You need the ability to revoke one device's credentials without touching the rest, rotate certificates before expiry, and quarantine devices exhibiting anomalous behavior. This is a backend capability, and it's much harder to add after a million devices are deployed.

Fleet monitoring

Watch for what a compromised device looks like from the server: a spike in connection attempts, publishing to topics it shouldn't, a firmware version that doesn't match any release you built, credentials used from an unexpected geography, or many devices sharing one identity simultaneously — which reveals a cloned or extracted key. See Monitoring and Alerting.

OTA as a security control

A working update path is the most important security capability you can ship, because it's the only one that fixes problems you haven't found yet. It must itself be secure: signed images, on-device verification, anti-rollback protection, and a rollback path if an update fails.

Regulation

The compliance landscape moved from voluntary to mandatory over the last few years, and the requirements are largely the same everywhere:

The common core across all of them: no default passwords, a vulnerability disclosure process, a stated minimum support period with security updates, secure communication, secure storage of sensitive data, and minimized attack surface. Building to ETSI EN 303 645 satisfies most of the others' baseline.

The support-period requirement deserves attention because it's a business commitment, not just an engineering one: you must state how long you'll ship security updates, and then actually do it.

Best Practices

Give every device a unique identity

Per-device keys or certificates, generated on-device where the hardware allows. This single decision determines whether a compromise is one device or your entire fleet, and whether revocation is possible at all.

Enable secure boot and flash encryption before production

They're one-way fuse operations, so the process must be validated on sacrificial units. Devices shipped without them can never be retrofitted, which makes this a hard deadline rather than a backlog item.

Verify certificates — and test that verification actually happens

Write a test that points the device at a server with a wrong certificate and asserts the connection fails. Disabled validation is almost always introduced deliberately during development and forgotten, and only a negative test catches it.

Assume firmware will be extracted

Never embed a shared secret, an API key, a private key, or a credential that matters. If you must ship something sensitive, put it in a secure element or eFuse-backed encrypted storage. Threat-model your firmware image as a public document.

Ship OTA on day one and keep it working

It's the mechanism by which every future vulnerability gets fixed. Verify after every release that the update path still functions — a firmware version that breaks its own updater is unrecoverable.

Minimize what's listening

Every open port, service, and console is attack surface. Production builds should have debug interfaces compiled out, not merely disabled by a runtime flag someone can toggle.

Use memory-safe practices in firmware

Buffer overflows in a parser handling network input are remote code execution on a device with no MMU and no ASLR. Bound every copy, validate every length field from the wire, and consider Rust for new parsing and protocol code specifically.

Log security events to the fleet backend

Failed authentication, unexpected reboots, failed update attempts, and configuration changes. A compromised device usually looks unusual from the server before anyone notices anything locally.

Common Mistakes

A shared credential across the fleet

Disabling certificate validation

Leaving debug interfaces enabled

Trusting network input without bounds checking

Shipping without an update path

A default password

FAQ

How much security does my device actually need?

Scale it to what a compromise costs. A hobby sensor on a home network warrants TLS, no default password, and OTA. A commercial product warrants secure boot, per-device identity, flash encryption, and a monitored fleet backend. A device controlling physical processes or handling personal data warrants a secure element, formal threat modeling, and third-party assessment. The ETSI EN 303 645 baseline is a reasonable floor for anything sold to consumers — and increasingly a legal one.

Can a constrained microcontroller do proper cryptography?

Yes. Modern MCUs have hardware AES, SHA, and often ECC acceleration, plus a true random number generator. TLS 1.3 with ECDHE runs comfortably on an ESP32 or an STM32 with a crypto peripheral. The costs are flash for the TLS stack, RAM for handshake buffers, and energy for the handshake — all manageable with session resumption and sensible connection intervals. On genuinely tiny parts, a secure element offloads the cryptography for a couple of dollars.

What's the single most important control?

A working, secure OTA update path. It's the only control that addresses vulnerabilities you don't know about yet, and every other measure eventually depends on being able to ship a fix. Second is per-device identity, because it determines whether one compromise is contained.

How do I protect against physical attacks?

Layer by cost. Cheap and effective: disable debug ports, enable flash encryption, use a secure element, and don't embed secrets. Moderate: tamper detection switches, potting or conformal coating, and sensors that zeroize keys on intrusion. Expensive attacks — decapping, microprobing, sophisticated side-channel analysis — are only worth defending against for high-value targets, and the defense is certified secure hardware rather than firmware measures.

How long do I need to support a device?

The EU CRA and UK PSTI require you to declare a support period and honor it; five years is a common commitment for consumer devices, and industrial equipment often needs far longer. Plan for it technically: certificate expiry, TLS versions being deprecated, cloud API changes, and the possibility that the update server outlives the product line. A device that stops connecting because a certificate expired is a support and reputational problem regardless of regulation.

What about devices with no connectivity?

They still need physical hardening — secure boot, encrypted flash, disabled debug ports, no default credentials — because the local attack surface is the same. What changes is the update mechanism: local update via USB or a technician's tool, with the same signing and rollback discipline. "Not connected" reduces remote attack surface; it doesn't remove the need for security, and it makes updates harder rather than unnecessary.