Azure IoT Hub 2 Routing Rule with same messages and destination

Just noticed a feature in Azure Portal, where we could perform "Change Authentication Type". I tested with this feature, then we could perform the below:-

1. In IoT Hub, turn on system managed identity.
2. In Service Bus, grant "Service Bus Data Sender" access to the IoT Hub's system managed identity.
3. Now, in the IoT Hub, go the the existing routing(s), switch the authentication type to "System-assigned".
4. Finally, in the Service Bus, disable public access and "allow trusted service"

With above steps, there are a few seconds delay of message routing during the switch of auth type which is acceptable.

Anyway, much appreciate the replies above :)

Hello John Wong Yek Hon,

welcome to this moderated Azure community forum.

I read through the answer coming from @SRILAKSHMI C .

The IoT Hub indeed has no deduplication logic.

We basically always need to prepare for duplicate data. An IoT Hub has an at-least-once delivery policy, the same goes for eg. an EventHub.

Deduplication is normally done downstream, eg. in the Azure Data Explorer database (Fabric Eventhouse) using a materialized view or via Azure Stream Analytics which can help you with that too.

I recommend an architecture able to cope with duplicate values. Then just have a solution for always.

But just wild idea, playing with Azure IoT Hub features, are you able to add a query rule on the IoT Hub based on message body values? If so, is there a timestamp inside that message?

Then, technically, you could have two routes each having an opposite query:

In pseudo code:
- Original route: 
- New route: $body.Weather.timestamp >= '2026-12-31T00:00:00.000Z'

Check the operators of the query.

Check if requirements on the message format (application properties) being sent by the devices:

using (var message = new Message(messageBytes))
  {
    message.ContentEncoding = "utf-32";
    message.ContentType = "application/json";
 
    await deviceClient.SendEventAsync(message);
  }

Then you will notice a switch over per route.

This is just thinking out-of-the-box. Please test this. Have fun :-)

--

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

Hello John Wong Yek Hon,

Welcome to Microsoft Q&A and Thank you for reaching out.

You’re right to think carefully about this migration, especially with the goal of minimizing downtime while tightening security using a private endpoint. However, there is an important routing behavior in Azure IoT Hub to be aware of.

Key clarification on IoT Hub routing behavior

Azure IoT Hub does not deduplicate messages across routing rules. Each routing rule is evaluated independently. If multiple routing rules match the same D2C message, IoT Hub will attempt to deliver that message once per matching rule.

This means:

• If two routing rules are active at the same time

Both match the same set of D2C messages

Both route to the same Service Bus queue

The Service Bus queue will receive duplicate messages (one copy per rule). There is no “only one rule wins” or competition logic, and messages will not be merged or dropped automatically.

So while messages will not be lost, duplication is expected and by design if routes overlap.

Why this happens

IoT Hub routing is intentionally fan-out based, allowing the same message to be sent to multiple endpoints. IoT Hub does not have awareness that two routes point to the same physical destination.

Impact on your migration plan

Running the old (key-based) route and the new (managed identity / trusted Microsoft services) route in parallel to the same queue is technically supported, but it will result in duplicate messages during the overlap period.

Recommended approaches to minimize downtime without duplicates

1: Controlled cutover

Create the new Service Bus endpoint with private endpoint and managed identity.

Create the new IoT Hub route, but with a query that does not match live traffic yet.

Validate permissions and connectivity.

Disable the old routing rule.

Update the new routing rule query to match production messages.

Disable public access on the Service Bus.

This avoids any overlap and prevents duplication.

2: Temporary validation destination

• Route the new rule to a temporary Service Bus queue for testing.
• Once validated, switch it to the production queue and disable the old rule.

3: Downstream deduplication

If a short overlap window is acceptable:

Enable Service Bus duplicate detection

Ensure devices set a deterministic messageId

This mitigates duplicates at the Service Bus level, but does not change IoT Hub routing behavior.

Best practices

• Use IoT Hub route test functionality to validate routing queries before enabling them.
• Monitor Routing Deliveries and Routing Latency metrics during the transition.
• Keep the fallback route enabled to avoid accidental message drops due to misconfigured queries.

Please refer this

• Use IoT Hub message routing to send device-to-cloud messages to Azure services
• Check Endpoint Health
• Troubleshooting Steps for IoT Hub
• Endpoint Health Status

I Hope this helps. Do let me know if you have any further queries.

Thank you!