Implement feedback; switch migration doc to past tense

Author: kgremban

articles/iot-dps/tls-support.md

@@ -7,7 +7,7 @@ author: kgremban
 ms.author: kgremban
 ms.service: azure-iot-hub
 ms.topic: concept-article
-ms.date: 09/15/2022
+ms.date: 11/27/2024
 ms.subservice: azure-iot-hub-dps
 ---
 
@@ -59,7 +59,7 @@ az deployment group create -g <your resource group name> --template-file templat
 
 For more information on creating DPS resources with Resource Manager templates, see, [Set up DPS with an Azure Resource Manager template](quick-setup-auto-provision-rm.md).
 
-The DPS resource created using this configuration will refuse devices that attempt to connect using TLS versions 1.0 and 1.1.
+The DPS resource created using this configuration refuses devices that attempt to connect using TLS versions 1.0 and 1.1.
 
 > [!NOTE]
 > The `minTlsVersion` property is read-only and cannot be changed once your DPS resource is created. It is therefore essential that you properly test and validate that *all* your IoT devices are compatible with TLS 1.2 and the [recommended ciphers](#recommended-ciphers) in advance.
@@ -77,7 +77,7 @@ DPS instances enforce the use of the following recommended and legacy cipher sui
 
 ### Legacy cipher suites
 
-These cipher suites are currently still supported by DPS but will be depreciated. Use the recommended cipher suites above if possible.
+These cipher suites are still supported by DPS but will be depreciated. Use the recommended cipher suites if possible.
 
 | Option #1 (better security) |
 | :--- |
@@ -93,7 +93,7 @@ When DPS enrollments are configured for X.509 authentication, mutual TLS (mTLS)
 
 ## Server TLS certificate
 
-During a TLS handshake, DPS presents RSA-keyed server certificates to connecting clients. All DPS instances in the global Azure cloud use the TLS certificate issued by the DigiCert Global Root G2. The [device SDKs](./iot-hub-devguide-sdks.md) include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to DPS and IoT Hub.
+During a TLS handshake, DPS presents RSA-keyed server certificates to connecting clients. All DPS instances in the global Azure cloud use the TLS certificate issued by the DigiCert Global Root G2 certificate. 
 
 We also recommend adding the Microsoft RSA Root Certificate Authority 2017 certificates to your devices to prevent disruptions in case the DigiCert Global Root G2 is retired unexpectedly. Although root CA migrations are rare, for resilience in the modern security landscape you should prepare your IoT scenario for the unlikely event that a root CA is compromised or an emergency root CA migration is necessary.
 
@@ -104,9 +104,23 @@ We strongly recommend that all devices trust the following root CAs:
 
 For links to download these certificates, see [Azure Certificate Authority details](../security/fundamentals/azure-CA-details.md).
 
+### Certificate trust in the SDKs
+
+The [Azure IoT device SDKs](../iot-hub/iot-hub-devguide-sdks.md) connect and authenticate devices to Azure IoT services. The different SDKs manage certificates in different ways depending on the language and version, but most rely on the device's trusted certificate store rather than pinning certificates directly in the codebase. This approach provides flexibility and resilience to handle future changes in root certificates. 
+
+The following table summarizes which SDK versions support the trusted certificate store:
+
+| Azure IoT device SDK | Supported versions |
+| -------------------- | ------------------ |
+| C | All currently supported versions |
+| C# | All currently supported versions |
+| Java | Version 2.x.x and higher |
+| Node.js | All currently supported versions |
+| Python | All currently supported versions |
+
 ### Certificate pinning
 
-[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (aka leaf certificates) and intermediate certificates associated with DPS 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](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
+[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (also known as leaf certificates) and intermediate certificates associated with DPS endpoints is 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](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
 
 ## Use TLS 1.2 in the IoT SDKs
 

articles/iot-hub/create-connect-device.md

@@ -31,7 +31,10 @@ Devices use two different types of certificates to connect to IoT Hub. When prep
 
 ### Required public root certificates
 
-Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. The device SDKs include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to the IoT hub.
+Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. Each device needs a copy of the root certificate that IoT Hub and DPS use. We recommend that all devices include the following root CAs in their trusted certificate store:
+
+* DigiCert Global G2 root CA
+* Microsoft RSA root CA 2017
 
 For more information about IoT Hub's recommended certificate practices, see [TLS support](./iot-hub-tls-support.md).
 

articles/iot-hub/iot-hub-tls-support.md

@@ -5,7 +5,7 @@
  author: kgremban
  ms.service: azure-iot-hub
  ms.topic: conceptual
- ms.date: 01/05/2024
+ ms.date: 11/27/2024
  ms.author: kgremban
 ---
 
@@ -17,7 +17,7 @@ TLS 1.0 and 1.1 are considered legacy and are planned for deprecation. For more
 
 ## 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. The [device SDKs](./iot-hub-devguide-sdks.md) include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to the IoT hub.
+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 also recommend adding the Microsoft RSA Root Certificate Authority 2017 certificates to your devices to prevent disruptions in case the DigiCert Global Root G2 is retired unexpectedly. Although root CA migrations are rare, for resilience in the modern security landscape you should prepare your IoT scenario for the unlikely event that a root CA is compromised or an emergency root CA migration is necessary.
 
@@ -28,9 +28,23 @@ We strongly recommend that all devices trust the following root CAs:
 
 For links to download these certificates, see [Azure Certificate Authority details](../security/fundamentals/azure-CA-details.md).
 
+### Certificate trust in the SDKs
+
+The [Azure IoT device SDKs](../iot-hub/iot-hub-devguide-sdks.md) connect and authenticate devices to Azure IoT services. The different SDKs manage certificates in different ways depending on the language and version, but most rely on the device's trusted certificate store rather than pinning certificates directly in the codebase. This approach provides flexibility and resilience to handle future changes in root certificates. 
+
+The following table summarizes which SDK versions support the trusted certificate store:
+
+| Azure IoT device SDK | Supported versions |
+| -------------------- | ------------------ |
+| C | All currently supported versions |
+| C# | All currently supported versions |
+| Java | Version 2.x.x and higher |
+| Node.js | All currently supported versions |
+| Python | All currently supported versions |
+
 ### Certificate pinning
 
-[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (aka leaf 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](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
+[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (also known as leaf certificates) and intermediate certificates associated with IoT Hub endpoints is 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](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
 
 ### Elliptic Curve Cryptography (ECC) server TLS certificate (preview)
 
@@ -95,7 +109,7 @@ To use ARM template for creation, provision a new IoT Hub in any of the supporte
 }
 ```
 
-The created IoT Hub resource using this configuration will refuse device and service clients that attempt to connect using TLS versions 1.0 and 1.1. Similarly, the TLS handshake will be refused if the `ClientHello` message does not list any of the [recommended ciphers](#cipher-suites).
+The created IoT Hub resource using this configuration refuses device and service clients that attempt to connect 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](#cipher-suites).
 
 > [!NOTE]
 > The `minTlsVersion` property is read-only and cannot be changed once your IoT Hub resource is created. It is therefore essential that you properly test and validate that *all* your IoT devices and services are compatible with TLS 1.2 and the [recommended ciphers](#cipher-suites) in advance.
@@ -104,7 +118,7 @@ The created IoT Hub resource using this configuration will refuse device and ser
 
 ## Cipher suites
 
-IoT Hubs that are configured to accept only TLS 1.2 will also enforce the use of the following recommended cipher suites:
+IoT Hubs that are configured to accept only TLS 1.2 also enforce the use of the following recommended cipher suites:
 
 * `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 * `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
@@ -126,11 +140,11 @@ For IoT Hubs not configured for TLS 1.2 enforcement, TLS 1.2 still works with th
 * `TLS_RSA_WITH_AES_128_CBC_SHA`
 * `TLS_RSA_WITH_3DES_EDE_CBC_SHA` **(This cipher will be deprecated on 10/01/2022 and will no longer be used for TLS handshakes)**
 
-A client can suggest a list of higher cipher suites to use during `ClientHello`. However, some of them might not be supported by IoT Hub (for example, `ECDHE-ECDSA-AES256-GCM-SHA384`). In this case, IoT Hub will try to follow the preference of the client, but eventually negotiate down the cipher suite with `ServerHello`.
+A client can suggest a list of higher cipher suites to use during `ClientHello`. However, some of them might not be supported by IoT Hub (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 links below to configure TLS 1.2 and allowed ciphers in IoT Hub client SDKs.
+Use the following links to configure TLS 1.2 and allowed ciphers in IoT Hub client SDKs.
 
 | Language | Versions supporting TLS 1.2 | Documentation |
 |----------|------------------------------------|---------------|