IoT device management and over-the-air (OTA) updates at scale
In short: Device management keeps an IoT fleet healthy from first boot to retirement. It covers provisioning identities, onboarding, monitoring, over-the-air (OTA) updates and decommissioning. Safe OTA updates are signed, tested on a pilot group, rolled out in stages and can roll back automatically.
Managing a fleet
One device can be configured by hand. A fleet of thousands needs automation. Device management is the set of tools and processes that track every device, keep its software current and remove it safely at the end. Without it, fleets drift: firmware versions multiply, lost devices keep valid credentials and nobody knows what is actually deployed.
Lifecycle stages
| Stage | What happens | Key control |
|---|---|---|
| Provision | Unique identity and keys created, often in the factory | Keys generated in a secure element, never shared |
| Onboard | Device registers with the platform and receives configuration | Only devices with a valid identity are accepted |
| Monitor | Health, connectivity, battery and firmware version reported | Alerts for offline, tampered or out-of-date devices |
| Update | New firmware or configuration sent over the air | Signed images, staged rollout, rollback |
| Decommission | Device removed from service | Revoke credentials, wipe data, update inventory |
Open standards help here. LwM2M (Lightweight Machine to Machine, from OMA SpecWorks) defines a common way to manage constrained devices over CoAP, including firmware updates.
Over-the-air updates done safely
A bad update can "brick" thousands of devices at once, so OTA must be designed defensively:
- Sign every image. The device verifies the signature with a public key held in protected storage before installing. Encryption of the image adds confidentiality, but signing is what stops tampering.
- A/B partitions. The device keeps the old firmware in one slot, writes the new firmware to the other, and boots the new one only after it passes checks. If it fails to start or report in, it falls back.
- Anti-rollback. A version counter stops attackers reinstalling an older, vulnerable image.
- Staged rollout. Update a pilot group first, then increasing percentages, pausing automatically if failure rates rise.
- Resumable downloads. Constrained links drop; downloads should continue where they left off.
- Respect constraints. Schedule updates when battery and connectivity allow, and avoid updating safety-critical devices mid-operation.
The open Uptane framework, designed for vehicles, and the IETF SUIT (Software Updates for Internet of Things) work both describe secure update designs worth studying.
Decommissioning
Retired devices are easy to forget. A sensor thrown in a skip may still hold Wi-Fi passwords and a valid cloud certificate. Revoke the certificate in the registry, factory reset or physically destroy storage, and update your asset inventory. For resold or returned equipment, verify the wipe.
Tip: track "percentage of fleet on current firmware" as a key metric. It shows at a glance whether your update process actually works.
Practice
Why do OTA systems use A/B partitions?
What does anti-rollback protection prevent?
List two steps when decommissioning an IoT device.
Key takeaways
- Device management covers provision, onboard, monitor, update and decommission.
- Give each device a unique identity created and stored securely.
- Sign OTA images, use A/B partitions and anti-rollback counters.
- Roll out updates in stages and stop automatically on failures.
- Revoke credentials and wipe data when devices are retired.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.