Transport Layer Security (TLS) support in IoT Hub

IoT Hub uses Transport Layer Security (TLS) to secure connections from IoT devices and services.

Mutual TLS support

Mutual TLS authentication ensures that the client authenticates the server (IoT Hub) certificate and the server (IoT Hub) authenticates the client using X.509 client certificate or X.509 thumbprint. IoT Hub performs authorization after authentication is complete.

For Advanced Message Queuing Protocol (AMQP) and Message Queuing Telemetry Transport (MQTT) protocols, IoT Hub requests a client certificate in the initial TLS handshake. If one is provided, IoT Hub authenticates the client certificate, and the client authenticates the IoT Hub certificate. This process is called mutual TLS authentication. When IoT Hub receives an MQTT connect packet or an AMQP link opens, IoT Hub performs authorization for the requesting client and determines if the client requires X.509 authentication. If mutual TLS authentication was completed and the client is authorized to connect as the device, it's allowed. However, if the client requires X.509 authentication and client authentication wasn't completed during the TLS handshake, then IoT Hub rejects the connection.

For HTTP protocol, when the client makes its first request, IoT Hub checks if the client requires X.509 authentication and if client authentication was complete then IoT Hub performs authorization. If client authentication wasn't complete, then IoT Hub rejects the connection.

After a successful TLS handshake, IoT Hub can authenticate a device using a symmetric key or an X.509 certificate. For certificate-based authentication, IoT Hub validates the certificate against the thumbprint or certificate authority (CA) you provide. To learn more, see Authenticate identities with X.509 certificates.

IoT Hub's server TLS certificate

During a TLS handshake, IoT Hub presents RSA-keyed server certificates to connecting clients. All IoT hubs in the global Azure cloud use the TLS certificate issued by the DigiCert Global Root G2.

Trust the following two root CAs for all devices:

• DigiCert Global G2 root CA
• Microsoft RSA root CA 2017

For links to download these certificates, see Azure Certificate Authority details.

Root CA migrations are rare. Always prepare your IoT solution for the unlikely event that a root CA is compromised and an emergency root CA migration is necessary.

Cipher suites

Starting August 31, 2025, IoT Hub enforces the use of recommended strong cipher suites for all existing and new IoT Hubs. Non-recommended (weak) cipher suites aren't supported after this date.

To comply with Azure security policy for a secure connection, IoT Hub only supports the following RSA and ECDSA cipher suites:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

The following non-recommended cipher suites are allowed on hubs without minTlsVersion:1.2 until August 31, 2025:

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA

A client can suggest a list of higher cipher suites to use during ClientHello. However, IoT Hub might not support some of them, for example, ECDHE-ECDSA-AES256-GCM-SHA384. In this case, IoT Hub tries to follow the preference of the client but eventually negotiates down the cipher suite with ServerHello.

Update IoT Hub to TLS 1.2 support

After you create an IoT Hub, update the minTlsVersion property by using the Azure portal, CLI, or SDKs. To update the IoT Hub to enforce TLS 1.2 and strong cipher suites (only allowed in selected regions) or to set TLS 1.2 support (supported in all regions), follow these steps.

To update IoT Hub to support TLS 1.2 and/or enforce strong cipher suites in Azure portal:

1. Navigate to your existing IoT Hub in the Azure portal.

2. In the Overview tab in the left menu, select the Minimum TLS Version link from the Essentials section.

   

3. From the Minimum TLS version side window, select 1.2 to ensure that only devices supporting TLS 1.2 or higher can connect.

4. Select Update.

   

Enforce IoT Hub to use TLS 1.2 and strong cipher suites

To ensure your IoT devices comply with TLS 1.2 and strong cipher suites, enforce compliance by using the minimum TLS enforcement feature in Azure IoT Hub.

To enable TLS 1.2 and strong cipher suites enforcement in the Azure portal:

1. Go to the IoT Hub create wizard in Azure portal.

2. Choose a Region from the list of supported regions.

3. Under Management -> Advanced -> Transport Layer Security (TLS) -> Minimum TLS version, select 1.2. This setting only appears for IoT hubs created in supported regions.

   

4. Select Create.

5. Connect your IoT devices to this IoT Hub.

To use an ARM template for creation, provision a new IoT Hub in any of the supported regions and set the minTlsVersion property to 1.2 in the resource specification:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Devices/IotHubs",
            "apiVersion": "2020-01-01",
            "name": "<provide-a-valid-resource-name>",
            "location": "<any-of-supported-regions-below>",
            "properties": {
                "minTlsVersion": "1.2"
            },
            "sku": {
                "name": "<your-hubs-SKU-name>",
                "tier": "<your-hubs-SKU-tier>",
                "capacity": 1
            }
        }
    ]
}

The created IoT hub resource refuses device and service clients that attempt to connect by using TLS versions 1.0 and 1.1. Similarly, the TLS handshake is refused if the ClientHello message doesn't list any of the recommended ciphers.

