Secure edge device provisioning -

Secure edge device provisioning

A secure and robust over-the-air (OTA) software update solution can mitigate security risks associated with deployed devices at the edge of the network.

A connected device in its lifetime will need to be provisioned, deployed, maintained and at some point, in its end of life taken offline (decommissioned). When you want to design a new connected device or retrofitting an existing one for the Internet-of-Things (IoT), you will have to provision the device initially which brings the device online and gets it connected to cloud services. The provisioning steps need to consider both the user experience and security.    

In this article, you will learn about security risks associated with deployed devices at the edge of the network and how a secure and robust over-the-air (OTA) software update solution like Mender can be used with Azure IoT Hub to simplify your IoT edge device provisioning and manage OTA updates and device management with one single service in Mender.

Connected devices at the edge

For enterprises with large scale IoT deployments, edge devices have surfaced as an effective way of measuring and processing data closest to the source (near data-generating devices). This has the benefit of reducing bandwidth costs, data latency from device-to-cloud, addressing security and privacy concerns. Emergency responses through alert notifications can also be dealt with faster if the detection workloads are processed at the edge.

As edge devices become pervasive on the IoT landscape, the diversity and distribution of connected devices is mounting. Software for edge devices require continuous updating to ensure the devices are secure, functional as intended by design and stream the correct data back to the cloud for storage and processing.

Security at the edge

Like any device connected to the internet, devices at the edge of the network bring with them notable security risks. Malicious actors can infiltrate and inject unauthorized software components into the edge node and install anything they want which can cause irreparable damages. One such scenario is known as node replication (research by IEEE), where attackers insert malicious nodes into the edge network and allot it an identification number identical to the existing node. Then like a spy disguised as stealing valuable information from within the network.   

Another security risk is the possibility of an attacker physically interfering and damaging edge devices and compromising the network stability by opening the entire network. Edge devices create an increased attack surface by being near the data-generating sources. Once physical access is achieved, malicious actors can take sensitive cryptographic information and install and modify node software and operating systems. 

The table below provides two other notable security threats to edge devices along with the weaknesses that make them possible:

Attack vectors Role in the attack
Device-to-cloud communication Attacker updates software in transit: A device will send its backup out to the cloud and will suffer a short downtime during reboot. If the connection is unencrypted and the update files are unprotected, a hacker could steal or alter sensitive information.
Unverified software deployment An obsolete or altered version of a software package is knowingly installed on a device that may contain vulnerabilities which are exploited by attackers.


Device provisioning

The first stage in deploying and managing devices remotely is provisioning. Provisioning essentially brings the devices online and gets them connected securely to cloud services. Devices have life cycles that span many years so secure remote provisioning is crucial to keep them up to date rather than replacing them. It must be handled with the utmost security to prevent loss of data, control and being attacked by external actors. There are two layers of provisioning: the server-side and the device-side. Server-side provisioning sets up the server-side configuration data that allows for registration, authentication and authorization to several cloud services such as Device Management, telemetry and ERP systems. Device-side provisioning allocates credentials and configuration data to the physical device.

However, device provisioning remains highly fragmented and custom with no single provisioning workflow that works across all hardware and cloud services. Since several layers and components are involved, that are usually interdependent on each other, device provisioning is an inherently complex problem that IoT development teams spend significant effort on creating and improving (as issues are discovered).

For example, the OTA update client on the device should not start before it has been registered in the OTA update server. Once the device has been fully provisioned, it should be available to the customer support team (but not before). The ordering of this is very important.

Simplifying device provisioning for IoT    

IoT devices connect to the cloud solution first by establishing the initial connection between the device and the IoT solution by registering the device and then applying the proper configuration to the device based on some specific requirements it was registered to.  A typical workflow would be: 1) Device credential setup 2) Configure servers to connect to device 3) update device to latest configuration over-the-air (OTA), and 4) authenticate and register device in all relevant cloud services backends. When these steps have been completed, the device can be considered fully provisioned. Some IoT cloud service providers only do the first step of the provisioning process and do not provide the initial configuration. Also note that device provisioning (e.g. certificates, private/public keys) may be partially done in the manufacturing of the device or by different hardware vendors (e.g. NXP) or electronics distributors.

