Introduction to secure edge device onboarding

Think about the most common way devices are deployed in non-edge-computing architectures: You send the device to the place where it will be used, then you send (or give remote access to) a specialist who performs the installation, configures the device, and deploys the required applications on top of it.

This model is valid if you don’t have a lot of devices to install. However, consider the scale of a typical edge computing solution, where you could have hundreds or thousands of devices to deploy. Sending specialized people to all locations could be slow, expensive (think about edge locations like windmills in a mountain range), and even insecure. You need new ways of deploying and performing the initial device configuration. What are the alternatives?

You can minimize costs and reduce delays (avoid sending specialized people) by preparing the devices in a central place before shipping them instead using specialized people to install it on-site. You could deploy and install the device, probably using images you can flash to the device and then send the preinstalled device to where it is needed.

If you want to take this approach, you have a couple of options. You could build specific images for each device. Or you might create an image template that can be easily customized by a nontechnical person or automatically using zero-touch provisioning. Customizations might include specific variables for the site, device purpose, and so forth.

If you don’t want to end up with a sea of device images, which could be complex to manage at scale, you will probably use an image template. But you must still figure out how to automate the customizations that must be made at boot time and even in that case change management could be complex (think that every customization change would imply rebuilding the images).

As explained, the traditional way of onboarding devices does not scale for edge use cases and an possible solution has been discussed: creating customized device images that can be installed by any non-specialized people onsite, but in that case you find an additional concern: Security.

Your solution must also take device security into account. As part of every deployment, you will probably need to include in the device image sensitive data, such as passwords, certificates, tokens, or keys. How do you plan to distribute them?

If you decide to inject those items directly into the images or templates, you create risk, since someone could access the image and extract that sensitive information.

An not only that, think that every time that you need to change those items (or any other customization) you will need to re-create again the device image, and probably re-distribute it to your edge locations, which at the end of the day, is a really complex model to manage.

There is still a way to solve this problem, instead of embeding all the intelligence and options in the image template as explained, you could build something more flexible and scalable by including the intelligence and options in a remote, centralized piece of the solution that will decide, depending on the device type, which components and configurations to apply, and where you can perform any update or change in the customization without involving to re-create and re-distribute images.

Instead of including secrets on the images, it’s better to have the device download them at installation time using a secure channel while onboarding, so you don’t keep any sensitive data on the image.

You could deploy an architecture where you provision template images and store the configurations in an external system. When the device boots up, it starts an automation process that finishes provisioning it, including the specific settings and software it needs to do its job, but this means that the edge device has to download these secrets from your central server.

How will you set up that secure channel? You could use encrypted communications or a virtual private network (VPN) tunnel, but that’s not enough. How can you be sure that the device is what it says it is and not a possible attacker trying to steal information or gain access to your network? You have another concern: authentication and authorization. Authentication is even more important, especially for companies that use third-party providers to create the device images or add other value to the supply chain. You need to determine whether the device asking to be introduced into your network can be trusted or not, depending in part upon who provides the image.

This approach provides zero-touch provisioning that doesn’t need a specialized person at the edge location but it is too much to do on your own, so probably you will need something already developed.

The market has addressed these challenges with several solutions. Yet many of these solutions are proprietary and not based on an industry standard, which could lead to vendor lock-in issues. It’s not their fault, as there wasn’t a clear industry standard for device onboarding…​until 2020.

This year, the FIDO Device Onboard (FDO) specification was released. FDO is an industry standard that solves the problem of trust and chain of ownership with the automation needed to onboard a device securely at scale, and that is being adopted as the defacto standard for edge device onboarding.