Check TLS versions and cipher suites for IoT Hub devices

Azure IoT Hub provides the capability to check the TLS version, cipher suites, and other device connection metrics to help monitor the security of IoT devices. You can use either IoT Hub metrics or diagnostic logs to track TLS version usage and other related properties like Cipher Suites.

Check TLS versions and cipher suites using IoT Hub metrics

To validate that device traffic to IoT Hub uses TLSv1.2 and strong cipher suites, check IoT Hub metrics. You can filter by TLS version or cipher suite and check the number of successful connections.

1. In the Azure portal, go to your IoT hub.

2. In the left-side menu under Monitoring, select Metrics.

3. Add the metric Successful Connects.

   

4. Filter by TLS version or cipher suite by selecting the Add filter button and choosing the appropriate property, TLS version or cipher suite, operator, such as "=", and value, such as TLSv1.2.

   

5. After you apply the filter, you see the sum of devices with successful IoT Hub connections based on the filtered property and values.

Check TLS versions and cipher suites by using IoT Hub diagnostic logs

Azure IoT Hub can provide diagnostic logs for several categories that you can analyze by using Azure Monitor Logs. In the connections log, you can find the TLS version and cipher suite for your IoT Hub devices.

To view these logs, follow these steps:

1. In the Azure portal, go to your IoT hub.

2. In the left-side menu under Monitoring, select Diagnostic settings. Ensure diagnostic settings have Connections checked.

3. In the left-side menu under Monitoring, select Logs.

4. Enter the following query:

   AzureDiagnostics
   | where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
   | where Category == "Connections"
   | where OperationName == "deviceConnect"
   | extend props_json = parse_json(properties_s)
   | project DeviceId = props_json.deviceId, TLSVersion = props_json.tlsVersion
   

5. An example of the query results looks like this:

   

TLS configuration for SDK and IoT Edge

Use the following links to configure TLS 1.2 and allowed ciphers in IoT Hub client SDKs.

IoT Edge devices can be configured to use TLS 1.2 when communicating with IoT Hub. For this purpose, use the IoT Edge documentation page.

Elliptic Curve Cryptography (ECC) server TLS certificate

While offering similar security to RSA certificates, ECC certificate validation (with ECC-only cipher suites) uses up to 40% less compute, memory, and bandwidth. These savings are important for IoT devices because of their smaller profiles and memory, and to support use cases in network bandwidth limited environments.

To use IoT Hub's ECC server certificate:

1. Ensure all devices trust the following root CAs:
   • DigiCert Global G2 root CA
   • Microsoft RSA root CA 2017
2. Configure your client to include only ECDSA cipher suites and exclude any RSA ones. These are the supported cipher suites for the ECC certificate:
   • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
   • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
   • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
3. Connect your client to the IoT hub.

TLS maximum fragment length negotiation

IoT Hub also supports TLS maximum fragment length negotiation, which is sometimes known as TLS frame size negotiation. This feature is in public preview.

Use this feature to specify the maximum plaintext fragment length to a value smaller than the default 2^14 bytes. Once negotiated, IoT Hub and the client begin fragmenting messages to ensure all fragments are smaller than the negotiated length. This behavior is helpful to compute or memory constrained devices. To learn more, see the official TLS extension spec.

Official SDK support for this public preview feature isn't yet available. To get started

1. Create an IoT Hub.
2. When using OpenSSL, call SSL_CTX_set_tlsext_max_fragment_length to specify the fragment size.
3. Connect your client to the IoT Hub.

Certificate pinning

Certificate pinning and filtering of the TLS server certificates and intermediate certificates associated with IoT Hub endpoints is strongly discouraged as Microsoft frequently rolls these certificates with little or no notice. If you must, only pin the root certificates as described in this Azure IoT blog post.

TLS 1.3 (Preview) behavior and requirements

Azure IoT Hub supports TLS 1.3 through newly introduced endpoints. TLS 1.3 isn't exposed through the existing (classic) endpoint.

Key behaviors

• TLS 1.3 is available only via the new device and service endpoints (<hub>.device.azure-devices.net and <hub>.service.azure-devices.net).
• The classic endpoint (<hub>.azure-devices.net) continues to support TLS 1.2.

Requirements for new endpoints

The TLS 1.3-capable endpoints introduce stricter security requirements:

• Server Name Indication (SNI) is required.
• Only restricted, security-compliant cipher suites are supported.

TLS 1.2 compatibility

• Devices using TLS 1.2 can still connect to the new endpoints.
• This support exists only if the client supports the required cipher suites.

Migration guidance

• Adoption of TLS 1.3 endpoints is optional and customer-controlled.
• Customers can continue using the classic endpoint indefinitely.
• Migration can be performed gradually, based on device and solution readiness.

Next steps

• To learn more about IoT Hub security and access control, see Control access to IoT Hub.
• To learn more about using X509 certificate for device authentication, see Device Authentication using X.509 CA Certificates.