IoT Device Management: Provisioning, OTA, and Lifecycle

IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile device management starts to hurt the day a project stops being a pilot, and it always arrives as the same question: who holds the list of installed units, and what does that list actually know about each one?

Up to that point, the list fits in a spreadsheet. After it, it does not. An installer swaps a sensor in the field and tells nobody. A new batch arrives with different firmware. A client asks that their 300 units stay invisible to everyone else. IoT device management is the work of holding all of that together for as long as the hardware stays in the field, and it is almost always designed too late.

This guide walks the full cycle: onboarding and provisioning, remote configuration, OTAOTermOTA (over-the-air)OTA (over-the-air) is the remote update of an IoT device's firmware over the network, without physical access, essential for large fleets.View profile updates, decommissioning and replacement, and how that work splits when an integrator sits in the middle. It is written for integrators and device manufacturers who already have units running and are starting to feel the weight of keeping them alive. If you are still short of that line, start with what changes from prototype to production.

What IoT Device Management Covers, and What It Does Not

IoT device management gets confused with the monitoring dashboard. They are different jobs. The dashboard answers "what is this sensor reading right now". Management answers "what is this unit, where is it, which version is it running, who is allowed to touch it, and what has happened to it since it left the factory".

That is five blocks of work:

None of this is optional in a commercial deployment. What changes between projects is how much of it is automated, and who does it.

A simple test for whether your setup holds: if replacing a failed unit requires calling the person who built the platform, the system is not finished.

Onboarding and Provisioning: Identity Comes Before Connectivity

Provisioning is how a unit stops being hardware and becomes a device the platform recognizes. It has two halves worth keeping apart: the cryptographic identity, which ideally is born on the production line, and the functional registration, which happens at install time.

Secrets Do Not Travel by Email

The pattern that ages best is factory-injected identity: every unit ships with its own credential, and the platform only accepts devices whose credential it knows. LoRaWANProtocolLoRaWANOpen long-range, low-power LPWANView profile solves this by specification, through OTAA activation and a join server that holds the root keys and derives session keys on every join. If that is where you operate, the decision that matters is who holds those root keys, and we cover it in the LoRaWAN network server guide.

In MQTTProtocolMQTTThe standard pub/sub protocol of IoTView profile, the equivalent practice is one credential per device over TLS, not one shared across the batch. Cloud Studio IoT runs a dedicated MQTT server per instance with TLS on port 8883, and credentials are managed from Gear Manager. A unique credential per unit costs a little more on the production line and saves an entire incident: if someone extracts a key from one sensor, you revoke that sensor, not the fleet.

What never works, though it still shows up: the same password on all 500 units, printed in the installation manual.

Bulk Onboarding Gets Prepared Before the Site Visit

An installer on a rooftop, wearing gloves, with no mobile signal, is not the right setting for typing a 16-character serial number. Bulk onboarding is prepared in advance:

1. Pre-loaded inventory. Batch identifiers go into the platform before the truck leaves, with model and client already assigned.
2. Machine-readable label. A QR or NFC tag on each unit removes manual transcription, which is where the errors come from.
3. Field binding. The installer scans, assigns the site, and takes a test reading. If the unit does not appear on the dashboard right then, it gets fixed while the ladder is still up.
4. Onboarding closed. The platform marks the unit as live and starts its history.

Ana runs a small integrator in Zaragoza and installed 180 level sensors across agricultural tanks in three provinces. She did the first rollout with a shared spreadsheet: when it was done, 14 units were bound to the wrong tank and two were missing entirely. Tracking down those 16 errors cost her four days of driving. On the second rollout, identifiers were pre-loaded and every sensor carried a QR code. Nothing ended up in the wrong place.

If you are wiring that flow into your own systems, the route is the API, and how it fits your ERP and the rest of your operation is covered in the API integration guide.

Operations: What "The Fleet Is Fine" Actually Means

At a hundred units, fleet health is something you eyeball. At ten thousand you need a written definition of normal, because something will always be offline.

Three signals carry day-to-day operations:

• Last seen. A sensor that reports every five minutes and has been quiet for an hour is not the same as one that reports daily. The threshold belongs to the device type, not the whole fleet.
• Battery and link quality. The trend matters more than the reading. A battery dropping three points a week warns you months ahead; a single sample tells you nothing.
• Firmware version and configuration. Knowing how many units sit on each version is what turns an update into a measurable operation.

Remote Configuration Is the Cheap Half of the Job

Before reaching for new firmware, exhaust what configuration can change: reporting interval, alarm thresholds, calibration, destination server. A configuration change is reversible and cheap. A firmware update is not entirely either.

The pattern that works is desired state: the platform stores the configuration the unit should have, the unit asks for it when it wakes, and confirms once applied. Neither side has to be online at the same moment, which is the only workable model for battery devices that sleep almost all the time.

On networks where downlinks are expensive, LoRaWAN above all, this has a physical limit: every command toward a device consumes gateway airtime. Batch your changes, and do not push a reconfiguration to the whole fleet on the same Tuesday.

For how those messages travel and what delivery guarantees you get, see the MQTT broker guide.

OTA Updates: How Not to Brick 400 Units

An over-the-air (OTA) update is the riskiest operation in the cycle. A failure leaves a unit unable to boot, and recovery means a site visit. With 20 units that is an afternoon. With 4,000 spread across a country it is a project.

