Share via

How does Azure IoT Hub handle devices and what authentication does it use?

Dhruvesh Sheladiya 0 Reputation points Microsoft Employee
2026-05-14T18:20:50.4566667+00:00

Question

How does Azure IoT Hub handle devices and what authentication does it use?

Description

I am trying to understand how Azure IoT Hub manages device connectivity and authentication in an IoT solution, specifically how devices are registered, identified, and securely connected to the IoT Hub.

Environment Details

Azure Service: Azure IoT Hub

Device Type: Multiple IoT devices (simulated/physical)

Communication Protocols: MQTT / AMQP / HTTPS

Identity Management: IoT Hub device registry

Authentication Scope: Device-to-cloud connectivity

Investigation Details / Observations

IoT Hub appears to maintain a central identity registry for all connected devices. [learn.microsoft.com]

Each device must be registered before it can connect. [learn.microsoft.com]

Devices seem to have per-device identities and credentials. [learn.microsoft.com]

Authentication is enforced on every request/message sent to IoT Hub. [learn.microsoft.com]

Device twins seem to exist for each device and track state/configuration. [learn.microsoft.com]

What I’ve Explored

Reviewed IoT Hub identity registry concepts

Checked how device provisioning works via DPS

Looked into device twin structure and usage

Explored authentication mechanisms in IoT Hub

Observed that multiple authentication methods exist

Authentication Methods Observed

Shared Access Signature (SAS) tokens

