The industrial world is rapidly evolving. Legacy devices speaking Modbus, low-power sensors communicating via LoRa, and modern cloud-native applications now need to coexist within a single, coherent platform. The challenge is no longer just collecting telemetry, it’s about acting on it, controlling devices remotely, and turning raw signals into operational intelligence.

This architecture presents a modern IoT reference platform built around MQTT, designed to support bidirectional communication: ingesting data from the field while also allowing operators to send commands back to devices through a secure web portal. It bridges the gap between constrained devices and cloud-scale processing, while remaining resilient, secure, and scalable.

Whether you are managing industrial equipment, smart buildings, energy systems, or distributed assets, this pattern provides a solid foundation for real-world IoT solutions.

You can choose this solution if…

This architecture is a strong fit when:

• You operate heterogeneous devices using Modbus (industrial PLCs, meters) and LoRa (low-power sensors).
• You need near real-time ingestion of telemetry data at scale.
• You want to send commands from a web portal back to devices (restart, configuration update, actuator control).
• Your IoT solution must support decoupled ingestion and processing.
• You require reliable message delivery and loose coupling between producers and consumers.
• You want a cloud-native, event-driven IoT backend on Azure.
• Security, traceability, and operational visibility are non-negotiable.

Architecture Overview

At the edge, Modbus devices (industrial controllers, meters, sensors) and LoRa devices (battery-powered sensors) communicate with a field gateway. This gateway acts as a protocol translator and aggregation point, converting Modbus and LoRa payloads into standardized MQTT messages.

The gateway publishes telemetry to a central MQTT broker using well-defined MQTT topics that encode device identity, type, and message intent (telemetry, status, command acknowledgment).

From the broker, messages are forwarded to Azure Storage Queues, providing durable buffering and decoupling between ingestion and processing. This ensures that downstream services remain resilient to spikes or temporary outages.

A set of Azure Function Apps consumes messages from the queues. These functions validate payloads, enrich data with metadata, apply business rules, and persist structured device data into Azure Cosmos DB.

On the consumption side, a Web Application provides operators with dashboards, device status, historical data, and control interfaces. When a user issues a command (for example, changing a device parameter), the request flows through an Application Gateway with WAF, reaches the backend API, and is published back to the MQTT broker using command-specific topics. The gateway then relays the command to the target device, closing the bidirectional loop.

Roles and Components

Component	Role
IoT Devices (LoRa / Modbus)	Generate telemetry data and receive control commands.
Modbus / LoRa Gateway	Aggregates field data, translates protocols, and publishes MQTT messages.
MQTT Broker	Central messaging backbone supporting bidirectional communication.
MQTT Topics	Logical channels defining telemetry, commands, and acknowledgments.
Azure Storage Queue	Buffers incoming messages and decouples ingestion from processing.
Azure Function Apps	Processes telemetry, applies rules, persists data, and emits events.
Azure Cosmos DB	Stores device state, telemetry history, and command status.
Web Application	User-facing portal for monitoring, visualization, and control.
Application Gateway (WAF)	Secures inbound traffic and protects the web and API layers.

Security

Security in IoT is not optional, it is foundational. This architecture applies defense-in-depth, protecting every layer from device to cloud.

At the edge, devices authenticate to the gateway using device-specific credentials or certificates. The gateway authenticates to the MQTT broker using secure client identities and TLS.

All communication: MQTT traffic, queue messages, API calls, is encrypted in transit using TLS. Sensitive data stored in Cosmos DB and queues is encrypted at rest using customer-managed keys.

Identity and access management is enforced through RBAC and Managed Identities, ensuring that Function Apps and web backends access only the resources they need, no secrets embedded in code.

The Application Gateway with WAF protects the web portal and APIs against common threats such as injection attacks, malformed requests, and volumetric abuse. Topic-level authorization ensures that devices can publish or subscribe only to their allowed MQTT topics, reducing blast radius in case of compromise.

From a threat modeling perspective, this design mitigates:

• Unauthorized device impersonation
• Command injection attacks
• Data exfiltration from cloud services
• Lateral movement across services