The Four Defenses of a Serious OTA

1. Signed firmware, verified at boot. The device checks the signature before it runs anything. The reference architecture here comes from the IETF SUIT working group, described in RFC 9019, which defines how an update is described and validated on constrained devices.
2. Dual partition and rollback. The new image is written to a partition other than the running one. If boot fails, or the unit does not confirm it is healthy, it falls back on its own.
3. Ring-based rollout. Five lab units first, then 5% of the real fleet, then the rest. Between rings, an observation window with written criteria for what aborts the campaign.
4. Resumable transfer. An interrupted download picks up where it stopped. On a slow network, or with devices that sleep, an update can take days, and that is normal.

The Network Decides How Much You Can Update

In LoRaWAN, firmware update over the air (FUOTA) exists and is specified by the LoRa Alliance, but it is worth knowing what it asks for: multicast, Class B or C receive windows, and hours of airtime inside duty cycle limits. It is workable for parameters and small fixes. It is not workable for rewriting a full application across 3,000 battery sensors.

For mixed fleets, the most widely adopted management standard is LwM2M from Open Mobile Alliance, which defines standard objects for inventory, configuration, diagnostics, and firmware update. If your hardware already speaks it, you avoid inventing a protocol of your own.

This Is No Longer Just Good Practice

In the European Union, the Cyber Resilience Act (Regulation (EU) 2024/2847) places obligations on products with digital elements, including vulnerability handling and security updates across the support period, with general application from December 2027. In parallel, ETSI EN 303 645 has for years set the baseline for consumer devices: no universal default passwords, a channel for reporting vulnerabilities, and a means to keep software updated.

The practical reading for a manufacturer: if you ship a device today that cannot be updated, in a few years you have a commercial problem on top of a technical one. It is worth looking at now, while the microcontroller is still a choice.

Decommissioning, Replacement, and Resale: The Ending Nobody Plans

Onboarding always gets designed. Decommissioning almost never does. And it is the one that corrupts the data.

Three different situations that many teams solve with the same delete button:

• Replacement after a failure. The history belongs to the measurement point, not to the box. Delete the unit and you lose the series. The correct move is to keep the site and swap the bound device, with the change date recorded.
• Permanent retirement. The unit leaves service, stops counting toward thresholds and billing, but its data stays queryable.
• Return or resale. The unit goes back to the factory or moves to another client. Before it leaves, revoke its credentials and wipe the previous client's configuration. A device resold with client A's credentials inside is a security incident waiting to happen.

Javier runs maintenance on a network of 2,400 meters for a utility retailer. Through the first year, every replacement was handled by deleting the old meter and creating the new one under a different identifier. At the annual close, the billing team found 190 supply points with their series split in two, and no report reconciled. The fix was conceptual, not technical: the measurement point became the primary entity and the meter an attribute with dates. Later replacements stopped breaking anything.

This is worth deciding before the first thousand units. After that, migrating historical data is expensive.

Who Manages What When an Integrator Sits in the Middle

In a B2B2B model, device management has three layers of responsibility, and the split is agreed in the contract:

That asks two things of the platform. First, real separation between clients: each one sees their fleet and nothing else. In Cloud Studio IoT that separation rests on granular permissions, with SSO, native two-factor authentication, and an audit trail. Second, the integrator has to operate across all their clients without entering them one by one, which is what makes hundreds of installations manageable with a small team. The full model is in the white-label IoT platform guide.

If you are sizing how much operational work you take on and how it gets billed, the cost components of an IoT platform include exactly that line item, the one most often underestimated.

An IoT Device Management Checklist Before the First Thousand Units

Before moving from dozens to thousands, have a written answer to these eight questions:

1. Identity. Does every unit have its own credential, and can one be revoked without touching the rest?
2. Inventory. Does the platform know model, version, client, and site for every unit, without a second spreadsheet?
3. Bulk onboarding. Can an installer bring a unit live in the field in under a minute?
4. Configuration. Can interval and thresholds be changed per group, without touching firmware?
5. Update. Does the device verify the signature and roll back if boot fails?
6. Rollout. Are rings defined, with written criteria for aborting a campaign?
7. Decommissioning. Does replacing a unit preserve the measurement point's history?
8. Permissions. Does each client see only their fleet, with a record of who changed what?

None of the eight needs a big project if it is decided early. All eight are expensive once 5,000 units are already installed, and the cost lands on the team that has to drive out to every site. Treat the checklist as part of the hardware specification, not as something the platform will sort out later.

Conclusion

IoT device management is the work that separates a pilot that runs from a service you can sell for five years. What to keep:

• The dashboard is not the IoT device management layer. Identity, inventory, configuration, update, and decommissioning are five separate blocks, and all five are needed.
• Identity is solved on the production line, one credential per unit. Shared credentials turn any single failure into a fleet failure.
• Remote configuration solves more problems than firmware does, and it is reversible. Exhaust it first.
• A serious OTA has signing, dual partitions, rings, and resumable transfer. Your network decides how much can really be updated.
• Decommissioning and replacement get designed alongside onboarding, or the history breaks at a point where fixing it is no longer cheap.
• With an integrator in the middle, the split of responsibilities is written before the first install.

If you are preparing the jump from pilot to commercial rollout and want to test how this fits your hardware and your network, talk to the team or look at how other integrators work through the partner program. Connection and credential details live in the technical documentation.