IoT Device Management and the FIDO Alliance: Has the Time Come for Zero-Touch Device Onboarding?

The onboarding dilemma consists of a need to manage multiple Internet of Things (IoT) devices, which is easy to onboard, yet neither proprietary code nor compatible with only a small number of hardware devices. Instead, the onboarding solution should support a larger amount of hardware and leverage open standards. Prior to FIDO’s answer to the onboarding dilemma, OMA (Open Mobile Alliance) also sought to address these shortcomings and introduced LwM2M (Lightweight Machine-to-Machine) which is an application layer for device management that can also be zero-touch in certain conditions. However, for customers that use a MQTT messaging protocol with a broker instead of a LwM2M server, the friction remains as their MQTT device manager is normally unable to onboard devices in a zero-touch manner; if a customer can onboard zero-touch, then it is limited to a given set of hardware if not proprietary altogether. This creates friction for customers to switch suppliers. FIDO says FDO addresses these pain points by introducing a specification that supports both Constrained Application Protocol (CoAP) and Transmission Control Protocol (TCP)—these transport protocols are leveraged by most messaging protocols including TCP-based MQTT as well as LwM2M, which was solely based on CoAP.

Prior to FDO, the device manager must be decided at the point of manufacturing the device in the factory. As customers being forced to make an early decision is typically fraught with risks of inflexibility as they may be unable to switch later, FIDO’s solution is late-stage binding. The security credentials are provisioned later in the stage when the device is onboarded instead of early on in the manufacturing stage. FDO has an ownership voucher outside the device by having a digital proof of ownership, effectively a “text file” with an encrypted key passing through the supply chain, as the mutual authentication between device and cloud is based on a root of trust in the device and the ownership voucher in the cloud. Then the ownership voucher is registered with the rendezvous server. Upon boot-up, the device calls the rendezvous server that was programmed into it in the manufacturing stage, and the rendezvous server matches the IoT device to the target cloud or other device management platform by providing the web address for the target platform to the device. Different rendezvous servers can be programmed, either on-premises or in the cloud. FDO lies dormant till it is again activated if there’s an ownership transfer (e.g., device is returned or device is sold). So, FDO’s major role is in the commissioning and de-commissioning of the device. Thus, FDO’s importance stems from it solving the problem of companies forced to choose their IoT device managers early in the solution’s lifecycle. Now, instead, the manufacturer only has to install an FDO client on the hardware.

FDO adoption may not be straightforward to predict but this is the most notable attempt to simplify IoT device onboarding with ‘late binding’ since Intel’s SDO (Secure Device Onboarding). Intel announced SDO in 2017, however, at that point the IoT market was still in its nascent stage and the standard did not gain the traction Intel had hoped for. Although FDO and SDO are similar in functionality, since some of the key features, including late binding and ownership vouchers, were present in Intel’s SDO. FIDO says the benefits of FDO are that it is an open specification which has become an industry standard and FDO had input in development from the leading cloud service providers, semiconductor, and security companies.

However, FDO’s biggest challenge will be gaining traction through partnerships with players across the IoT value chain, which will be a key factor in driving adoption. Enabling FDO requires co-operation from digital security firms like Device Authority, alongside support from hardware vendors who manufacture equipment and install the FDO client on the IoT device, as their manufacturing tools provide device credentials and create the ownership voucher. Another key part of the IoT value chain are the cloud hyper-scalers (AWS, Microsoft, and Google) who have supported the development of the FDO specification. This shows FDO has the support to resolve a major pain point in device management, the zero-touch enrollment for a scalable IoT deployment.

Other attempts have been made to address the zero-touch onboarding problem outside of FDO and SDO, such as LwM2M, however even OMA’s LwM2M requires device clients to be installed before deployment or the device ships with a LwM2M agent at the point of assembly. The benefit of FDO is its messaging protocol agnostic so the amount of device managers it can support for onboarding spans both MQTT-based device managers and LwM2M-based device managers. FDO, however, is not a panacea for pain points in IoT device management. Since the LwM2M application layer address another pain point, it makes it easy to switch device managers since Over-the-Air (OTA) updates, remote monitoring and diagnostics features are also standardized, so the LwM2M device and agent can support alternative device management platforms. Nonetheless, FIDO has an answer with FDO to one of the key pain points, the onboarding problem, and unlike SDO, this time round other players in the industry recognize its value as well.