Microsoft has announced security enhancements across Azure IoT services.

Users managing connected devices get a modern transport-security baseline with TLS 1.3 for Azure IoT Hub, identity-based provisioning that removes long-lived secrets with managed identity support for linking an IoT Hub to DPS, and encrypted update delivery with TLS downloads for device updates for IoT Hub.

TLS 1.3 and managed identity are in public preview; TLS downloads are generally available.

Azure IoT Hub now supports TLS 1.3 through new endpoints that sit alongside the existing classic endpoint.

The new device and service endpoints support TLS 1.3, and support TLS 1.2 with a reduced, security-compliant cipher suite. Devices connect through the device endpoint for device-to-cloud telemetry and cloud-to-device messages, while backend and management applications built on the service SDK connect through the service endpoint.

The existing endpoint remains available, so users can adopt the endpoints on their own timeline rather than through a forced migration. No enablement action is needed: the endpoints are provisioned automatically on new and existing hubs, and users adopt TLS 1.3 by pointing their device or service clients at the new hostnames.

TLS 1.3 provides a more modern security baseline for IoT connectivity. The release introduces a clearer separation between device traffic and service traffic through dedicated endpoints, which makes the connectivity model easier to understand and evolve over time.

This design also reflects how real IoT deployments work. Many users cannot update every device or backend integration at once, so a side-by-side endpoint model helps teams test, validate and roll out changes in stages.

DPS links to an IoT Hub securely to assign devices to the right hubs at scale and, until now, that link has relied on connection-string (shared access key) authentication. This dependency on a shared key results in users keeping local authentication enabled on the IoT Hub, even when their security policies call for disabling it in favour of Microsoft Entra ID.

Managed identity support removes that constraint: DPS can now authenticate to IoT Hub using a managed identity backed by Microsoft Entra ID so the hub linking no longer requires a connection string. As a result, users can disable local authentication on the IoT Hub, remove long-lived shared keys from the provisioning path, and simplify credential lifecycle management and security governance with no shared keys to rotate, store or accidentally leak.

Together, TLS 1.3 and managed identity strengthen the same hub linking scenario: TLS 1.3 modernises how devices and services connect to IoT Hub, while managed identity gives Azure services credential-free authentication during provisioning.

Device updates for IoT Hub can now deliver update content over HTTPS, encrypting update content in transit between the device update service and the devices. For those managing large fleets, this brings update delivery in line with the same modern transport-security expectations now applied to device and service connectivity, and helps teams meet encryption-in-transit and compliance requirements.

Download security is a deployment-level setting available in the device update data plane API version 2026-06-01. New deployments created with this version use HTTPS by default, while existing deployments continue using their current configuration. Those that require HTTP downloads can still explicitly select HTTP.

With these enhancements, Azure IoT services are taking a step towards secure, modern device onboarding, connectivity and lifecycle management. TLS 1.3 (learn.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support#tls-13-support-preview) modernises how devices and services connect, managed identity (learn.microsoft.com/en-us/azure/iot-dps/how-to-manage-linked-iot-hubs) removes secrets from the provisioning flow, and TLS download (learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-tls-download) protects update content in transit. Each addresses a different layer of the security model.