IoT Platform / Device Management
IoT device management
from the factory line to retirement
Provisioning at end-of-line test, per-device identity and tokens, fleet grouping that matches how you build and how you sell, live health and connectivity state, and a lifecycle record that survives every replacement and every rollout.
The Foundation
If the registry is wrong,
everything above it is wrong.
Device management is the least glamorous part of an IoT platform and the part that decides whether the rest works. An OTA rollout can only target devices the registry knows about. An alert can only route to a customer if the device is claimed to a site. A warranty claim can only be settled if the serial links back to a lot and a build date. When the registry drifts from reality, teams start keeping a private spreadsheet, and from that point the platform is decoration.
Drift usually starts at manufacture. Units get flashed with a shared image and a generic identity, then someone types serials into a sheet after the fact. Two lots later nobody can say which units have which sensor revision. We push the registry as far upstream as it goes, into the end-of-line test fixture, so a device is known and trusted before it is boxed.
The same discipline runs through the rest of the life of the unit. Every state change is recorded against the serial: claimed to a site, firmware moved, alert raised, RMA opened, unit swapped, unit retired. That record is what turns a support call into a two-minute answer instead of an investigation.
| Registry task | Managed registry | Handled by spreadsheet |
|---|---|---|
| Device identity | Per-device keys at end-of-line | Shared image, generic identity |
| Serial to lot link | Bound before the unit ships | Typed in later, often wrong |
| OTA targeting | Query by product, lot or tag | Hand-built device lists |
| Warranty lookup | Serial resolves to build and site | Cross-referenced by hand |
| Retirement | A state change, history kept | Row deleted or lost |
Provisioning
A device is trusted
before it ships.
Provisioning is a production process, so we build it into production. The test fixture that validates the board is the same fixture that gives it an identity and proves it can reach the platform.
- Serial tied to product, variant and lot
- Credentials written into secure storage
- Device record created at end-of-line test
- First authenticated message on the line
- Claim to a site and customer on install
- A failed unit never leaves the building
Serial Allocation
Every unit gets a serial before it powers on for the first time. The serial is tied to a product, a variant, and a manufacturing lot, so a defect traced to one batch can be scoped exactly rather than guessed at.
Credential Injection
Credentials are written into secure storage on the device during end-of-line test. The key material never travels in a spreadsheet and never appears in a shared firmware image.
Platform Registration
The test fixture creates the device record and links it to the lot, the test results, and the firmware version flashed. The registry knows the unit exists before it leaves the building.
Connectivity Proof
The unit connects to the platform, authenticates, and publishes a first message while still on the line. A device that cannot authenticate is caught at the factory rather than at a customer site.
Field Claim
On installation the unit is claimed to a site, a customer, and a location. Installers do this from a phone. That claim is what turns an anonymous serial into an asset someone is responsible for.
Identity and Tokens
One key per device.
Never one key per fleet.
Shared credentials are the most common shortcut in fielded IoT and the most expensive one to undo. Somebody pulls the flash off one unit, and every device in the fleet is now speaking with a key an attacker holds. The only fix is a firmware campaign across the entire installed base.
Per-device credentials make that a single-unit problem. Revoke the serial, ship a replacement, carry on. They also make the audit trail meaningful, because a message can be attributed to a specific device rather than to the fleet in general.
Per-device credentials, no shared fleet key
Credential rotation without a site visit
Immediate revocation for a single serial
Every message attributable to one device record
Mutual authentication on the transport layer
Separate credentials for telemetry and update channels
Key material held in secure storage on the device
Full audit trail of issue, rotation, and revoke events
Bring us your serial scheme and your production test flow. We will show you where the registry should start.
Book a Technical Session →Fleet Grouping
Group by how you build.
Group by how you sell.
Engineering and service ask different questions of the same fleet. Engineering wants every unit on hardware revision C. Service wants every unit at a customer site. Both need to be one query, which means devices carry structural and operational grouping at the same time.
Product
The top level. All units of one product line share a data model, a firmware track, and a default alert policy.
Variant
Hardware revisions, regional radio variants, and optional sensor configurations. Firmware compatibility is decided at this level.
Lot
The manufacturing batch. When a component fails early, the lot boundary is the fastest way to find every unit at risk.
Site and Customer
Operational grouping. Who owns the unit, where it is installed, and which service contract covers it.
Region
Drives data residency, connectivity provider, alert routing, and which support team picks up the call.
Tags
Free-form grouping your team controls. Pilot cohorts, canary rings for updates, problem units under watch.
Groups are the targeting primitive for everything else on the platform. A staged rollout on the OTA updates layer starts with a tag, expands to a lot, then to a variant. An alert policy applies per product. A data export filters by customer. Grouping done properly once removes a whole class of manual work later.
Health and Connectivity State
Know a device is failing
before the call comes in.
Health is a computed state, not a field the device sets. The platform combines report timing, radio quality, power behaviour, reset history, and firmware version into a status that a support engineer can act on. Thresholds are per product, because a unit that reports once a day is not offline after an hour.
Last Seen
Time since the last accepted message, compared against the expected report interval for that product.
Connectivity State
Online, offline, or intermittent, based on link stability rather than a single missed packet.
Signal Quality
Radio signal level and its trend. A slow decline usually means an antenna or mounting problem, not a network problem.
Reboot Behaviour
Uptime and reset cause. Repeated resets point at power, watchdog, or firmware faults before the customer notices.
Power State
Battery level, charge state, or supply voltage, with thresholds set per product rather than globally.
Firmware Drift
Devices running an old build after a rollout completed. Drift is a first-class health signal, not a report you run monthly.
Lifecycle
Six states. One record
that never gets deleted.
A device is an asset with a history. Every transition is stamped and kept, so warranty decisions, failure analysis, and customer reporting all read from the same timeline rather than from three different systems.
Serial and keys at the factory
Claimed to a site and customer
Reporting, health tracked
Alerts, RMA, field swaps
Credentials revoked, history kept
Manufactured
Serial allocated, credentials injected, end-of-line test passed. Not yet claimed by anyone.
In Stock
Shipped to a distributor or held in inventory. Reachable if powered, but no site or customer attached.
Commissioned
Claimed to a site, reporting on its normal schedule, covered by warranty and an alert policy.
Under Service
Flagged by an alert, an RMA, or a support ticket. Still in the fleet, excluded from rollout targeting until resolved.
Replaced
Swapped in the field. History transfers to the installation record so the site keeps a continuous timeline.
Decommissioned
Credentials revoked, device can no longer publish, history preserved for warranty and failure analysis.
FAQ
Device management questions
we get asked first.
Four things. Getting a device a trusted identity at manufacture, keeping a record of what that device is and where it lives, knowing whether it is healthy and connected right now, and tracking every state change through its working life until it is retired. Everything else in an IoT platform depends on those records being correct.
Related
Go deeper.
Get the registry right
before the fleet grows.
Retrofitting identity and lifecycle onto ten thousand shipped units is a firmware campaign. Designing it in before the first production run is a sprint. Talk to us at whichever stage you are at.