· ObjectSource GmbH · Tutorials · 4 min read
Mastering Multi-Tenant Data Isolation in Azure IoT
If you are building a SaaS platform for IoT sensors, you need to ensure that Customer A never sees Customer B's data

If you are building a SaaS platform for IoT sensors, here is how to ensure Customer A never sees Customer B’s data:
The Problem: Azure IoT Hub is a “flat” resource. By default, it doesn’t distinguish between telemetry from different customers (tenants) once it hits the cloud.
The Solution: Device Twin Tagging + Message Enrichment.
Step 1: Assign a unique
TenantIDto each device using Device Twin Tags.Step 2: Configure Message Enrichment in IoT Hub to automatically “stamp” every incoming message with its
$twin.tags.TenantID.Step 3: Use Azure Data Explorer (ADX) or Cosmos DB with Row-Level Security (RLS) to isolate data based on that stamp.
The Benefit: You can run thousands of customers on a single IoT Hub instance, dramatically reducing overhead while maintaining strict security boundaries.
Introduction: The “Crossed Wires” Crisis
Meet Chloe, the CTO of a startup that provides “Air Quality as a Service” to school districts. Business was booming until a Tuesday morning when a principal from District A logged into his dashboard and saw a massive spike in CO2 levels. He panicked and evacuated the school.
The problem? The data he saw was actually from a biology experiment in District B.
Chloe had built her solution on a shared IoT Hub but relied on the ESP32 firmware to identify the customer. When a developer accidentally swapped the IDs in a firmware update, the data streams merged. Chloe didn’t just have a technical bug; she had a trust crisis.
The lesson was clear: Never trust the device to identify itself. You need the cloud infrastructure to act as the ultimate arbiter of truth. Here is how Chloe fixed her architecture using multi-tenant isolation.
Building the SaaS Fortress
Why shouldn’t I just give each customer their own Azure IoT Hub?
While “one hub per customer” offers the highest isolation, it is an operational nightmare. Managing 500 hubs means 500 scaling policies, 500 sets of credentials, and 500 bills. For most SaaS providers, a Shared Hub model is more cost-effective and easier to manage, provided you have a robust way to tag data.
How do I “tag” data if the ESP32 can’t be trusted?
You use Device Twin Tags. When you register an ESP32 in your system, you add a TenantID to its “Tags” section in the cloud. Tags are invisible to the device itself; they live only in Azure. Even if a hacker compromises the ESP32’s firmware, they cannot change the TenantID tag associated with that hardware ID in your registry.
What is “Message Enrichment” and why is it the “Secret Sauce”?
Message Enrichment is a feature of IoT Hub that intercepts a message after it arrives but before it is routed to your database. You can tell IoT Hub: “For every message, look up the device’s Twin, find the TenantID tag, and add it as a header to the message.” This means your database (like ADX) receives a packet that is already “stamped” by a trusted source.
How do I handle multi-tenancy in the database?
Once your data reaches Azure Data Explorer (ADX), you have two main choices:
- Table-per-Tenant: Cleanest isolation, but harder to manage at scale.
- Shared Table with Row-Level Security (RLS): All data goes into one big
Telemetrytable. You create a policy that says: “When User A queries this table, only show rows whereTenantID == 'CustomerA'.” This is the industry standard for SaaS scalability.
What about the Device Provisioning Service (DPS)?
If you have multiple hubs (e.g., one for Europe, one for USA), use DPS Custom Allocation. You can write a small Azure Function that looks at the device’s TenantID during its very first connection and assigns it to the specific Hub instance dedicated to that region or customer tier.
Comparison: Tenant Isolation Models
| Feature | Hub-per-Tenant | Shared Hub (Enrichment) |
|---|---|---|
| Complexity | High (500+ Hubs) | Low (1-5 Hubs) |
| Isolation | Physical | Logical |
| Cost | High (Minimum $10/mo per tenant) | Low (Pay per message) |
| Scalability | Hard to automate | Highly automated |
Conclusion
Multi-tenancy is a balancing act between security and sanity. By leveraging Device Twin Tags and Message Enrichment, you move the responsibility of identification from the “weak” edge (the ESP32) to the “strong” cloud (Azure), ensuring that Customer A’s spikes never cause Customer B’s alarms.
Photo by Luke Heibert on Unsplash




Comments
Add Comment