Uses symmetric keys stored per device

  Tokens are generated and sent with each request [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/authenticate-authorize-sas)
  
  **X.509 Certificates**
  
     Certificate-based authentication via PKI
     
        Device proves identity using private key [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-certificate-management-concepts)
        
        **TPM-based authentication**
        
           Uses hardware-based identity (TPM chip) [[github.com]](https://github.com/Azure/azure-iot-sdk-csharp/blob/main/device_connection_and_reliability_readme.md)

Steps Followed / Understanding Built

Registered devices in IoT Hub identity registry

Verified device identity creation and properties

Observed device twin auto-creation per device

Tested connections using different auth types

Analyzed how credentials are validated during connection

Challenges / Confusions

Difference between SAS vs X.509 authentication usage scenarios

How IoT Hub validates device identity internally on connection

When to choose symmetric keys vs certificates

How device provisioning (DPS) ties into authentication flow

How authentication impacts device scalability and security

Ask / Clarification Needed

How exactly does IoT Hub validate device identity at runtime?

What is the recommended authentication method for production scale?

  • How does IoT Hub manage millions of device identities securely?

What are best practices for choosing between SAS and X.509?

Question

How does Azure IoT Hub handle devices and what authentication does it use?

Description

I am trying to understand how Azure IoT Hub manages device connectivity and authentication in an IoT solution, specifically how devices are registered, identified, and securely connected to the IoT Hub.

Environment Details

Azure Service: Azure IoT Hub

  Device Type: Multiple IoT devices (simulated/physical)
  
     Communication Protocols: MQTT / AMQP / HTTPS
     
        Identity Management: IoT Hub device registry
        
           Authentication Scope: Device-to-cloud connectivity
           
           ### **Investigation Details / Observations**

              IoT Hub appears to maintain a **central identity registry** for all connected devices. [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry)
              
                 Each device must be registered before it can connect. [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry)
                 
                    Devices seem to have **per-device identities and credentials**. [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-identity-registry)
                    
                       Authentication is enforced on every request/message sent to IoT Hub. [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/authenticate-authorize-sas)
                       
                          Device twins seem to exist for each device and track state/configuration. [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins)
                          
                          ### **What I’ve Explored**

                             Reviewed IoT Hub identity registry concepts
                             
                                Checked how device provisioning works via DPS
                                
                                   Looked into device twin structure and usage
                                   
                                      Explored authentication mechanisms in IoT Hub
                                      
                                         Observed that multiple authentication methods exist
                                         
                                         ### **Authentication Methods Observed**

                                            **Shared Access Signature (SAS) tokens**
                                            
                                                  Uses symmetric keys stored per device
                                                  
                                                        Tokens are generated and sent with each request [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/authenticate-authorize-sas)
                                                        
                                                           **X.509 Certificates**
                                                           
                                                                 Certificate-based authentication via PKI
                                                                 
                                                                       Device proves identity using private key [[learn.microsoft.com]](https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-certificate-management-concepts)
                                                                       
                                                                          **TPM-based authentication**
                                                                          
                                                                                Uses hardware-based identity (TPM chip) [[github.com]](https://github.com/Azure/azure-iot-sdk-csharp/blob/main/device_connection_and_reliability_readme.md)
                                                                                
                                                                                ### **Steps Followed / Understanding Built**

                                                                                   Registered devices in IoT Hub identity registry
                                                                                   
                                                                                      Verified device identity creation and properties
                                                                                      
                                                                                         Observed device twin auto-creation per device
                                                                                         
                                                                                            Tested connections using different auth types
                                                                                            
                                                                                               Analyzed how credentials are validated during connection
                                                                                               
                                                                                               ### **Challenges / Confusions**

                                                                                                  Difference between SAS vs X.509 authentication usage scenarios
                                                                                                  
                                                                                                     How IoT Hub validates device identity internally on connection
                                                                                                     
                                                                                                        When to choose symmetric keys vs certificates
                                                                                                        
                                                                                                           How device provisioning (DPS) ties into authentication flow
                                                                                                           
                                                                                                              How authentication impacts device scalability and security
                                                                                                              
                                                                                                              ### **Ask / Clarification Needed**

                                                                                                                 How exactly does IoT Hub validate device identity at runtime?
                                                                                                                 
                                                                                                                    What is the recommended authentication method for production scale?
                                                                                                                    
                                                                                                                       How does IoT Hub manage millions of device identities securely?
                                                                                                                       
                                                                                                                          What are best practices for choosing between SAS and X.509?
Azure IoT Hub
Azure IoT Hub

An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Karnam Venkata Rajeswari 3,150 Reputation points Microsoft External Staff Moderator
    2026-05-14T18:42:07.18+00:00

    Hello @Dhruvesh Sheladiya ,

    Welcome to Microsoft Q&A .Thank you for reaching out to us.

    Azure IoT Hub provides a secure, scalable device connectivity model based on per-device identity, strong authentication, and centralized provisioning. It supports MQTT, AMQP, and HTTPS protocols while ensuring every device is authenticated and authorized before communication is allowed.

    1. Device identity management and runtime validation All devices are managed through a central identity registry, where each device must be registered before it can connect. Each device identity includes:
      • Unique device ID
      • Authentication configuration (SAS, X.509, or TPM via provisioning)
      • Status (enabled/disabled)
      • Access permissions and metadata
      Device twins are automatically created for each device identity and are used for configuration and state synchronization, not authentication. Please refer the following - Understand the Azure IoT Hub identity registry | Microsoft Learn Runtime connection and flow When a device connects:
      1. A TLS-secured connection is established with the IoT Hub endpoint
      2. Device identity is validated against the identity registry
      3. Authentication is performed based on configured credentials
      4. Authorization rules are evaluated before access is granted
      Only after successful validation are telemetry and command operations allowed. Please refer to the following - Azure IoT Hub TLS support | Microsoft Learn
    2. Authentication mechanisms - IoT Hub supports multiple authentication methods depending on device capability and security requirements. SAS token-based authentication (symmetric keys)
      • Each device is assigned a unique symmetric key in the identity registry
      • A Shared Access Signature (SAS) token is generated using this key
      • IoT Hub validates the token by:
      • Verifying the signature using the stored key
      • Checking expiry and scope
      • The symmetric key is never transmitted over the network
      Key characteristics:
      • Lightweight and easy to implement
      • Suitable for constrained devices and development scenarios
      • Requires secure key storage on device
        • Each device is assigned a unique symmetric key in the identity registry
      • A Shared Access Signature (SAS) token is generated using this key
      • IoT Hub validates the token by:
        • Verifying the signature using the stored key
        • Checking expiry and scope
      • The symmetric key is never transmitted over the network
      Key characteristics: X.509 certificate-based authentication
      • Device identity is validated during the TLS handshake using certificates
      • IoT Hub validates:
      • Certificate chain of trust (CA-based scenarios), or
      • Thumbprint mapping to a registered device identity
      • Certificate must be associated with a device in the identity registry
      Key characteristics: TPM-based authentication (via Device Provisioning Service)
      1. Uses hardware-backed secure key storage
      2. Private keys remain within secure hardware boundaries
      3. Typically used during provisioning to establish device identity securely
    3. Device provisioning at scale Azure IoT Hub Device Provisioning Service enables automated and secure onboarding of large device fleets. Key capabilities:
      • Zero-touch provisioning at device first boot
      • Automatic assignment of devices to IoT Hub instances
      • Support for SAS, X.509, and TPM attestation
      • Secure identity creation and configuration at scale
      After provisioning, devices authenticate directly with IoT Hub using assigned credentials. Please refer the following - https://learn.microsoft.com/en-us/azure/iot-dps/
    4. Scaling to millions of devices IoT Hub is designed for large-scale IoT workloads through:
      • Distributed identity management for devices
      • Independent authentication validation per connection request
      • Horizontally scalable MQTT, AMQP, and HTTPS endpoints
      • Partitioned backend processing for telemetry ingestion
      • Integration with Device Provisioning Service for automated onboarding
      This design ensures secure isolation and independent authentication for each device. Please refer the following - https://learn.microsoft.com/azure/iot-hub/iot-hub-devguide-scale SAS vs X.509 – selection guidance

    SAS authentication

    Best suited for:

    • Development and testing
    • Constrained or legacy devices

    Considerations:

    • Simpler to implement
    • Requires careful key protection and rotation

    X.509 authentication

    Best suited for:

    • Enterprise-scale deployments
    • Security-sensitive environments
    • Long-term device lifecycle management

    Advantages:

    • No shared secrets
    • Strong cryptographic identity assurance
    • Supports scalable certificate lifecycle operations

    Please consider the following troubleshooting steps-

    1. For authentication failures (401 / 403)
      1. Verify device exists and is enabled in the identity registry
      2. Validate SAS token expiry and device clock synchronization
      3. Confirm certificate chain, thumbprint, or CA configuration
      4. Ensure correct device-to-identity mapping
    2. For Connectivity issues
      1. Ensure TLS 1.2 or later is enabled on device runtime
      2. Validate protocol compatibility (MQTT/AMQP/HTTPS)
      3. Check firewall or network restrictions for IoT endpoints
    3. For orovisioning issues
      1. Validate Device Provisioning Service scope ID and enrollment configuration
      2. Confirm correct attestation type (SAS/X.509/TPM)
      3. Review provisioning logs for assignment or registration failures

    The best practices are to :

    1. Use unique identities per device
    2. Prefer X.509 certificates for production workloads
    3. Use Device Provisioning Service for large-scale automated onboarding
    4. Protect credentials using secure hardware (TPM/HSM where available)
    5. Minimize reliance on shared access policies for service operations
    6. Use Microsoft Entra ID for service-side authentication and RBAC

    Please let us know if the response was helpful

    Thank you

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-05-14T18:21:30.3866667+00:00

    Azure IoT Hub handles devices through a central identity registry and authenticates each device on every connection and operation using either SAS tokens or X.509 certificates.

    How IoT Hub handles devices

    1. Identity registry
      • Every IoT hub has an identity registry that stores information about all devices and modules permitted to connect.
      • Before a device or module can connect, an entry for that device or module must exist in the identity registry.
      • Device identities in this registry are used for device authentication and access control.
    2. Per-device credentials and permissions
      • When a device is registered to use SAS token authentication, IoT Hub creates two symmetric keys for that device.
      • These symmetric keys grant the DeviceConnect permission for that specific device identity.
      • Each device has its own credentials; shared symmetric keys across devices are discouraged.
    3. Device endpoints and protocols
      • For each registered device, IoT Hub exposes device endpoints for:
        • Sending device-to-cloud messages
        • Receiving cloud-to-device messages
        • File uploads
        • Device twin operations
        • Direct methods
      • These endpoints are available over MQTT v3.1.1, AMQP 1.0, and HTTPS 1.1 (with some twin/method exceptions for HTTPS).
    4. Device twins
      • Each device has a device twin accessible via service-facing endpoints.
      • Device twins are separate from authentication but rely on the device identity to authorize access.

    Authentication methods used by IoT Hub

    IoT Hub supports two primary device authentication methods:

    1. SAS token–based authentication (symmetric keys)
      • Devices authenticate using Shared Access Signature (SAS) tokens.
      • SAS tokens are generated using the device’s symmetric key stored in the identity registry.
      • The token is sent with every call to IoT Hub, providing time-bounded access to specific IoT Hub resources.
      • The symmetric keys themselves are never sent over the wire; only the derived SAS token is.
      • SAS tokens provide both authentication (AuthN) and authorization (AuthZ) for each call.
    2. X.509 certificate–based authentication
      • Devices authenticate using X.509 certificates during the TLS handshake.
      • IoT Hub supports:
        • X.509 certificates validated by thumbprint, or
        • X.509 certificates issued by a registered CA certificate chain.
      • For CA-based auth, the device presents a certificate chain of trust; IoT Hub:
        1. Cryptographically validates the certificate chain.
        2. Issues a proof-of-possession challenge that the device must sign with its private key.
      • The device certificate’s Common Name (CN) must match the device ID (CN=deviceId), or CN=deviceId/moduleId for modules.

    How IoT Hub validates device identity at runtime

    1. TLS session establishment (mutual TLS)
      • For MQTT and AMQP, IoT Hub requests a client certificate during the initial TLS handshake.
      • If a client certificate is provided and the device is configured for X.509 auth, IoT Hub authenticates the client certificate and the client authenticates IoT Hub’s server certificate.
      • For HTTPS, IoT Hub checks whether the client requires X.509 authentication when the first request is made.
    2. Authentication step
      • After a successful TLS handshake, IoT Hub authenticates the device using either:
        • The SAS token (for symmetric key auth), or
        • The X.509 certificate (thumbprint or CA-based).
      • For X.509 CA-based auth, IoT Hub validates the certificate chain and proof-of-possession as described above.
    3. Authorization step
      • Once identity is authenticated, IoT Hub performs authorization based on:
        • Device-level permissions (for example, DeviceConnect via symmetric keys), or
        • Service-level shared access policies or Microsoft Entra ID for service APIs.
      • Only if both authentication and authorization succeed is the device allowed to use its endpoints.
    4. Ongoing validation
      • Every time a device connects, IoT Hub renegotiates the TLS session and re-verifies the device’s X.509 certificate (for certificate-based auth).
      • For SAS, each call must include a valid SAS token; expired or invalid tokens are rejected.

    Recommended authentication for production scale

    1. Preferred: X.509 certificates
      • For production environments, the recommended method is X.509 certificate–based authentication, especially using CA-signed device certificates.
      • Benefits:
        • Higher security and better credential management.
        • Scales well for large fleets via a certificate chain of trust.
        • Avoids sharing symmetric keys and supports secure manufacturing and supply-chain flows.
    2. When to use SAS (symmetric keys)
      • SAS tokens are simpler to implement and suitable for devices that can securely store a symmetric key.
      • They are often used for:
        • Prototyping and development.
        • Simpler or resource-constrained devices where PKI management is not feasible.
      • Best practice is to avoid shared symmetric keys across devices and assign unique credentials per device.

    How IoT Hub manages millions of device identities securely

    1. Per-device identity in the registry
      • Every device has its own identity and credentials in the IoT Hub identity registry.
      • Device identities are used for both authentication and access control to device endpoints.
    2. Scalable endpoints and protocols
      • IoT Hub exposes device endpoints over scalable protocols (MQTT, AMQP, HTTPS) and handles multi-tenant isolation.
    3. Security practices
      • Use X.509 certificates for device authentication in production.
      • Avoid shared symmetric keys across devices.
      • Use secure hardware (for example, HSMs) on devices to protect private keys.
    4. Admin and service access
      • For management and service APIs, use Microsoft Entra ID and Azure RBAC for granular, least-privilege access instead of broad shared access policies.
      • Disable shared access policies when not needed to reduce attack surface.

    Best practices for choosing between SAS and X.509

    1. Choose X.509 when:
      • Operating at production scale with many devices.
      • A PKI and certificate lifecycle management process is available.
      • Devices can securely store private keys (ideally in HSMs or secure elements).
      • Strong security and supply-chain trust are required.
    2. Choose SAS when:
      • Simplicity is critical and device hardware or environment cannot support certificate management.
      • Working with prototypes, test environments, or small deployments.
      • Devices can still securely store symmetric keys and unique keys per device are used.
    3. General security guidance:
      • Prefer X.509 certificates for production.
      • Ensure each device has unique credentials.
      • Protect private keys (for X.509) and symmetric keys (for SAS) using secure hardware where possible.
      • Use Microsoft Entra ID and Azure RBAC for service-side access control and disable unnecessary shared access policies.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.