Key takeaway
- Learn how an IoT analytics platform works: four architecture layers, protocols, cloud services compared, security and governance for enterprise teams.
An IoT analytics platform is the layer that takes data from sensors and devices, moves it reliably, stores it, analyses it and returns it to people and systems as decisions. The architecture question for an enterprise is not which dashboard to buy. It is which layers you need, where each one runs, and who owns the data and the decisions that depend on it.
This guide takes the platform view: the four layers, the nine capabilities a platform must provide, the protocols that connect devices, and how major cloud services differ. For the edge-versus-cloud placement of analytics, read our companion guide on IoT edge analytics and 2026 trends. For plant-floor examples, see industrial IoT applications.
What is an IoT analytics platform?
It is middleware between connected devices and the business. Devices carry unique identifiers and transfer data over a network without human-to-human or human-to-computer interaction. The platform connects them, manages their lifecycle, processes the data they produce and exposes the results to applications. Our IoT application development page describes how we build such systems.
| Question | Short answer |
|---|---|
| What does it do? | Connects devices, ingests and routes data, stores it, runs analytics and serves applications |
| Who is it for? | Teams running fleets of sensors, machines or vehicles who need decisions from the data |
| What it is not | A single dashboard, or a replacement for edge logic that must act in seconds |
What are the four layers of an IoT analytics architecture?
Most IoT architectures can be described in four layers. Each has a distinct owner and failure mode, so it helps to decide them separately.
| Layer | What it holds | Typical decisions |
|---|---|---|
| Hardware and sensing | Sensors, actuators, microcontrollers and tags such as RFID; wireless sensor networks | Which sensors, sampling rate, power and firmware update path |
| Network and gateway | Gateways and links (wired LAN, Wi-Fi, internet) that carry digitised data using IoT protocols | Which protocol, what happens when the link drops |
| Management | Data modelling, processing, device management, authentication and authorisation | Where data is stored and who may see or change it |
| Application | Dashboards, business intelligence tools, mobile apps and third-party integrations | Which decisions are automated and which stay with people |
A common prototype pattern links sensors to an Arduino microcontroller and on to a Raspberry Pi that sends data to a server over Ethernet or Wi-Fi. That is fine for a proof of concept. Production estates add managed gateways, device identity and update control.
Which capabilities should an IoT platform provide?
Whatever the vendor, a platform should cover the following. Use the list as an evaluation checklist.
| Capability | What to ask of it |
|---|---|
| Connectivity | Which protocols and gateways it supports, and how it handles unreliable links |
| Device management | Onboarding, provisioning, firmware updates, remote configuration, monitoring and retirement |
| Data management | Storage, processing and retention for time-series data |
| Application enablement | APIs and SDKs so teams can build against devices and data |
| Cloud services | Scalable storage, compute and analytics |
| Interoperability | Whether mixed device types can exchange data without rework |
| Security | Encryption, authentication and access control for devices and data |
| Analytics | Rules, machine learning and real-time insight on streams |
| Application development | Tools to build and test applications on top of the platform |
Which protocols connect devices to the platform?
Five protocols appear most often. The facts below come from the standards bodies.
| Protocol | What it is | When it fits |
|---|---|---|
| MQTT | A client-server publish/subscribe messaging transport; lightweight and open; OASIS Standard version 5.0 (7 March 2019). Version 3.1.1 is also ISO/IEC 20922:2016 | Telemetry from devices where bandwidth or code size is limited |
| CoAP | A web transfer protocol for constrained nodes and networks (RFC 7252, June 2014); a REST subset that maps to HTTP; runs over UDP by default | Very small devices on low-power, lossy links |
| AMQP | An open messaging standard for passing messages between applications | Back-end integration between systems |
| HTTP(S) | The standard web protocol; RESTful interfaces are widely used | Devices and apps that already speak web APIs |
| DDS | OMG data-centric publish-subscribe model for distributed application communication (version 1.4, March 2015) | High-performance machine-to-machine data exchange |
Sources: OASIS MQTT 5.0, RFC 7252 and OMG DDS.
How does real-time data handling work on the platform?
Real-time analytics depends on three stages that should be designed together: ingestion of high-velocity device data, stream processing (transformations, anomaly detection and enrichment as data arrives) and storage that keeps low-latency access at scale. Our guide to data ingestion pipeline architecture covers the first stage, and Apache Flink is one engine for stateful stream processing.
The practical rule is to keep time-critical logic near the device and send aggregated results upward. The edge guide linked above sets out that split in detail.
How do cloud IoT services differ?
Major clouds provide the connectivity and routing layers, and you assemble analytics around them. Read each vendor page before you commit, because services are retired and renamed.
| Service | What its documentation states | Status note |
|---|---|---|
| AWS IoT Core | Message broker for devices using MQTT and MQTT over WSS; HTTPS for publishing; LoRaWAN support | Current |
| Azure IoT Hub | Central message hub; device-side MQTT, AMQP, HTTPS and WebSockets variants; routes telemetry to Storage, Event Hubs, Service Bus and Cosmos DB; commands through direct methods; scales to millions of connected devices | Current |
| AWS IoT Analytics | Managed time-series analytics service | AWS ended support on 15 December 2025; the console and resources are no longer accessible |
Sources: AWS IoT Core, Azure IoT Hub and AWS IoT Analytics. We have left out services whose current status we could not confirm from the vendor.
The lesson from the AWS retirement is architectural. Keep ingestion, storage and analytics loosely coupled with open protocols and exportable data, so one managed service ending does not force a rebuild.
Where does IoT analytics pay off?
| Sector | Decision the platform supports | Where it fits |
|---|---|---|
| Manufacturing | Predictive maintenance: flag equipment at risk before failure | Needs sensor history and a path to maintenance systems |
| Healthcare | Remote monitoring from wearables and sensors so clinicians can adjust care | Needs strict privacy controls |
| Transport and logistics | Route optimisation, fleet and vehicle health monitoring | Needs reliable connectivity while moving |
| Supply chain | Real-time asset and inventory tracking, product condition monitoring | Needs integration with warehouse systems |
| Energy | Analysing usage patterns to find inefficiency and manage peak loads | Needs fine-grained meter data |
Each row is a decision, not a dashboard. Start from the decision and work back to the data it needs.
How should you secure and govern an IoT platform?
A platform that spans devices, networks and cloud multiplies the places where data can leak or decisions can go wrong. Treat security and governance as architecture, not an afterthought.
- Network and device security: encryption, authentication and access controls on every link; regular updates and tamper resistance on devices.
- Data protection: encrypt, restrict and anonymise data to meet privacy rules.
- Monitoring: intrusion detection and vulnerability scanning with a defined response path.
- Regulation: the EU Cyber Resilience Act entered into force on 10 December 2024, with reporting obligations from 11 September 2026 and main obligations from 11 December 2027 (as published on the European Commission page). Check how it applies to connected products you make or sell.
- Decision governance: when analytics trigger automated actions, record which policy allowed each one. ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents.
What does it take to implement an IoT analytics platform?
- Define the business objectives and the KPIs the platform must move.
- Design for more devices, more data and more users than you have today.
- Balance edge and cloud: process real-time data at the edge, run complex analytics in the cloud, and use hybrid models where needed.
- Validate data with sensor health monitoring, completeness checks and anomaly detection.
- Train staff on IoT security risks.
For physical-world estates that span sites, NexaStack is an agentic operating platform for physical AI that runs across on-premises, cloud and hybrid environments. For the analysis step, AgentAnalyst lets teams ask questions of enterprise data in plain language and get real-time insights.
When is a full IoT analytics platform not the right choice?
- A handful of devices with simple alerts rarely needs a platform; a rules engine may do.
- Decisions that must happen in seconds, offline, belong at the edge, not in a cloud-only design.
- If you cannot name the decision the data will change, fix that before buying infrastructure.
What will change in IoT analytics next?
The direction our teams watch is a move from reporting to acting: AI and machine learning on or near devices, more edge processing, digital twins for monitoring and optimisation, and tighter privacy controls. Treat these as directions rather than forecasts. Where analytics start to trigger actions, the platform needs the same policy and audit controls as any other automated decision.
To map one IoT decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.
Related on XenonStack
- NexaStack: agent runtime and inference for private cloud, on-prem and edge.
- Edge and vision AI: computer vision agents at the edge.
- Agentic analytics platform: AI dashboards and insights that act.
Frequently asked questions
What is an IoT analytics platform?
It is middleware that connects devices to the cloud, manages them, processes their data and delivers insights to applications.
What are the layers of IoT analytics architecture?
Hardware and sensing, network and gateway, management, and application.
Which protocols are most used in IoT?
MQTT, CoAP, AMQP, HTTP and DDS. MQTT is a lightweight publish/subscribe protocol standardised by OASIS, and CoAP is defined in RFC 7252 for constrained devices.
Is AWS IoT Analytics still available?
No. AWS ended support on 15 December 2025, and the console and resources are no longer accessible.
Which protocols does Azure IoT Hub support on the device side?
MQTT, MQTT over WebSockets, AMQP, AMQP over WebSockets and HTTPS.
Should IoT analytics run at the edge or in the cloud?
Run time-critical logic at the edge and complex analytics in the cloud, using hybrid models where needed.
Follow XenonStack on LinkedIn: XenonStack on LinkedIn for new guides on agentic AI, data and platform engineering.
Ready to put AI agents to work? Explore ElixirClaw, the agentic OS platform to build, orchestrate and govern AI agents.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE
