Azure IoT Hub TLS 1.3 Support

Question

Azure IoT Hub TLS 1.3 Support

Stephane Simard 20

Hi,

TLS 1.3 Support has been announced as a Preview feature. What will be the procedure to migrate to TLS 1.3 for existing IoT Hub instances and devices in the field.

We are using the Device Provisioning service.

Will TLS 1.3 endpoints will be added to existing IoT Hub instances?
In the DPS, will it be possible to reconfigure the existing individual enrollment to change the IoT Hub endpoints?
Will it be possible to reprovision a device through the DPS to the exact same IoT Hub, but to the new endpoints supporting TLS 1.3?

Stephane Simard 20 Reputation points

2026-06-17T16:17:15.2033333+00:00

This is great, but it does not help to define what is the migration procedure to use the new Azure IoT Hub endpoints that support TLS 1.3 for existing IoT Hub instances and devices already enrolled?

Our idea was to reconfigure devices individual enrollments (Azure DPS) and force devices to reprovision. We need to know if it will be possible to configure the DPS to return the new IoT Hub endpoints supporting TLS1.3 to the devices (instead one the current one supporting TLS 1.2).

Moreover, will the device state (desired and reported twins) will be preserved if the device is reassigned to the exact same IoT Hub, but connecting to the new endpoints?
Stephane Simard 20 Reputation points

2026-06-18T12:34:13.08+00:00
Whether you're using individual enrollments or enrollment groups.

We are using individual enrollments.

Whether devices store the assigned IoT Hub hostname or always obtain it through DPS.

The devices are persisting the assigned IoT Hub endpoint returned by the DPS upon provisioning. However, we have logic to force a device to reprovision, ie. forget the currently assigned IoT Hub, then call the DPS to be reassigned to, protentially, a new IoT Hub. It assumes that the DPS is able to moved the device state from the initial IoT Hub to the new one.

Whether you're using X.509 certificates or symmetric keys.

We use X.509-based device identities.
Anshika Varshney 15,030 Reputation points Microsoft External Staff Moderator

2026-06-18T19:38:12.1466667+00:00
Hello @Stephane Simard

Thank you for the additional information.

Based on your architecture (individual enrollments, X.509 identities, and DPS-based reprovisioning), here are some troubleshooting steps that may help validate whether the issue is related to DPS assignment, endpoint handling, or device-side logic while planning your TLS 1.3 migration.

Verify which endpoint DPS is returning

After forcing a reprovision, capture the DPS registration response and confirm which IoT Hub hostname is returned.

Specifically check whether DPS returns:

<hub>.azure-devices.net (classic endpoint)

<hub>.device.azure-devices.net (TLS 1.3 endpoint)

This will help determine whether DPS is currently assigning the new TLS 1.3-capable endpoint.

Test reprovisioning with a pilot device

Before migrating your production fleet:

Select a test device.

Force reprovisioning through DPS.

Compare the assigned IoT Hub hostname before and after reprovisioning.

Verify device connectivity and authentication after reassignment.

Validate device-side endpoint persistence

Since devices cache the assigned IoT Hub endpoint:

Ensure the reprovisioning logic completely clears the stored endpoint.

Confirm the device is actually requesting a fresh assignment from DPS.

Verify the device doesn't reconnect using a previously cached hostname.

Check IoT Hub device identity continuity

After reprovisioning:

Verify whether the device appears under the same Device ID in IoT Hub.

Compare desired and reported properties before and after reprovisioning.

Confirm whether modules, tags, and twin data remain intact.

This will help determine whether twin state is preserved for your specific workflow.

Validate TLS 1.3 compatibility on the device

Before switching endpoints, confirm the device supports:

TLS 1.3

Server Name Indication (SNI)

Supported TLS 1.3 cipher suites

A device may successfully reprovision but still fail to connect if TLS 1.3 prerequisites are not met.

Enable diagnostic logging during testing

For your pilot migration devices:

Capture DPS registration logs

Capture device connection logs

Monitor IoT Hub connection events

Record any TLS handshake failures

This makes it easier to identify whether failures occur during:

DPS registration

Endpoint assignment

TLS negotiation

Device authentication

Compare behavior between old and new endpoints

If possible, test:

Device connecting to the classic endpoint

Same device connecting to the TLS 1.3 endpoint

Compare:

Provisioning success

Twin synchronization

Telemetry flow

Direct method execution

Cloud-to-device messaging

A controlled pilot reprovisioning test is likely the fastest way to validate the behavior in your environment before rolling it out more broadly.

Thanks for sharing the details of your implementation.

Thankyou!
Stephane Simard 20 Reputation points

2026-06-19T15:14:35.6466667+00:00

How can I have the TLS 1.3 Support feature enabled on one of a DPS and one IoT Hubs instance to test the provided procedure?

Answer accepted by question author

AI answer

