Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
IoT Hub uses Transport Layer Security (TLS) to secure connections from IoT devices and services.
Note
Azure IoT Hub will end support for TLS 1.0 and 1.1 in alignment with the Azure wide service announcement for TLS 1.0 and 1.1 retirement on August 31, 2025. In addition, IoT Hub will no longer support weak cipher suites as of August 31, 2025. Only recommended strong cipher suites will be supported for both existing and new IoT Hubs.
Beginning August 31, 2025, the Azure IoT Hub team will begin proactively enforcing TLS 1.2 and strong cipher suites across all IoT Hubs. This enforcement is part of our broader commitment to strengthening security and ensuring compliance across Azure services.
It's therefore essential that you properly test and validate that all your IoT devices are compatible with TLS 1.2 and the recommended ciphers in advance.
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.
We strongly recommend that all devices trust the following three root CAs:
- 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. You should 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 will enforce the use of recommended strong cipher suites for all existing and new IoT Hubs. Non-recommended weak cipher suites will no longer be supported past 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_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 negotiate down the cipher suite with ServerHello
.
TLS configuration for SDK and IoT Edge
Use the following links to configure TLS 1.2 and allowed ciphers in IoT Hub client SDKs.
Language | Versions supporting TLS 1.2 | Documentation |
---|---|---|
C | Tag 2019-12-11 or newer | Link |
Python | Version 2.0.0 or newer | Link |
C# | Version 1.21.4 or newer | Link |
Java | Version 1.19.0 or newer | Link |
Node.js | Version 1.12.2 or newer | Link |
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.
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.
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