What does device management include?
Device registry and identity, factory provisioning, configuration management, staged over-the-air update with rollback, diagnostics and fleet health monitoring, and access control across all of it.
SYSTEM INTEGRATION
Cloud, OTA & Device Management
The cloud side of a connected product is mostly fleet operations, not analytics. Ingest, device registry, provisioning, configuration, staged update, diagnostics and access control are what determine whether ten thousand devices are an asset or a support burden. The dashboards matter, but they are not what breaks.
SCOPE
What the platform layer does.
- Telemetry ingest — MQTT, HTTP and vendor IoT services, sized for the real message rate rather than the demo one.
- Device registry — identity, metadata, grouping and lifecycle state for every unit.
- Provisioning — factory onboarding and credential issuance that is auditable end to end.
- Configuration management — reporting intervals, thresholds and behaviour changed per device or per group.
- Over-the-air update — staged rollout with canary groups, monitoring and automatic rollback.
- Diagnostics — connectivity quality, reset causes, battery state and firmware version as first-class fleet data.
- Analytics and dashboards — the reporting an operator will actually act on, not every chart that can be drawn.
- Integration — ERP, CMMS, MES and customer systems, so events become work rather than notifications.
OPERATIONS
The parts that decide support cost.
Staged update. A firmware release that fails in the field is expensive in proportion to how many units received it. Canary groups, monitored rollout and automatic rollback contain the damage.
Fleet health. A device that reports only its payload cannot be supported remotely. One that reports connectivity quality, reset cause, battery state and firmware version can be triaged from a desk.
Data retention. Retaining everything forever is expensive and, under most privacy regimes, indefensible. Retention policy per data class is a design decision, not an operations afterthought.
Access control. Who can see which devices, change which configuration and trigger which update — defined before the first external user, because retrofitting a permission model is unpleasant.
DEPLOYMENT
Where the platform runs.
| Option | When it fits | Consideration |
|---|---|---|
| Customer cloud account | Data residency, procurement or existing platform investment | Customer operates it; Faststream builds and hands over |
| Faststream-managed | Customer would rather not operate infrastructure | Managed service with agreed responsibilities |
| Hybrid | Sensitive data on-premise, fleet management in cloud | Clear boundary and synchronisation design required |
| On-premise | Air-gapped or strictly regulated environments | Update and support model needs explicit design |
COMMON QUESTIONS
What engineers ask before they call.
Which cloud platforms does Faststream work with?
AWS and Azure primarily, and the Multi-TECH device framework is built for multi-cloud so the cloud decision is not welded into device firmware. On-premise and hybrid deployments are supported where residency or regulation requires.
How is over-the-air update made safe?
Signed images, a bootloader with rollback, staged rollout to canary groups first, monitoring against defined failure signals, and automatic rollback — so a bad release affects a small group rather than the installed base.
KEEP READING
Related work.
BUILD WITH FASTSTREAM
Bring us the difficult part.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.