![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(147.20000000000002, 49%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDS%3C/text%3E%3C/svg%3E)
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(6.4, 51%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKV%3C/text%3E%3C/svg%3E)
Azure IoT Hub secures device connectivity with a combination of strong device identity, TLS for transport security, and per-device authentication using either SAS tokens or X.509 certificates. Authorization is then enforced based on the authenticated device identity.
How IoT Hub authenticates devices
- Identity registry
Every device or module must have an entry in the IoT Hub identity registry before it can connect. The registry stores the device ID and its credentials. Authentication uses those stored credentials to validate the device or module when it connects. IoT Hub supports two authentication methods for devices and modules:- SAS token–based authentication (symmetric keys)
- X.509 certificate–based authentication
- SAS token authentication (symmetric keys)
- Each device has symmetric keys stored in the identity registry.
- The device uses these keys to generate Shared Access Signature (SAS) tokens that are sent as part of the connection (for example, as the MQTT password).
- SAS tokens are time-limited and signed with the symmetric key, so the key itself is never sent over the network.
- IoT Hub validates the signature and expiry on each request that uses a SAS token.
- X.509 certificate authentication
X.509 authentication is more secure and scalable and is recommended for higher security requirements:- Devices authenticate during the TLS handshake using an X.509 certificate instead of a SAS token.
- IoT Hub supports two X.509 modes:
- X.509 CA-signed (recommended for production):
- A root or intermediate CA certificate is uploaded and verified in IoT Hub.
- Devices hold leaf certificates whose chain of trust leads to that CA.
- When a device connects, it presents its full certificate chain. IoT Hub validates the chain against the registered CA.
- Multiple devices can authenticate via the same verified CA, which scales well for large fleets.
- X.509 self-signed:
- For each device, a certificate thumbprint (hash) is stored in the identity registry.
- When the device connects, IoT Hub validates the presented certificate against the stored thumbprint.
- X.509 CA-signed (recommended for production):
CN=deviceId). For modules, the CN must beCN=deviceId/moduleId. Authenticate identities with third-party X.509 certificates - Enforcing X.509-only authentication
For extra security, IoT Hub can be configured to disable SAS authentication for devices and modules, leaving X.509 as the only accepted method:
Authenticate identities with third-party X.509 certificatesaz resource update -n <iothubName> -g <resourceGroupName> \ --resource-type Microsoft.Devices/IotHubs \ --set properties.disableDeviceSAS=true properties.disableModuleSAS=true - TLS and protocol-level security
- All supported device protocols (MQTT, AMQP, HTTPS) use TLS to secure data in transit.
- Devices connecting directly with MQTT (without SDKs) must use TLS on port 8883 and include the device ID and IoT Hub hostname in the MQTT CONNECT packet.
- When using X.509, the certificate is presented during the TLS handshake; SAS tokens are not required in that case.
Recommended mechanism for large-scale production
For large-scale, production-grade systems, the guidance is:
- Prefer X.509 certificate–based authentication, especially CA-signed X.509:
- Provides stronger security than symmetric keys.
- Scales better because a single verified CA can authenticate many devices.
- Avoids sharing symmetric keys across devices.
- Use SAS tokens mainly for:
- Evaluation, testing, or simpler scenarios where certificate management is not feasible and devices can securely store symmetric keys.
Security guidance for IoT solutions explicitly recommends X.509 for production environments and advises against shared symmetric keys across devices.
- “Use X.509 certificates to authenticate your devices to IoT Hub or IoT Central… Use X509-based authentication in production environments as it provides greater security than symmetric keys.”
- “Avoid shared symmetric keys… Each device needs unique credentials.”
Key rotation and certificate revocation
- Device credential rotation
- Device credentials (keys or certificates) should be renewable and rotated regularly to limit the impact of compromise.
- For X.509, IoT guidance includes rolling device certificates and managing certificate lifecycles.
- X.509 certificate lifecycle and revocation
- With CA-signed X.509, revocation is handled by:
- Removing or disabling the device identity in the IoT Hub identity registry, and/or
- Managing the CA and intermediate certificates (for example, revoking a CA or not trusting a compromised CA).
- IoT Hub requires proof of possession when registering a CA certificate: a cryptographic challenge is signed with the CA private key, ensuring only the CA owner can register it. This model underpins trust and enables revocation at the CA or device level.
- With CA-signed X.509, revocation is handled by:
- Revoking compromised devices
- Implement procedures to quickly revoke access for compromised devices, preventing them from connecting and impacting other devices.
- Device Provisioning Service (DPS) guidance includes how to revoke device access and roll certificates.
- Certificate management with Microsoft-managed PKI (preview)
- IoT Hub introduces certificate management using Microsoft-managed PKI to issue and manage X.509 certificates for devices.
- This feature handles certificate issuance and renewal for devices provisioned via DPS, simplifying rotation at scale.
Best practices for securing device credentials at the edge
- Use X.509 certificates for device authentication
- Use X.509 for device-to-cloud authentication in production.
- Store private keys securely and never embed them in firmware in plain text.
- Use hardware-backed key storage (HSM/TPM)
- Store credentials (keys and certificates) in hardware security modules (HSMs) or Trusted Platform Modules (TPMs) to protect against extraction and tampering.
- TPM attestation can be used with DPS for secure provisioning.
Secure your Azure IoT Hub deployment - Avoid shared symmetric keys and enforce least privilege
- Never share symmetric keys across devices. Each device must have unique credentials.
- Use least-privilege access for any cloud-side identities (for example, using Microsoft Entra ID and RBAC for management operations).
Secure your Azure IoT Hub deployment - Rotate keys and certificates regularly
- Regularly rotate device keys and certificates, especially after a breach or on expiration.
- Ensure devices can update TLS root certificates and device certificates to avoid connectivity loss when certificates expire or are revoked.
Secure your Azure IoT Hub deployment - Use secure device provisioning and updates
- Use Device Provisioning Service (DPS) for secure, zero-touch provisioning with appropriate authentication (X.509, TPM).
- Use Device Update for IoT Hub or similar mechanisms to securely deliver firmware and credential updates.
- Network and connection security
- Use TLS 1.2, strong cipher suites, and keep root CAs current.
- Consider Azure Private Link, IP filtering, and disabling public network access where possible to reduce exposure.
Summary
- IoT Hub authenticates devices using credentials in the identity registry via SAS tokens or X.509 certificates, over TLS-secured connections.
- For large-scale production, X.509 CA-signed authentication is recommended due to stronger security and better scalability.
- Key rotation and certificate revocation are handled through renewable credentials, CA-based trust, DPS-based certificate rolling, and device revocation procedures.
- Best practices include using X.509, hardware-backed key storage (HSM/TPM), unique per-device credentials, regular rotation, secure provisioning and updates, and strong network security controls.
References: