We’re ringing in 2019 by announcing the general availability for the Azure IoT Hub Device Provisioning Service features we first released back in September 2018! The following features are all generally available to you today:
- Symmetric key attestation support
- Re-provisioning support
- Enrollment-level allocation rules
- Custom allocation logic
All features are available in all provisioning service regions, through the Azure portal, and the SDKs will support these new features by the end of January 2019 (with the exception of the Python SDK). Let’s talk a little more about each feature.
Symmetric key attestation
Symmetric keys are one of the easiest ways to start off using the provisioning service and provide an easy “Hello world” experience for those of you who want to get started with provisioning but haven’t yet decided on an authentication method. Furthermore, symmetric key enrollment groups provide a great way for legacy devices with limited existing security functionality to bootstrap to the cloud via Azure IoT. Check the docs to learn more about how to connect legacy devices.
Symmetric key support is available in two ways:
- Individual enrollments, in which devices connect to the Device Provisioning Service just like they do in IoT Hub.
- Enrollment groups, in which devices connect to the Device Provisioning Service using a symmetric key derived from a group key.
The documentation has more about how to use symmetric keys to verify a device’s identity.
Automated re-provisioning support
We added first-class support for device re-provisioning which allows devices to be reassigned to a different IoT solution sometime after the initial solution assignment. Re-provisioning support is available in two options:
- Factory reset, in which the device twin data for the new IoT hub is populated from the enrollment list instead of the old IoT hub. This is common for factory reset scenarios as well as leased device scenarios.
- Migration, in which device twin data is moved from the old IoT hub to the new IoT hub. This is common for scenarios in which a device is moving between geographies.
We’ve also taken steps to preserve backward compatibility for those who need it. Check the documentation, “IoT Hub Device reprovisioning concepts,” to learn the details. The documentation also has more on how to use re-provisioning.
Enrollment-level allocation rules
Customers need fine-grain control over how their devices are assigned to the proper IoT hub. For example, Contoso is a solution provider with two large multinational companies as customers. Each of Contoso’s customers is using Contoso devices across the globe in a geo-sharded setup. Contoso needs the ability to tell the provisioning service that customer A’s devices need to go to one set of hubs distributed geographically and that customer B’s devices need to go to another set of hubs distributed geographically. Enrollment-level allocation rules allow Contoso to do just that.
There are two pieces of functionality that light up:
- Specifying allocation policy per enrollment gives finer-grain control.
- Linked hub scoping allows the allocation policy to run over a subset of hubs.
This is available for both individual and group enrollments.
Custom allocation logic
With custom allocation logic, the Device Provisioning Service will trigger an Azure Function to determine where a device ought to go and what configuration should be applied to the device. Custom allocation logic is set at the enrollment level.
To sum things up with a limerick:
New features we announced last fall
Are ready for one and for all.
More flexibility
Makes provisioning easy
For devices from big to the small.
