Shipping a connected device is the start of a relationship that may last a decade. During that time the device will need new firmware to fix bugs and vulnerabilities, configuration changes, new credentials when old ones expire, and eventually a controlled retirement. Doing this for ten devices in a lab is easy. Doing it for a hundred thousand devices in customers’ homes and inside machines, over networks you do not control, is device management.
The capability that matters most is the over-the-air update. Every security regulation now in force assumes that devices can be patched remotely, and a fleet that cannot be updated is a fleet whose first serious vulnerability is permanent. This guide covers the full device lifecycle and then goes deep on how OTA is done safely.
The lifecycle
A device passes through a predictable sequence of states, and each needs tooling.
Manufacturing. The device receives its identity: a unique serial number and, ideally, a cryptographic key pair with a certificate signed by the manufacturer’s PKI. Keys generated inside a secure element never leave the chip. Doing this on the production line, rather than in the field, is what makes later steps secure.
Provisioning. Provisioning is how the back end comes to know and trust the device. With factory certificates it is automatic: the device connects, presents its certificate, and the platform registers it in the device registry under the right fleet. Without factory credentials, a bootstrap token is exchanged for a real identity, which is weaker and harder to scale.
Commissioning. Commissioning is the site-specific setup: assigning the device to a location, joining it to the local network, calibrating sensors, linking it to the asset it monitors. Installer apps and QR codes are the usual tools.
Operation. The device reports, receives configuration and commands, and sends heartbeats so that the platform knows it is alive. Fleet management views show status across groups, and device shadows hold desired versus reported configuration so that changes apply even to devices that are asleep.
Maintenance. Firmware updates, certificate rotation and configuration changes, discussed below.
Decommissioning. The device is retired: credentials revoked, data retention applied, and storage wiped so that a device sold second hand does not carry the previous owner’s keys. This step is routinely forgotten.
Monitoring the fleet
Operational visibility is the daily use of device management. The basic signals are connection status, last-seen time, firmware version, battery life, signal quality and error counters. Devices that have gone silent are the first thing to look for, and only the pattern across the fleet tells you whether a network outage, a bad update or a hardware batch is responsible.
Remote diagnostics such as pulling logs or running a self-test are commands, and need the same authorization and audit discipline as any other.
Over-the-air updates
An OTA update replaces the firmware on a device without physical access: the platform announces a new image, the device downloads it, verifies it, writes it to flash memory, and reboots into it. Every step hides a way to brick the device, and the design is about eliminating those ways.
Image verification
The device must verify the image before installing it. The image is signed with the manufacturer’s private key; the device holds the corresponding public key and checks the signature and the hash. This stops an attacker who controls the network, or even the update server, from installing malicious firmware. Together with secure boot, which verifies the image again at every power-on, it establishes a root of trust that runs from hardware to application.
Anti-rollback protection, where the device refuses an image with a lower version than the one running, stops an attacker from reinstalling old firmware with known vulnerabilities.
Surviving failure
The classic protection is dual-bank (A/B) flash: the device keeps two firmware slots, writes the new image to the inactive slot, and the bootloader switches to it on reboot. If the new firmware fails to confirm itself as healthy within a set time, a watchdog timer triggers a reboot and the bootloader falls back to the old slot. This doubles the flash needed, a real cost on small microcontrollers, which is why some constrained devices use a single slot with a small recovery image instead.
Power loss during the write is handled by writing the whole image before changing the boot pointer, and download interruptions by resumable, chunked transfers with per-chunk checksums. “Healthy” must be defined concretely; a common definition is that the new firmware connects to the platform and reports its version within a few minutes.
Delivering the image
The transport depends on the link. Wi-Fi and cellular devices usually download over HTTPS from a URL supplied in an MQTT command, with a short-lived signed URL so that the image store is not public. For devices behind a gateway on Zigbee or Thread, the gateway downloads once and distributes locally. For LoRaWAN, where downlink capacity is tiny, updates use multicast and fragmentation extensions and take a long time, which is a reason to get LoRaWAN firmware right the first time.
Delta updates, which send only the difference between the old and new image, cut download size dramatically and are worth the added complexity on metered or slow links. LwM2M defines a standard object for firmware updates that many constrained-device stacks implement.
Rolling out
Never update the whole fleet at once. A staged rollout sends the image to a small canary group first, waits for them to confirm health, then expands in steps, with automatic pause if the failure rate rises. Groups can be chosen by hardware revision, region or customer. A rollback plan should exist before the rollout starts, and the platform should be able to target a previous version just as easily as a new one.
Devices with a job to do should update during a maintenance window, and battery-powered devices only when charge is sufficient to finish.
Configuration and credentials
Not every change needs new firmware. Reporting intervals, thresholds, endpoints and feature flags should be configuration, delivered through the device shadow or a configuration object so that the device picks them up on its next check-in. Keeping configuration separate from code makes the firmware simpler and the update rarer.
Certificates expire, and a fleet whose certificates all expire on the same day is an outage waiting to happen. Rotation should be automated, staggered and tested, with recovery if it fails part way. The device identity guide covers certificate handling.
Choosing or building the tooling
Most IoT platforms offer registry, shadow, jobs and OTA features, and open-source update frameworks exist for Linux-based devices. Check whether the tool supports staged rollouts with automatic pause, delta updates, your device’s bootloader and flash layout, and gateway-mediated distribution. Building OTA from scratch is reasonable only for teams with embedded security expertise.
Where to go next
- IoT platforms explained compares the platforms that provide these management functions.
- Device identity, certificates and PKI for IoT covers the credentials that provisioning and rotation depend on.
- IoT security fundamentals explains why secure boot and signed updates matter.
- Types of IoT devices and their constraints describes the flash and power limits that shape OTA design.
Topics: device management, OTA, firmware, fleet management, lifecycle