Production devices disconnected from Azure IoT Hub - deprecated TLS 1.2 cipher no longer accepted

Hi @Greg Melson ,

Thanks for the detailed writeup — this is genuinely useful context. What you're seeing is a security enforcement rollout, not a bug or a certificate issue on your hub. Let me go through your questions one by one.

1. What changed around July 1, 2026? Nothing new was introduced that day — this is the tail end of a change Azure announced back in 2025. IoT Hub ended support for TLS 1.0/1.1 and stopped supporting weak cipher suites as of August 31, 2025, as part of an Azure-wide TLS retirement, and only recommended strong cipher suites are supported on existing and new hubs. The catch is that enforcement wasn't a single global cutover — Microsoft has been proactively enforcing TLS 1.2 and strong cipher suites across all IoT Hubs in waves since that date. Several other customers reported the exact same disconnect pattern in early July 2026, so your hub almost certainly got caught by one of these later enforcement waves rather than anything you configured. Azure Docs + 2
2. Has cipher enforcement changed or is it being applied differently now? The policy hasn't changed — TLS_RSA_WITH_AES_256_CBC_SHA / SHA256 were already on the non-recommended list. What's changed is that the backend is now actively blocking them even on hubs that never had minTlsVersion explicitly set to 1.2. So if your hub was quietly "grandfathered" onto legacy ciphers before, that grace period is what closed on July 1.
3. Can we temporarily relax enforcement or restore June 30 behavior? Unfortunately, no — this isn't a per-hub toggle you or we can flip back. RSA-only, non-forward-secret ciphers like yours were formally retired almost a year ago, so there's no supported flag to re-enable them. You can open a support case to ask about a short bridging exception while firmware rolls out, but treat that as a best-effort, time-boxed accommodation rather than something guaranteed — the product group has been explicit in other threads that these exceptions are temporary and not being extended indefinitely.
4. Exact cipher/cert requirements so you can validate firmware To connect today, devices need TLS 1.2 with one of these strong 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
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (public cloud only)
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (public cloud only)
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (public cloud only)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (public cloud only)

A couple of things that trip firmware up: if you're negotiating ECDHE, your ClientHello must include a valid supported_groups extension, and if you're using a client certificate, the curve in that cert has to be listed there too. On the cert-chain side, trust the DigiCert Global G2 root CA and Microsoft RSA Root CA 2017 — full download links are in the Azure CA details doc below.

How to formally request an exception / extended transition Open a support request in the Azure Portal (Help + support → New support request, Issue type Technical, Service IoT Hub), include your hub's resource ID and rough device count/timeline for the firmware rollout. The IoT Hub team reviews these case‑by‑case. Given the cipher was already past its deprecation date, I'd plan for this to buy you weeks, not months — the firmware update is really the only durable fix here.

One practical step in the meantime: you can quantify exactly which devices/ciphers are failing using IoT Hub's Connections diagnostic logs or the "Successful Connects" metric filtered by TLS version/cipher suite — that'll help you prioritize the rollout instead of updating all ~devices blind.

Thanks,
Manish.

There is no supported per-hub rollback or exception for weak cipher suites now. IoT Hub retired TLS 1.0/1.1 and non-recommended ciphers on August 31, 2025; changing minTlsVersion cannot restore them.

Supported TLS 1.2 suites are ECDHE_ECDSA or ECDHE_RSA with AES_128_GCM_SHA256, AES_256_GCM_SHA384, AES_128_CBC_SHA256, or AES_256_CBC_SHA384. The ClientHello must also contain a valid supported_groups extension for ECDHE.

Capture a failing ClientHello to confirm the offered suites and groups. If the firmware only supports a TLS_RSA_* suite, the durable fix is updated firmware or device replacement. A temporary, isolated gateway that accepts the legacy device connection and reconnects to IoT Hub with a supported ECDHE suite is the practical bridge during rollout.