Managing IoT devices correctly – this is how

The Internet of Things is still on the advance and offers companies numerous opportunities for new and innovative business models. With the number of networked devices continuing to grow rapidly, simple management and remote control of IoT hardware is becoming increasingly important. The role played by IoT device lifecycle management is therefore particularly important. Following an holistic approach to managing the devices used helps to prolong their useful life – and thus contributes to the success of a company’s own IoT use case. The lifecycle of an IoT device naturally differs depending on the sector and use case. Nonetheless, it can be divided roughly into the following phases:

• Purchase of hardware (for edge devices or gateways)
• Initial device setup and vulnerability management
• Device provisioning
• Connectivity setup
• Over-the-air updates
• Monitoring
• Resale
• Deprovisioning / disposal

These individual phases will be examined more closely below. A critical factor not least with regard to choosing an appropriate cloud platform is that the processes described below can be automated as extensively as possible. This is the only way a company can scale its IoT solution when using many devices.

Purchase of hardware

IoT devices can be connected to the Internet in three ways: Directly, via a field gateway or using an edge device that acts as a field gateway. An example of a field gateway is a mobile phone gateway with a SIM card or also a protocol converter, which connects a non-IP-enabled device to the Internet. Edge devices generally have gateway functionalities, but can also execute the business logic locally, for example, in the form of containers that can be downloaded from the cloud.

A manufacturer has to be evaluated for field gateways or edge devices and a supply chain established. Depending on the cloud platform, a certification programme exists that identifies suitable hardware in a catalogue.

Initial device setup and vulnerability management

Initial device setup then follows or, in other words, installation of the operating system and, if need be, the edge framework on the edge devices or field gateways. In an ideal scenario, the manufacturer supplies pre-installed devices including, if necessary, any licences that may be required such as for Windows devices. Lastly, vulnerability management of the software stack poses a particular challenge. A process has to be established that allows newly identified security vulnerabilities to be assessed quickly and patches deployed in good time. The hardware manufacturer may already offer suitable options. The topic of device hardening – so increasing device security – should also be discussed with the hardware provider. Among other things, it must be ensured that no unnecessary services are running on the device and that all ports are closed. This also includes protecting physical access to the devices. Device hardening along with the relevant test suites should be automated.

Device provisioning

Device provisioning involves registering the device in the IoT system and configuring it so that it sends data to the system and authenticates itself in the corporate network. This is often done on the basis of certificates that are installed on the device. Certain IoT platforms also offer a separate device provisioning service that allows this step to be automated. Nonetheless, a certain amount of implementation effort is required in order to adapt device provisioning to the company’s own processes and systems. The critical factor is whether the device is provisioned prior to delivery or only first in the field. If provisioning is performed first, it must be expected that the device will no longer be connected to the cloud for a long period – for example because it is kept in a storage facility and only used later on. This can lead to certificates expiring before the device is put into service. When the device is provisioned in the field, service engineers have to be trained to be able to provision the device locally. If a certificate is used for device authentication, a separate public key infrastructure may also have to be developed.

Apart from access credentials, the initial configuration is also loaded onto the device during provisioning. In this case also, the cloud platform should offer an automation mechanism, such as device templates that are applied automatically to certain device groups.

Connectivity setup

In principle, every IoT device (or every field gateway) can be connected to the Internet in three ways: by means of a local infrastructure (LAN, WLAN), via its own mobile broadband access or using LPWAN (Low-Power Wide-Area Network). Access via satellite will also be a realistic option in the future. Mobile access can ideally be configured prior to delivery. The biggest challenge lies in managing the mobile contracts (including roaming) and the associated SIM cards or eSIM-enabled devices. With LAN/WLAN access, the local network access data must be configured for each individual device, including any proxy and DNS server. This is often not possible in advance, since it is not known which device will be installed in which local network. The proxy servers pose a major challenge in this respect, especially if they interrupt the TLS connection to the cloud gateway (TLS interception).

LPWAN connections bring their own challenges and cover their own category of IoT use cases.

Over-the-air updates

Once the device is installed in the field, configured and connected to the cloud, it must be possible to update it from the cloud. In particular, this applies to security patches in the software stack, but also the loading of new server TLS root certificates from the cloud gateway or configuration updates. With edge computing, the cloud platform must also offer lifecycle management for container images that are to be loaded onto the devices. In the event of errors occurring, the update functionality should be able to automatically roll back to a functioning setup. It should be ensured that devices with very old software can still be updated using the remote update functionality. Furthermore, the integrity of software updates must be ensured since, even worse than loss of data, is the risk that IoT systems will distribute malware (viruses, ransomware, bitcoin mining, etc.) on a large scale – not only to the company’s own IoT devices, but also to entire (customer) networks.

Monitoring

As long as IoT devices are in active use, it must be possible to monitor them via the cloud. This is described as fleet monitoring, since each individual device as well as groups of devices are monitored – both in respect of the device status as well as the configuration, the status of edge containers and system parameters such as capacity utilisation or energy consumption.

Under certain circumstances, monitoring of edge devices also includes automatic scanning for malware. Likewise, it must be possible to carry out device hardening tests regularly in the field.

Resale

In the same way that a car changes hands many times over its lifetime, IoT-enabled devices and machines can also be resold. The question here is what should be done with the data: In other words, which data should a buyer of an IoT device be allowed to see when they purchase it? Does my IoT platform take account of functions when an IoT device changes owner (or clients) over its lifetime? In the case of IoT-enabled machines, should data from acceptance tests within production be made available to the first seller or not? Does the machine retain its identity when sold – in other words, serial number plus owner ID – or not?

Deprovisioning / disposal

It must be ensured when deprovisioning that the device is also deregistered in the cloud and therefore that the access data stored on it becomes invalid. This is a challenge if the cloud only knows the root certificate and all certificates derived from it are accepted.

This text is taken from our updated IoT and cloud platforms booklet.