Every connected product needs a back end that devices talk to. Someone has to accept thousands of simultaneous connections, check that each device is who it claims to be, store what it sends, let operators push firmware, and expose the data to applications. Building all of that from scratch is a year of work before the first useful dashboard appears. An IoT platform is software that provides these common functions so that a team can focus on the parts specific to their product.
The term covers a wide range of products: managed services from the large cloud providers, open-source stacks you host yourself, vertical platforms built for one industry, and the connectivity management portals that mobile operators offer. They overlap, and marketing material tends to describe each as “end to end”. This guide separates the functions a platform can provide, maps them to the main categories of product, and lists the questions that actually decide which one fits.
The functions a platform provides
A platform is best understood as a bundle of services sitting between devices and applications. Not every product offers every service, and that is the first thing to check.
Device connectivity
The entry point is an endpoint that devices connect to, usually an MQTT broker, often with HTTP and sometimes CoAP or LwM2M alongside. The endpoint terminates TLS, authenticates the device and enforces authorization rules about which topics it may publish to or subscribe from. Scaling it to hundreds of thousands of persistent connections is one of the main reasons to buy rather than build.
Identity and registry
A device registry records every device the system knows about: its identifier, its credentials or certificate, its type, its metadata such as location or owner, and its status. Provisioning workflows get a new device into the registry securely, ideally using a factory-installed certificate and a PKI so that no secret has to be typed by an installer. The device identity guide covers these mechanisms.
Device state and management
A device shadow (also called a digital twin in some products, although the term digital twin usually means something richer) stores the last reported state and any desired state waiting to be applied. Fleet management tools group devices, show which are online, and run jobs across groups. OTA updates deliver new firmware in staged rollouts with rollback. The device management guide explains these in detail.
Data routing and rules
Incoming messages are routed by a rule engine that can filter, transform and forward them: to a database, to a message queue, to a serverless function, to an alerting service. This is the glue that connects device data to the rest of the data pipeline.
Storage and analytics
Some platforms include a time-series database, dashboards and basic analytics; others expect you to connect your own. Vertical platforms tend to bundle domain-specific analytics, such as predictive maintenance models for industrial equipment.
Application interfaces
Finally, the platform exposes APIs and webhooks so that your applications can query device state, retrieve history, send commands and react to events, and usually an SDK for device firmware and for application code.
The main categories
Hyperscaler cloud platforms
AWS IoT Core, Azure IoT Hub and their equivalents provide the connectivity, registry, shadow and rules layer as managed services, billed by message and connection. Their strength is elastic scale and tight integration with the rest of the provider’s cloud: storage, functions, analytics, machine learning. Their weakness is that the integration is one way; the sum of a dozen loosely coupled services takes real expertise to assemble, and moving off later is painful. Vendor lock-in is a legitimate concern, mitigated by keeping devices on standard MQTT and keeping business logic out of provider-specific rule languages.
Open-source and self-hosted platforms
Open-source IoT stacks package a broker, registry, rule engine, storage and dashboards into something you run on your own servers or in your own cloud account. They give full control over data location, which matters for data sovereignty, and avoid per-message pricing. The cost moves to operations: someone has to patch, back up, scale and monitor the stack. For teams with existing platform engineering capacity and a few thousand devices this is often the best value. For a two-person startup it can be a distraction.
Vertical and industrial platforms
Platforms built for a specific industry, such as industrial equipment monitoring, smart building management or asset tracking, bundle domain models, integrations with industry protocols like OPC UA or BACnet, and ready-made applications. They shorten time to market when the product fits, and constrain you when it does not.
Connectivity management platforms
A connectivity management platform from a mobile operator or MVNO manages SIMs and eSIMs, data plans, network access and diagnostics for cellular devices. It is a different layer from the application platforms above and is usually used alongside one of them.
How to choose
A platform decision tends to be made once and lived with for the life of the product. The questions below separate products better than feature lists.
Which functions do you need now, and which in two years? A prototype needs connectivity and a dashboard. A product needs provisioning at manufacturing scale, OTA with rollback, and an audit trail. Buying everything up front is expensive; buying a platform that cannot grow is worse.
Where may the data live? Regulation or customer contracts may require specific regions or on-premises hosting, which rules out some managed options.
What protocols do your devices speak? A platform that only accepts MQTT over TLS is fine for Wi-Fi devices and useless for a LoRaWAN fleet without an intermediate network server.
What is the cost model at scale? Per-message pricing is cheap at a thousand devices reporting hourly and startling at a million devices reporting every few seconds. Model the total cost of ownership including the engineers who operate it.
How hard is it to leave? Standard protocols on the device side, exportable data, and business logic kept in your own code rather than the platform’s rule language all reduce switching cost.
Who operates it at three in the morning? A managed service has an SLA and a support line. A self-hosted stack has your on-call rotation.
A common failure pattern
Teams frequently pick the platform that gets a demo working fastest and discover its limits during the first large rollout. The symptoms are familiar: provisioning that requires manual steps per device, no way to stage an update to a subset of the fleet, and rules that silently drop messages under load. This is one of the paths into pilot purgatory. The defense is to test the platform against the boring operational scenarios early: onboarding a thousand devices at once, updating half of them, revoking one compromised certificate.
Where to go next
- Device management and OTA updates covers the platform functions that matter most after launch.
- The IoT data pipeline explains what happens to data once the platform has routed it.
- IoT architecture: the layers places the platform in the overall system.
- MQTT explained describes the protocol most platforms are built around.
Topics: platforms, cloud, architecture, device management