TLS 1.3 support for Azure IoT Hub is provided via new, additional endpoints and does not replace the existing endpoint. Migration is optional and customer-controlled.

Answers to the specific questions:

Will TLS 1.3 endpoints be added to existing IoT Hub instances?
Yes. Existing IoT hubs keep their classic endpoint (<hub>.azure-devices.net) with TLS 1.2, and additional TLS 1.3-capable endpoints are provided alongside it:

Device endpoint (preview): <hub>.device.azure-devices.net
Service endpoint (preview): <hub>.service.azure-devices.net

These new endpoints support TLS 1.3 and restricted TLS 1.2 cipher suites. Existing applications and devices using the classic endpoint continue to work without changes.

In DPS, will it be possible to reconfigure existing individual enrollments to change the IoT Hub endpoints?
The provided information for DPS focuses on TLS 1.2 support and the minTlsVersion setting. It does not describe changing IoT Hub hostnames or endpoints within existing enrollments, so no procedure can be derived from this context.
Will it be possible to reprovision a device through DPS to the same IoT Hub but using the new TLS 1.3 endpoints?
From the available information, DPS currently supports TLS 1.2 and uses standard IoT Hub hostnames. The context does not describe a specific reprovisioning workflow or configuration to move devices from the classic endpoint to the new TLS 1.3-capable endpoints, so no explicit procedure can be stated.

What is clear from the context:

TLS 1.3 is available only on the new device and service endpoints (<hub>.device.azure-devices.net and <hub>.service.azure-devices.net).
The classic endpoint (<hub>.azure-devices.net) remains fully supported with TLS 1.2 and continues to be the default, including for Private Link scenarios.
Adoption of TLS 1.3 endpoints is optional, additive, and can be done gradually based on device and solution readiness.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

1 additional answer

Your answer

Stephane Simard 20 Reputation points

2026-06-17T16:17:15.2033333+00:00

This is great, but it does not help to define what is the migration procedure to use the new Azure IoT Hub endpoints that support TLS 1.3 for existing IoT Hub instances and devices already enrolled?

Our idea was to reconfigure devices individual enrollments (Azure DPS) and force devices to reprovision. We need to know if it will be possible to configure the DPS to return the new IoT Hub endpoints supporting TLS1.3 to the devices (instead one the current one supporting TLS 1.2).

Moreover, will the device state (desired and reported twins) will be preserved if the device is reassigned to the exact same IoT Hub, but connecting to the new endpoints?
Stephane Simard 20 Reputation points

2026-06-18T12:34:13.08+00:00

Whether you're using individual enrollments or enrollment groups.

We are using individual enrollments.

Whether devices store the assigned IoT Hub hostname or always obtain it through DPS.

The devices are persisting the assigned IoT Hub endpoint returned by the DPS upon provisioning. However, we have logic to force a device to reprovision, ie. forget the currently assigned IoT Hub, then call the DPS to be reassigned to, protentially, a new IoT Hub. It assumes that the DPS is able to moved the device state from the initial IoT Hub to the new one.

Whether you're using X.509 certificates or symmetric keys.

We use X.509-based device identities.
Stephane Simard 20 Reputation points

2026-06-19T15:14:35.6466667+00:00

How can I have the TLS 1.3 Support feature enabled on one of a DPS and one IoT Hubs instance to test the provided procedure?

Answer 1

Hello @Stephane Simard

Based on the Azure IoT Hub TLS documentation, TLS 1.3 support is being introduced through new IoT Hub endpoints, while the existing *.azure-devices.net endpoint continues to support TLS 1.2. The migration to TLS 1.3 is designed to be customer-controlled and can be performed gradually as devices become TLS 1.3 capable.

Existing IoT Hubs

You do not need to create a new IoT Hub to use TLS 1.3. The documentation indicates that TLS 1.3 is available through newly introduced endpoints associated with the IoT Hub, while the classic endpoint remains available for TLS 1.2 clients.

DPS and Reprovisioning

The current documentation does not explicitly describe:

Whether existing DPS enrollments can be updated to automatically return the new TLS 1.3 endpoints.
Whether reprovisioning a device through DPS to the same IoT Hub changes the endpoint hostname returned to the device.
How device twin state is affected when moving between the classic and TLS 1.3 endpoints.

Therefore, I cannot confirm these behaviors based solely on the published documentation.

What we do know

TLS 1.3 connections use the new IoT Hub endpoints.
The classic *.azure-devices.net endpoint remains available for TLS 1.2 devices.
Migration can be performed incrementally, allowing customers to transition devices as needed.
TLS 1.3 endpoints require SNI support and use a restricted set of modern cipher suites.

To better understand the DPS migration scenario, it would be helpful to know:

Whether you're using individual enrollments or enrollment groups.
Whether devices store the assigned IoT Hub hostname or always obtain it through DPS.
Whether you're using X.509 certificates or symmetric keys.

Reference: Azure IoT Hub TLS support

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

If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

Thankyou!