In steps 3 and 4 above, choosing a simpler provisioning that enables a smoother user experience means finding the OTA update and IoT cloud services that minimize friction in these operations. Services like Azure IoT Hub and Mender enable users to work with one service but yet the capabilities of both: managing devices and deploying software over-the-air (OTA) using Mender combined with IoT Hub for applications and telemetry. With Azure Device Twins in Mender, users can have all the information about devices in a single panel in the Mender interface, configure each device, and update them directly from Mender. Essentially, Device Twin is a JSON file that is representative of device properties which a user can configure within the Mender UI and consequently deploy the update to the device with Mender. With Azure Device Twins, Mender users can avoid making their own device portal for merging data and instead manage all of their device information through one simple Mender web interface making it easier and more efficient. These two services will typically cover all the needs of users to manage devices, applications (software and data) and analytics for IoT.

Today, over-the-air (OTA) software and device management solutions are segregated from IoT cloud service providers. Yet there is still a need to connect every device to both services.This makes managing separate key credentials on the device as well as making sure the device is created in the cloud service risky and cumbersome. In the event of a failure with this setup, neither the device would be able to send telemetry data, nor would it be able to receive OTA software updates.      

To simplify the workflow the devices should be registered once in a single service and then ensure that it is kept synchronized, even when rotating device credentials. This must be applied to both device and cloud identities and credentials, and other provisioning information. Additionally, the user would want to lookup and control device information in one single source.

The Mender integration with Azure IoT Hub focuses on solving the above-mentioned problems (Figure 1).

click for full size image

Figure 1. Steps in provisioning devices to Azure IoT Hub with Mender. (Source:

When you create a new device in Mender (manually or automatically), the Mender server will automatically create the same device in Azure IoT Hub, by generating a new, secure symmetric key for the device. With the Mender Configure add-on, Mender will also distribute the symmetric key for Azure IoT Hub to the device, making it available for use. In production, it would take an average of 15 minutes depending how often the device checks for updates.

The Mender client would normally ping the Mender server for any updates, then the Mender client would receive the key for Azure IoT Hub from the Mender server as it was created by the Mender server. Since the device has the key for it, it is authenticated with Azure IoT, and it can start sending telemetry data immediately. Mender will continue to manage the device life cycle and synchronize this device information to Azure IoT Hub. For example, if the device becomes Rejected in Mender, Mender will disable it in Azure IoT Hub.

This integration will have several benefits:

  • Simplifies provisioning of device between Mender and Azure IoT Hub
  • Reduces operational complexity by allowing users to work with one service instead of two
  • Increases security by simplifying device-side credentials management
  • Correlates analytics from Azure with past software update deployments from Mender

Even though there seems to be the chance of exposure of Azure authentication credentials when transferred and maintained in another repository, Mender already has a secure channel to the device (https based) so attacking in transit isn’t possible. Attacking in storage isn’t possible either, as regardless how you transfer the credentials the device needs to store them.  See a tutorial on the integration here.

Additionally, Mender exposes the Azure IoT Device Twin in the Mender UI allowing all the device information to be exposed through the Mender UI.


IoT device security and provisioning is complex by nature and can be exacerbated when working with different IoT services such as OTA update managers, device management and IoT cloud service providers because they each work in silos. Proper integration of third-party solutions with IoT cloud services can solve this very problem. Users should no longer need to manage device registrations in multiple places and once a device is registered in one service, it is also registered with the IoT cloud service provider (e.g., Azure IoT). Since the same device identity is used across both services, analytics from the cloud can be easily correlated with past software update deployments in the integrated service. The number of secret key credentials that need to be handled and protected is minimized, which results in stronger security through more focused oversight.


Farshad Tavakoli is the technical product marketing lead for the project at He is an IoT enthusiast and advocate of ‘all things IoT’. He periodically writes about IoT and related embedded device technologies which help customers build delightful IoT device management solutions with Mender.

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.