Devices lose connection to the Azure IoT Hub due to outdated TLS ciphers

Question

Devices lose connection to the Azure IoT Hub due to outdated TLS ciphers

Hoge, Florian 0

Hello,

We observed that since the night of June 30 to July 1, 2026, approximately half of our IoT devices currently deployed in the field have no longer been able to connect to the Azure IoT Hub.

After a brief analysis, we were able to identify the root cause based on the IoT Hub error logs: the affected devices do not support a currently accepted TLS cipher and are therefore unable to establish a connection.

No strong TLS ciphers available to connect to IoT Hub. For more information, see https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support.

By reviewing the connection logs from the past few weeks, we determined that up until July 1, the affected devices were using the outdated cipher TLS_RSA_WITH_AES_256_CBC_SHA256, which is also listed in the documentation as no longer being supported. Therefore, we assume that the change of the supported TLS ciphers for our IoT Hub took place during the night of July 1, resulting in the support removal of the outdated cipher that had previously been negotiated by these devices.

Unfortunately, it is not possible for us to update the affected devices to a supported cipher within a short timeframe. We would therefore like to ask whether it would be possible to temporarily re-enable support for this cipher for a fixed period of time.

We are aware that this cipher is outdated and contains security risks. However, restoring support temporarily would provide us with valuable time to evaluate and implement technical alternatives.

We would appreciate your feedback. Thank you very much.

0 comments

2 answers

Your answer

Answer 1

Hello @Hoge, Florian

