Jun 21, 2026
24.6.2026
24.6.2026
Which Azure IoT solution fits which scenario? This article compares IoT Hub, IoT Edge, and Azure IoT Operations—and explains why OT-centric data flows are becoming increasingly important for physical AI and modern production environments.
Azure offers several ways to connect devices, machines, and production data to the cloud, including IoT Hub, IoT Edge, and Azure IoT Operations. However, the right architecture, data model, integration effort, and AI potential can vary significantly depending on the scenario. In this article, we compare these approaches from the perspectives of data management, OT/cloud integration, security, and industrial AI. You’ll gain practical guidance on when IoT Hub and IoT Edge are sufficient—and when Azure IoT Operations provides a stronger foundation for scalable production and AI scenarios.
Azure IoT is a modular platform of managed cloud services, edge solutions, and programming tools designed to efficiently connect the physical world with the cloud. Choosing the right components always depends heavily on the specific use case—and that is exactly where many companies face the challenge of selecting the right architecture.
At a high level, two design principles can be distinguished: cloud-based IoT solutions and edge-based IoT solutions. In cloud-based approaches, connected devices send their data directly to the cloud, where it is processed and analyzed. Azure IoT Hub is one example.
In edge-based approaches, data is first processed, filtered, or enriched locally and then passed on to the cloud. Azure IoT Operations is designed for this type of approach.
Between these two models are hybrid architectures that combine cloud and edge components. One established approach is the combination of Azure IoT Hub and Azure IoT Edge: the cloud remains the control and integration center, while edge devices preprocess data locally.
Following this distinction, IoT Hub is the central component of a cloud-based IoT approach. It serves as a central communication hub and enables secure, scalable, bidirectional communication between edge devices and the cloud. Devices can be provisioned, configured, and managed from the cloud. IoT Hub can also be natively connected to Azure services such as Stream Analytics or Event Hubs to further process the collected data. As a standalone solution, however, IoT Hub does not provide a way to process data directly on the edge device itself.
From a data management perspective, this approach has a clear device-centric focus. Device states, properties, and firmware levels are managed through device twins. Typically, devices send telemetry data to IoT Hub, which then forwards it to Event Hubs, Blob Storage, or downstream analytics services.
With the integration of Azure IoT Hub into Azure Device Registry (ADR), this device-centric approach will become more tightly embedded in the broader Azure management layer. IoT Hub devices can be represented as Azure resources and managed through Azure Resource Manager. This is particularly relevant for larger IoT fleets, as devices are no longer viewed solely within individual IoT hubs but become visible and manageable across a central registry.
IoT Edge often serves as an extension of IoT Hub in factory environments. At its core, it is an edge runtime that enables data to be processed directly where it is generated. Technically, the runtime consists of two central modules: the Edge Agent, which controls the orchestration and configuration of containerized workloads, and the Edge Hub, which acts as a local broker for communication between modules and the cloud.
Existing code in the form of Docker images—or Azure services already provided as modules, such as Machine Learning or Stream Analytics—can also be deployed as standardized containers on the edge device. This allows data to be processed locally or forwarded to the cloud after filtering. Offline scenarios can also be supported by buffering data locally.
With IoT Hub and IoT Edge, cloud integration is the primary focus. IoT Hub provides standard routing to various Azure services, including:
This makes IoT Hub especially well suited for scenarios in which telemetry data needs to be brought quickly and scalably into existing Azure data and analytics stacks.
On the edge side, IoT Edge is very open in terms of interfaces. However, native support for industrial protocols is limited. Partner modules or custom containers are often used to connect industrial systems, for example for:
The advantage of this approach: flexibility. In principle, any Docker container can be integrated as an IoT Edge module. This allows existing applications, protocol connectors, or custom business logic to run freely on the edge device.
The disadvantage of this approach: the heterogeneity of the ecosystem. Configuration, monitoring, updates, and operation of individual modules are partly outside the actual Azure core and must be addressed individually. In OT environments with many machines, protocols, and security zones, this can quickly become challenging. In addition, this approach requires experience programming container apps, which not only makes self-service more complex for business teams but also increases OT’s dependency on IT.
By contrast, Azure IoT Operations is a clearly edge-centric IoT solution. While IoT Hub primarily focuses on individual devices and their connection to the cloud, Azure IoT Operations treats the entire production and OT environment as a connected edge cluster. The technical foundation consists of Arc-enabled Kubernetes clusters that serve as a full-featured, modular edge platform.
Instead of relying on a monolithic runtime, Azure IoT Operations uses containerized, cloud-native services that together form a comprehensive IoT architecture. Key components include:
From a data management perspective, Azure IoT Operations is much more focused on data flows and processes than IoT Hub-based approaches. Data is primarily understood as streams originating from OT sources such as controllers, OPC UA servers, or machines. These streams pass through internal processing stages and are ultimately written to IT or cloud targets such as data lakes, event streaming platforms, or analytics environments.
Typically, this data is viewed as time series data in the context of assets. As a result, data pipeline configuration takes place not only at the level of individual devices, but also at the level of tags and signals.
Another focus is edge-side data storage and resilience. Events can be buffered locally and resent to the cloud once the connection is restored. This helps avoid data gaps during temporary interruptions in cloud connectivity. In production environments in particular, this behavior is critical because availability, data completeness, and stable processing chains are high priorities.
On the OT side, Azure IoT Operations places particular emphasis on simple integration of industrial systems. The focus is on OPC UA and other common industrial protocols.
The difference from IoT Edge is that these connectors are already available as part of the official platform stack. The emphasis is less on “bring your own container” and more on curated, robust OT connectors that are closely integrated with production environments.
Toward IT and the cloud, data streams from IoT Operations can be selectively integrated into:
The goal is to connect the OT and IT worlds cleanly. OT data should flow reliably and in a structured way into IT systems without violating OT security zones, latency requirements, or availability requirements.
Across many industries, it is becoming clear that the greatest value is created where AI meets the physical world. While traditional IoT scenarios primarily use edge devices to collect data and forward it to the cloud, AI and ML applications require faster processing directly on-site. In production environments especially, milliseconds can make a difference. That is why AI models are increasingly being run on edge systems—where the data is generated. This reduces latency, enables real-time decisions, and allows processes to continue being monitored or controlled even when the cloud connection is interrupted.
These kinds of AI scenarios can also be implemented with Azure IoT Hub and IoT Edge. A typical pattern is to first train an ML model in the cloud, then package it as a Docker container and deploy it to an edge device as an IoT Edge module via IoT Hub. There, the model can perform inference locally, for example by detecting anomalies in sensor data or classifying events. The advantage of this approach is its flexibility: existing models, custom code, or specialized analytics components can be operated as containers, while IoT Hub continues to serve as the central control and deployment system.
At the same time, this approach is usually geared more toward inference than model training. Models are generally trained in the cloud and then distributed to the edge. Because many edge devices have limited resources, smaller or optimized models are especially suitable. Extensive data enrichment, complex contextualization, or model training directly at the edge are possible, but they are typically not the primary use case. This makes IoT Hub + IoT Edge particularly suitable for device-centric AI scenarios such as remote monitoring or local ML inference close to the device.
For more comprehensive industrial AI scenarios, however, Azure IoT Operations offers a stronger foundation. With the latest release, Azure IoT Operations 2603, Microsoft is increasingly positioning the platform as a basis for what is known as physical AI—AI systems that not only analyze digital data, but can also understand and influence physical processes in production, plant operations, and OT environments.
The key point is this: AI in production does not start with the model. It starts with the data foundation. Production data must be reliably captured from machines, controllers, and sensors, processed with the correct timing, enriched with asset and process context, and then made available in cloud, analytics, or AI platforms. This is exactly the role Azure IoT Operations plays as an operational data layer between OT and IT.
Through native OT connectors, dataflows, MQTT communication, edge-side processing, and integration with Azure Arc, IoT Operations makes industrial data AI-ready both locally and in the cloud. Data can be processed close to the machine while also being transferred to central platforms such as Event Hubs, Azure Data Explorer, Data Lake, or Microsoft Fabric. This creates an end-to-end architecture for industrial AI use cases such as predictive maintenance, condition monitoring, quality forecasting, and industrial copilots.
Compared with IoT Hub and IoT Edge, this represents a clear shift in focus. While IoT Hub and IoT Edge primarily cover device-centric telemetry and edge workload scenarios, Azure IoT Operations addresses entire production sites, lines, cells, and OT data flows. For AI in production, this is a decisive advantage because models need more than raw data—they need contextualized, robust, and continuous time series from real production processes.
The approaches also differ significantly when it comes to security.
IoT Hub, IoT Edge, and Azure Device Registry rely on proven device security mechanisms. These include support for:
Azure Device Registry adds further value for larger device fleets. This includes centralized certificate management for issuing and managing X.509 certificates, automated certificate rotation, integration of Microsoft-managed PKI, and improved traceability and governance. This is especially relevant for audit requirements: companies can better trace not only certificate chains, but also who registered, changed, or managed which device or certificate and when.
Communication with the cloud is encrypted via TLS. IoT Edge extends this model with device and module identities, secured runtime communication, and the controlled use of trusted container images. Microsoft Entra ID and Azure RBAC can be used to control who is allowed to manage IoT Hub resources, device identities, device twins, certificates, or edge deployments. In addition, Azure Policy and existing Azure certifications such as ISO or SOC can support governance and compliance.
Azure IoT Operations is more strongly geared toward security-critical OT environments. Its architecture takes into account typical requirements of industrial networks, such as:
Because Azure IoT Operations is based on Arc-enabled Kubernetes, it uses the security models of Kubernetes and Azure Arc. These include namespaces, network policies, secrets, and RBAC. These mechanisms make it possible to separate and control workloads, configurations, and access at a granular level. The connectors themselves must also be operated securely. For OPC UA, for example, this includes certificates, signing, encryption, and authentication.
At the governance level, Azure IoT Operations offers strong integration with Azure mechanisms such as policies for cluster configurations, monitoring, and audit logs. This is especially relevant for companies with high requirements for traceability and regulatory compliance, including in energy, pharmaceuticals, automotive, and other regulated industries.
Based on the points discussed in this article, two broad patterns emerge.
Both worlds will coexist for the foreseeable future. The key question, therefore, is not which platform is fundamentally “better,” but which level of abstraction fits the scenario: device-centric with IoT Hub and IoT Edge, or OT-, process-, and data-stream-centric with Azure IoT Operations.
For many companies, a hybrid architecture will make sense: IoT Hub for global product fleets and Azure IoT Operations for the production sites that manufacture, operate, or maintain those products. This makes it possible to bring cloud, edge, and OT scenarios together in a shared architecture—from secure device identity and local data processing to global analytics and AI scenarios.
Are you also trying to determine which Azure IoT architecture fits your production or IoT scenario? We’ll be happy to help you develop the right target architecture and build the data foundation for industrial analytics and AI use cases. Get in touch with us.
Domain Lead Cloud Transformation & Data Infrastructure
Private networking in Azure increases security, but it also comes with higher costs and greater architectural effort. We explain which risks are often overlooked and when private endpoints actually make sense.
The Kubernetes SIG Network and the Security Response Committee have announced the end of support for Ingress NGINX. Until March 2026, one of the most widely used Kubernetes Ingress controllers will only receive best-effort support. Here is why you should take action now.
No previous post
No next post