Availability

IoT platforms must operate continuously, often in environments where downtime has real-world consequences.

This architecture supports high availability by design. The MQTT broker can be deployed in a clustered or managed configuration. Storage Queues provide durable message buffering, allowing the system to absorb bursts or temporary downstream failures.

Azure Function Apps are stateless and automatically recover from failures. Cosmos DB offers built-in replication and SLA-backed availability, ensuring that device state and telemetry remain accessible.

Even if processing components are temporarily unavailable, data ingestion continues—protecting the integrity of the system.

Scalability

Scalability is achieved through horizontal, event-driven design.

As the number of connected gateways increases, the system scales horizontally by design. The Azure Event Grid MQTT broker (MQTT Namespace) supports thousands of concurrent connections and processes tens of thousands of messages per second, depending on the topic architecture, payload size, and QoS settings. Built for industrial-scale ingestion, it integrates natively with Azure services such as Event Grid and Azure Functions, making it ideal for LoRa and Modbus scenarios via edge gateways.

Storage Queues allow ingestion to scale independently from processing. Function Apps scale out automatically based on queue depth, handling spikes in telemetry without manual intervention.

Cosmos DB scales elastically to support increasing write and read throughput, while the web application can scale independently to serve more users or dashboards.

This architecture scales from hundreds to hundreds of thousands of devices with minimal redesign.

Network & Connectivity

The network topology is designed to be secure and flexible.

Gateways communicate outbound to the MQTT broker, avoiding inbound exposure from the internet. Backend services are deployed within Azure virtual networks, with controlled ingress through Application Gateway.

Private endpoints can be introduced for Cosmos DB and storage services to keep all traffic on the Azure backbone. Network segmentation ensures that ingestion, processing, and presentation layers remain isolated but connected through controlled paths.

This model supports both cloud-only and hybrid deployments, including on-premises gateways or private connectivity extensions.

Observability

Operational visibility is essential in IoT systems where failures may be silent but impactful.

This architecture integrates Application Insights and Azure Monitor to track:

• Message ingestion rates
• Processing latency
• Function execution failures
• Device connectivity and heartbeat signals

Custom logs and metrics allow teams to monitor command success rates, device responsiveness, and system health. Dashboards provide real-time insights for operators, while historical data supports trend analysis and predictive maintenance scenarios.

Observability turns raw telemetry into operational confidence.

Closing Thoughts

This IoT architecture showcases how LoRa and Modbus devices can be integrated into a cloud-native platform using MQTT as the central communication protocol. It supports not only ingestion and analytics but also secure command execution, enabling real operational intelligence at scale.

That said, if you’ve read this far, you’re probably asking yourself a few valid questions. For example:

“How do we protect the MQTT broker if it’s publicly exposed?”

You’re absolutely right to wonder. Most MQTT brokers require a public endpoint for edge connectivity, which introduces exposure. While TLS encryption, client certificates, topic-level ACLs, and IP filtering can help, a fully private deployment model is still a known limitation—especially when dealing with LoRa or Modbus gateways that don’t support advanced networking.

“Why use MQTT instead of Azure IoT Hub or IoT Edge?”

A great point. Azure IoT Hub offers robust device provisioning, security, and SDK integration—but it may be too heavy for lightweight LoRa use cases or legacy Modbus gateways. MQTT, in contrast, offers simplicity, protocol flexibility, and ecosystem compatibility. That said, IoT Hub can absolutely be an alternative in scenarios where you need tighter Azure-native integration, especially with DPS, Twin states, or Azure Defender for IoT.

“What about edge processing or offline fallback?”
This pattern focuses on the cloud backend and control loop. In industrial deployments, adding edge intelligence with Azure IoT Edge or industrial PCs might be necessary. That could be a next chapter in this series.

The goal here isn’t to prescribe a one-size-fits-all solution but to offer a reference pattern you can adapt, challenge, and evolve based on your needs, constraints, and technology stack.

If you have thoughts, alternative ideas, or use cases you’d like to explore—let’s start a conversation.