Thanks for the thorough diagnosis pulling the connection logs and pinpointing the exact cipher is the hard part, and it makes this straightforward to answer (even if it isn't the answer you were hoping for).

Short version: there's no way to temporarily re-enable TLS_RSA_WITH_AES_256_CBC_SHA, either as a hub setting or via a support exception. What you're hitting is the Azure-wide strong-cipher enforcement that took effect August 31, 2025, and per the documentation it applies to all existing and new IoT Hubs — "non-recommended (weak) cipher suites aren't supported after this date." It isn't tied to a minTlsVersion change on your hub, so there's no per-resource rollback; the removal is at the service/platform layer. Enforcement has been rolling out progressively, which is why some devices kept connecting past the formal date before finally being refused.

Why your devices break: the TLS_RSA_* suites are static-RSA (no forward secrecy) and were removed. IoT Hub now accepts only these strong suites — the common thread is ECDHE: ECDHE-RSA

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

ECDHE-ECDSA (public-cloud regions only)

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

Your device's TLS stack needs to offer an ECDHE suite in its ClientHello. One gotcha that trips up embedded stacks: when offering an ECDHE/ECDSA cipher, the client must also include a valid supported_groups (elliptic-curves) extension in the ClientHello, or the handshake still fails.

Permanent fix — firmware/TLS-stack update on the Quectel modules. If they use the Azure IoT C SDK, get on a TLS 1.2–capable tag and confirm the underlying TLS library (mbedTLS/OpenSSL/wolfSSL) is built to offer ECDHE suites plus a curve. If a given module genuinely can't do ECDHE at all, that unfortunately means a firmware variant change or device replacement — there's no server-side accommodation for static-RSA anymore.

Interim bridge to keep field devices online while you roll out firmware. The supported pattern is a local gateway that terminates the device's legacy TLS and re-originates a compliant connection to IoT Hub — for example, an Azure IoT Edge transparent/protocol gateway deployed near the fleet: devices connect to Edge locally, and Edge connects to IoT Hub with a modern cipher. A self-managed reverse proxy you control can work too, but note two constraints: (1) it must be on infrastructure that can accept the retired cipher inbound — most managed Azure frontends (App Service/Functions) also enforce strong ciphers, so they generally can't accept the legacy handshake and (2) it must preserve each device's IoT Hub identity/auth and MQTT semantics. So plan the bridge as local-gateway infrastructure, not a simple cloud TLS relay.

Pinpoint exactly which devices are still on the bad cipher. Use IoT Hub → Metrics → Successful connects and add a filter on the Cipher Suite (and/or TLS version) dimension — this shows the count of successful connections per cipher, so you can watch the fleet migrate in real time. For per-device TLS version you can also use the Connections diagnostic logs (note: TLS-version logging isn't available for devices connecting over HTTPS):

AzureDiagnostics

| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"

| where Category == "Connections" and OperationName == "deviceConnect"

| extend props = parse_json(properties_s)

| project DeviceId = props.deviceId, TLSVersion = props.tlsVersion

For the fully-disconnected devices: Device Update for IoT Hub only works for devices that can still reach the hub, so you'll need an out-of-band path — Quectel's own cellular FOTA (check their module docs for the relevant AT commands) or local USB/serial update. Getting a first wave back online via the gateway lets you then use Device Update for the rest.

One more defensive note: avoid any device logic that pins to a specific intermediate CA — Microsoft rotates those, and it's a second, independent way fleets like this break.

I'm sorry this lands as a hard "no" on the rollback, but the fastest route back to green is a staged firmware push to an ECDHE suite, with the Metrics cipher filter tracking recovery.

Links :

IoT Hub TLS support (supported cipher suites & enforcement):
https://learn.microsoft.com/azure/iot-hub/iot-hub-tls-support
Check TLS versions & cipher suites (metrics + KQL):
https://learn.microsoft.com/azure/iot-hub/iot-hub-tls-support#check-tls-versions-and-cipher-suites-for-iot-hub-devices
IoT Hub monitoring data reference (connect.success → TLSCipher dimension):
https://learn.microsoft.com/azure/iot-hub/monitor-iot-hub-reference#metrics
Configure TLS 1.2 in the IoT client SDKs:
https://learn.microsoft.com/azure/iot-hub/iot-hub-tls-support#tls-configuration-for-sdk-and-iot-edge
IoT Edge as a transparent gateway:
https://learn.microsoft.com/azure/iot-edge/iot-edge-as-gateway
Device Update for IoT Hub:
https://learn.microsoft.com/azure/iot-hub-device-update/understand-device-update

Thanks,
Manish

Answer 2

Martin Jørgensen 86

Hi @Hoge, Florian

We got the same issue.

How do you get the logs from IotHub? (via Monitoring->Logs?)

But I have been able to get them online again using a AzureFunction as proxy.

But it requires, that you are able to route the "host" url to the azure function.

The morning, 1st of July was not great :-)

Next step is to update Quectel modules with new firmware in order to support more modern ciphers...

BR Martin

Julien Wan 0 Reputation points

2026-07-08T07:17:49.37+00:00

Hi @Martin Jørgensen
How were you able to change the URL if your devices were offline ?
have a nice day!
Martin Jørgensen 86 Reputation points

2026-07-08T07:46:41.9066667+00:00

@Julien Wan I am sorry to hear about your issue!!!

Perhaps I am using IotHub a little bit different than others... I have used it for approx. 10 years, and in 2016 there was no Device Provisioning Service (DPS).
Therefore I have my own "provisioning", which supplies the configuration details (and SAS tokens) for my devices (at every reboot).
So I was able to update the Host.
I normally used frontdoor Microsoft service (to allow use of my own private certificate) for the configuration, but has changed that to a virtual machine (linux) due to cracy pricing for a frontdoor service.

I also ended up having A LOT of offline devices starting the night between 30/6 and 1/7.

I do not understand why Microsoft has done this. A few years ago, where TLS1.2 needed to be tested, I did that. And did not find an issue. But now where cipher suites are changed, I do not think Microsoft did a good job of telling the customers. I have not seen anything about you needed to test the cipher changes (or instruction how to create an iothub with limited ciphers).

Also the baltimore/digicert change was communicated a lot better a few years ago!

A have also helped other companies implementing iothub, and I really never understood, that anyone would rely 100% on iothub, without a way of at least perform a device firmware update in a different way than relying on iothub.

I believe Microsoft SHOULD revert this change (not for me), but for all other, who has put the faith in iothub without having an alternative way of updating the devices.

I found out, that most of my devices were able to use the ciphers, which are available on a standard azurefunction. I guess there is approx. 16 supported ciphers. But I also have devices, which were not able to use my azurefunction proxy. They are now using a virtual maching (linux) proxy, untill I can update Quectel firmware...

I wish you the best regarding this issue. I know the feeling and pressure, when a lot of devices are only. I have also questioned myself, what I could have done different. Because I do not believe I did a professional job... But it seems like, I am not the only one being caught on the wrong foot.

BR Martin
Julien Wan 0 Reputation points

2026-07-08T11:34:45.63+00:00

Thank you very much for sharing your experience. There are lessons to learn here.