Azure IoT Hub + Azure Device Registry (Preview Refresh): Device Trust and Management at Fleet Scale
What’s New in this Preview In November 2025, we announced the preview integration of Azure IoT Hub with Azure Device Registry, marking a huge step towards integrating IoT devices into the broader Azure ecosystem. We’re grateful to the customers and partners who participated in the preview and shared valuable feedback along the way. Today, we’re expanding the preview with new capabilities to strengthen security, improve fleet management, and simplify development for connected devices. With this refresh, preview customers can: Automate device certificate renewals with zero-touch, at-runtime operations to minimize downtime and maintain a strong security posture. Integrate existing security infrastructure like private certificate authorities with your Azure Device Registry namespace. Leverage certificate revocation controls to isolate device or fleet-level risks and maintain operational continuity Utilize an improved Azure Portal experience for streamlined configuration and lifecycle management of your devices. Accelerate solution development with expanded IoT Hub and DPS Device SDK compatibility for smoother integration and faster time to value. Together, these enhancements help organizations to secure, govern, and manage their IoT deployments using familiar Azure-native tools and workflows. Why this matters: From Connected Devices to Connected Operations Operational excellence begins by bridging the gap between physical assets and digital intelligence. Consider a global logistics fleet where every vehicle is more than just a machine; it is a trusted, connected, and manageable digital entity in the cloud. As these assets move, they emit a continuous stream of telemetry - from engine vibrations to fuel consumption – directly to a unified data ecosystem, where AI agents can reason over it with greater context. Instead of waiting for a breakdown, these agents detect wear patterns, cross-reference with digital twins, and provide recommendations to reroute a vehicle for service before a failure occurs. This completes a shift from reactive troubleshooting to proactive physical operations. Yet, for many organizations, this transformation is often stalled by fragmented systems where security policies, device registries, and data streams exist in silos. Overcoming this requires a sophisticated stack designed to establish trust, manage device lifecycles, and orchestrate data flows at a global scale: The Digital Operations stack for cloud-connected devices This journey starts with having a secure foundation for fleet management. In an era where perimeter security is no longer enough, organizations need an identity foundation that is both hardware-rooted and deeply integrated with device provisioning. Utilizing robust X.509 certificate management, where keys and credentials are anchored in tamper-resistant hardware, provides high-assurance system integrity across millions of endpoints. Once trust is established, Azure Device Registry creates a unified management plane, where devices are represented as first-class Azure resources, enabling ARM-based fleet management, role-based access control for lifecycle operations, and Azure Policy for enforcement. Simultaneously, IoT Hub provides secure, bidirectional messaging for at-scale fleets. This high-fidelity data provides the essential fuel for Physical AI. By streaming trusted telemetry into Microsoft Fabric, organizations can break down data silos and allow AI agents to reason over real-world events in a centralized analytics environment. The Azure IoT stack provides the essential bridge for cloud-connected devices, enabling customers to transform their industrial environments into highly secure and intelligent ecosystems. For more information on Azure's approach to industrial AI, check out: Making Physical AI Practical for Real-World Industrial Operations. Azure IoT Hub + ADR (Preview): Expanding Fleet and Certificate Lifecycle Management The April 2026 Preview for Azure IoT Hub and Azure Device Registry (ADR) deliver key features to further standardize device identity and enable policy‑driven management for certificates at scale. You can think of device identity in Azure Device Registry like the birth record of a person. When someone is born, certain information becomes permanently associated with them - such as their date and place of birth. In the same way, a device’s identity represents its immutable existence within your solution - things like its serial number, model, or ownership context. However, as that person moves through life, they obtain different credentials that allow them to prove who they are in different situations - such as a driver’s license or passport. These credentials may expire, be renewed, or even replaced entirely over time without changing the person’s underlying identity. In IoT, devices use X.509 certificates as their credential to prove identity to services like IoT Hub. In your Azure Device Registry namespace, you can define the public key infrastructure (PKI) that manage your X.509 certificates and certificate authorities (CAs). In this preview, we are making it easier to integrate with existing security infrastructure and manage certificates at fleet scale. Certificate Management for Cloud-connected Devices in Azure Bring Your Own Certificate Authority (BYO CA) in Azure Device Registry Organizations that already operate sophisticated certificate authorities, with well‑established compliance controls, audit processes, and key custody requirements, want to integrate their trusted CA with the Azure Device Registry operating model. With BYO CA, customers can use their own private certificate authority while still benefiting from Azure’s fully managed device provisioning, and lifecycle management. Azure handles the heavy lifting of issuing, rotating, and revoking issuing certificate authorities (ICAs) and device certificates - while you stay in control of the top-most CA. Full Ownership of Trust and Keys: By bringing their own CA, organizations maintain absolute control over their private keys and security boundaries. Azure never takes custody of the external CA, ensuring existing governance, auditability, and compliance controls remain fully intact. Automated Lifecycle Management: While the CA remains customer-owned, Azure Device Registry automates the issuance, rotation, and revocation of device certificates. This eliminates the need for custom tooling or manual, per-device workflows that typically slow down deployments. Bring your own Certificate Authority in Azure Device Registry Fleet‑Wide Protection with Certificate Revocations Revocation is a mechanism for selective isolation, used to contain a single or group of devices by decommissioning a single device's certificates or the entire anchor of trust. When a single device is compromised, lost, or retired, device certificate revocation enables a precise, targeted response. This allows organizations to isolate individual devices instantly, reduce blast radius, and maintain uninterrupted operations for healthy devices - without rebuilding device identities. ADR propagates the revocation state to IoT Hub, blocking revoked devices until they’re re-provisioned. When a subset of devices requires isolation, policy revocation allows operators to decommission an entire trust anchor rather than managing individual devices. By mapping a specific Issuing CA to a single ADR policy, organizations gain a high-precision containment mechanism. In a single action, an operator can invalidate a compromised CA and then plan for a staged credential rollover across the entire segment. ADR automatically enforces this updated trust chain within IoT Hub, ensuring that only devices with newly issued certificates can connect. This makes large‑scale certificate rotation predictable, controlled, and operationally simple. Revoking the certificate for a single ADR Device on Azure Portal Flexible Options to renew Device Certificates Managing X.509 certificates at scale doesn’t stop once a device is onboarded. Operational certificates are short-lived by design, ensuring devices do not rely on long-lived credentials for authentication. In real-world IoT fleets, devices are often intermittently connected, deployed in hard-to-reach locations, and expected to run continuously - making certificate renewal one of the most operationally challenging parts of device security. Azure IoT Hub now enables device certificate renewal directly through IoT Hub, complementing the role of Device Provisioning Service (DPS). While DPS remains the solution for first-time device onboarding and certificate issuance, IoT Hub renewal is designed for the steady state - keeping already-connected devices securely authenticated over time without introducing downtime. IoT Hub certificate renewal follows similar patterns as other device-initiated operations such as twin updates and direct methods. With this capability, devices can request a new certificate as part of normal operation, using the same secure MQTT connection they already rely on. Support for IoT Hub and Device Provisioning Service (DPS) Device SDKs Managing credential issuance and renewals at scale is only possible if devices can handle their own credential lifecycles. We’ve added Certificate Signing Request (CSR) support to our C, C# (.NET), Java, Python, and Embedded device SDKs for IoT Hub and Device Provisioning Service (DPS). Beyond developer convenience, this provides multiple device-initiated paths for certificate renewal and trust-chain agility. Devices can generate CSRs and request newly signed X.509 certificates through IoT Hub or DPS as part of normal operation. This allows security teams to rotate and update certificates in the field without touching the hardware, keeping fleets secure as certificate authorities and policies evolve over time. Customer Feedback from Preview We’re grateful to the customers and partners who participated in the preview and shared valuable feedback along the way. Hear some of what our customers had to say: "The availability of a built-in certificate manager is a great upgrade in keeping the IoT space more secure."— Martijn Handels, CTO, Helin Data “Secure data is the starting line for industrial AI. With Azure certificate management, at CogitX we can ingest manufacturing signals safely and confidently - then use domain‑aware models to deliver real‑time insights and agentic workflows that improve throughput, quality, and responsiveness.” – Pradeep Parappil, CEO, CogitX Get Started Explore the new capabilities in preview today and start building the next generation of connected operations with Azure IoT Hub and Azure Device Registry: Get Started with Certificate Management in Preview.Automatic IoT Edge Certificate Management with GlobalSign EST
(Republish from Feb 15, 2023) When it comes to managing IoT devices, security is of the utmost importance. But you’d also rest easier if devices are secure without concern about manual certificate management. In this post, we'll show you a solution that streamlines IoT Edge certificate management using GlobalSign's IoT Edge Enroll EST service. An Analogy Think of each IoT Edge device as a new driver, ready to hit the road and communicate with the IoT Hub. And like a new driver, each device needs its own set of credentials that need renewal. Here's how GlobalSign's EST service makes it a breeze: Birth Certificate: During manufacturing, each device is given a unique Initial Device Identifier (IDevID) certificate and private key (ideally, something like Trusted Computing Group’s (TCG) Trusted Platform Module’s (TPM) Endorsement Key (EK) certificates with factory burnt secured hardware backed private keys). This is like the device's birth certificate, proving its identity. Driver's License: When the device connects for the first time, it uses its IDevID to authenticate with GlobalSign for certificate signing request (CSR). In return, GlobalSign provides a short-lived Locally Significant Device Identifier (LDevID) certificate from a trusted root CA. This LDevID acts as the device's driver's license, allowing it to operate for some time. The LDevID serves as the device's unique identifier in IoT Hub, registered through Device Provisioning Service (DPS). Automatic Renewal: To make sure your devices never lose their communication privileges, IoT Edge automatically renews the LDevID certificates before expiration. Like a driver license renewal, but automated! By using GlobalSign's EST service, you can enjoy secure certificate management for your IoT Edge devices. It's like having a personal assistant renewing your driver's license for you. Give it a try to start streamlining your IoT Edge certificate management. Prerequisites An IoT hub and Device Provisioning Service linked to it. A GlobalSign demo account: Sign up for Test Your Azure IoT Edge PoC with live device certificates from GlobalSign's IoT Edge Enroll. You'll receive an email with details for your EST server endpoint within a few days, including three endpoints (IDevID, LDevID, and Edge CA). Reply to the GlobalSign contact and ask to: Enable X.509 authentication (mTLS) for both the LDevID and the Edge CA endpoints Turn off “re-enrollment forcing” (the default behavior with GlobalSign IoT Edge Enroll is that it notices that a previously issued certificate was presented and "upgrade" the request to the reenrollment workflow. This overrides the subject CN to be the same as the previously issued certificate. Typically, customers would use a separate CA for the bootstrap/idevid, so in practice this outcome usually wouldn't be seen. But for simplicity of this post, it’s easier to ask GlobalSign to respect the certificate signing request (CSR) and not perform the “upgrade”). Linux machine, VM, or device with IoT Edge installed: Don't provision the IoT Edge device identity. Create the IDevID In this section, we create the IDevID certificate, which serves as the device's birth certificate. It’s a one-time process that occurs during device manufacturing, and ensures that the initial secret value for first-time authentication to GlobalSign never leaves the factory. Later, when the device wakes up, it will use the IDevID certificate to get a driver's license, or the LDevID certificate. On your local machine or SSH into the IoT Edge device, create directories to store certificates and private keys for IoT Edge and assign ownership of these directories to the "aziotcs" certificate service and "aziotks" key service. sudo mkdir -p /var/aziot/secrets sudo mkdir /var/aziot/certs -p Retrieve the GlobalSign demo root CA certificate with curl and convert it to PEM format using openssl. This certificate serves as the common root of trust between IoT Edge, GlobalSign, and DPS (and thus IoT Hub). curl https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/cacerts| openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out globalsign-root.cert.pem Use openssl to create a new private key and certificate signing request (CSR). openssl req -nodes -new -subj /CN=IDevID -sha256 -keyout IDevID.key.pem -out IDevID.csr Send the CSR to GlobalSign's simple enroll EST endpoint using curl, to obtain the IDevID certificate that is signed with the root CA and paired with the private key created earlier. curl -X POST --data-binary "@IDevID.csr" -H "Content-Transfer-Encoding:base64" -H "Secret-Value: <YOUR-SECRET-VALUE>" -H "Content-Type:application/pkcs10" https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/simpleenroll | openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out IDevID.cert.pem Move the certificates and private keys to the directories you created earlier, and give the IoT Edge certificate and key services the appropriate permissions to the PEM files and directories. sudo cp *cert.pem /var/aziot/certs sudo cp *key.pem /var/aziot/secrets sudo chown aziotcs:aziotcs /var/aziot/certs/*.cert.pem sudo chmod 644 /var/aziot/certs/*.cert.pem sudo chown aziotks:aziotks /var/aziot/secrets/*.key.pem sudo chmod 600 /var/aziot/secrets/*.key.pem sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets Use the ls command to verify that the files are in place with the proper permissions and match the expected values. $ sudo ls -lR /var/aziot /var/aziot: total 8 drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 11 14:38 certs drwx------ 2 aziotks aziotks 4096 Jan 11 14:38 secrets /var/aziot/certs: total 8 -rw-r--r-- 1 aziotcs aziotcs 1298 Jan 11 14:38 IDevID.cert.pem -rw-r--r-- 1 aziotcs aziotcs 1383 Jan 11 14:38 globalsign-root.cert.pem /var/aziot/secrets: total 4 -rw------- 1 aziotks aziotks 1704 Jan 11 14:38 IDevID.key.pem Prepare DPS for provisioning Here's how to get DPS ready for device provisioning: If you haven’t already done so, create an IoT hub and DPS, then link them together. Go to the DPS instance in Azure portal, then select Certificates > Add. In the pop-up, select your GlobalSign EST root CA certificate. You can use SFTP, VS Code Remote Extension to copy it from the IoT Edge device, or use curl to get it again. Select Set certificate status to verified on upload so that you can skip proof-of-possession. Click Save. Create a DPS enrollment group. Make sure attestation type is set to Certificate, IoT Edge device is set to True, certificate type is set to CA Certificate, and the root CA you just uploaded is set as the Primary Certificate. Now, your DPS is ready to provision the IoT Edge device when it wakes up, using the root CA certificate as the trusted source of authentication. Configure and start the IoT Edge device In this section, we set up the IoT Edge device with its birth certificate (IDevID) to communicate with the GlobalSign EST server and receive its driver license (LDevID). The LDevID allows the device to talk to DPS and get the proper authorization for communication with IoT Hub. On the IoT Edge device, create a config file config.toml. Replace marked parameters with details from your GlobalSign account and DPS. # The CA cert of the demo root we got from earlier [cert_issuance.est] trusted_certs = ["file:///var/aziot/certs/globalsign-root.cert.pem"] # Empty because the LDevID (device ID) and Edge CA endpoints are different [cert_issuance.est.urls] # Use the IDevID cert and private key for authentication to EST [cert_issuance.est.auth] identity_cert = "file:///var/aziot/certs/IDevID.cert.pem" identity_pk = "file:///var/aziot/secrets/IDevID.key.pem" # DPS provisioning with X.509 certificate # Replace with ID Scope from your DPS [provisioning] source = "dps" global_endpoint = "https://global.azure-devices-provisioning.net" id_scope = "<DPS-ID-SCOPE e.g 0AB12345678>" [provisioning.attestation] method = "x509" registration_id = "my-device-id" # Get LDevID (device ID) cert from EST with auto renew [provisioning.attestation.identity_cert] method = "est" common_name = "my-device-id" url = "https://<YOUR-LDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [provisioning.attestation.identity_cert.auto_renew] threshold = "80%" retry = "4%" # Get Edge CA from EST also with auto renew [edge_ca] method = "est" url = "https://<YOUR-EDGE-CA-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [edge_ca.auto_renew] threshold = "80%" retry = "4%" Copy the file over as root and apply configuration with iotedge config apply. This also starts the IoT Edge device. sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply Verify that the configuration was successful by using the iotedge check command. You should see successful checks on the connection with DPS and the status of certificates and keys. You can also check in your DPS Enrollment Group > Registration Records or IoT Hub to see that the IoT Edge device is registered (shown below). Note: if you haven’t configured an IoT Edge deployment, you might see an error about edgeHub container being missing in iotedge check and a 417 in IoT Hub. That’s normal until you add the deployment via Set modules. On the device, check the new certificates from the EST server. In the "/var/lib/aziot/certd/certs" directory, you should see three different certificates starting with "estid", "aziotedgeca", and "deviceid". Use OpenSSL to inspect them. Note: the certificate names are randomly generated, use "ls" to find their names and paste them into the OpenSSL command. sudo ls /var/lib/aziot/certd/certs sudo openssl x509 -text -in /var/lib/aziot/certd/certs/estid-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/aziotedgedca-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/deviceid-<GUID>.cer sudo openssl x509 -in /var/aziot/certs/IDevID.cert.pem -text | head -n 10 That’s it! When the time (80% to expiration) comes, IoT Edge will automatically renew both the device ID and the Edge CA certificates without manual intervention. Simplify IoT Edge Security This blog showed how to configure IoT Edge devices for secure communication using X.509 certificates without the need for manual certificate management. By using this approach, organizations can securely and efficiently manage their IoT Edge devices at scale, streamlining device enrollment and reducing the risk of security breaches. To adapt the example to fit your needs, consider the following: Security level: Your security requirements may vary based on your use case. Consider whether a unique IDevID certificate per device is necessary or if sharing the same certificate among multiple devices is acceptable. It's important to never store the initial EST secret value on the device in plaintext. Comprehensive security: For a more robust security approach, refer to The blueprint to securely solve the elusive zero-touch provisioning of IoT devices at scale | Azure. Dev/test scenarios: IoT Edge also supports basic authentication (username/password) for EST servers. To Restart If you need to restart midway through, stop the IoT Edge service first, delete any certificates and keys that were generated, reapply the config, and restart IoT Edge. sudo iotedge system stop sudo sh -c "rm /var/lib/aziot/certd/certs/*" sudo sh -c "rm /var/lib/aziot/keyd/keys/*" sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply sudo iotedge system logs -- -f
