Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Galem KAYO
on 9 October 2019

A reference architecture for secure IoT device Management

One of the key benefits of IoT is the ability to monitor and control connected devices remotely. This allows operators to interact with connected devices in a feedback loop, resulting in accelerated decisions. These interactions are mediated by a device management interface, which presents data in a user-friendly UI. The interface also serves as a client to remotely control devices in the field. Device management is, therefore, a key component of IoT solution stacks, with a significant impact on the ROI of such deployments.

However, there is no one size fits all when it comes to device management solutions. IoT solutions are deployed in various contexts. The purpose, the devices, and the users involved vary from one deployment to another, even within the same industry. It is, therefore, challenging to find a ready-made device management solution perfectly suitable to any given deployment.

Security is the critical requirement that these deployments invariably share, for it must be implemented in line with the best practices. Secure authentication and communication encryption are indispensable for the management of mission-critical device fleets.

The challenge

When it comes to IoT device management, the core challenge is the following: how to implement a solution that is both secure and perfectly suited to the intended use case? Our answer entails three main elements:

  • Microservices implementing management functions
  • A secured implementation of the MQTT protocol for communication
  • Orchestration of the microservices with Kubernetes

Our device management solution exposes devices running Ubuntu Core over a simple UI. These devices are authenticated and communicate securely with an edge cloud hosting their digital twins. All the elements of this solution are open-source. We will elaborate on how these elements combine to deliver a comprehensive reference solution for IoT device management.

Building blocks

At the device level, our reference architecture builds on snaps, the universal application container format portable across multiple Linux distributions. Being strictly confined and transactionally upgraded, snaps offer security guarantees that are important for mission-critical applications. Ubuntu Core, the distribution of the Ubuntu open-source operating system dedicated to the internet of things, is fully built on snaps. In addition to the security benefits that Ubuntu Core brings, it runs a daemon that exposes a REST API. Devices are therefore accessible via an API; a key pre-requisite for remote management delivered out of the box with Ubuntu Core.

Hardware requirements

The multiple services that make up this solution are to be executed at the edge. Therefore, implementation requires hardware, suitable for usage conditions in fields of operations. Such hardware will need sufficient computational capabilities to perform as a worker or master node in an IoT cluster. The capabilities required will vary depending on the complexity of the intended deployment. However, computational power will have a direct effect on the CAPEX of the deployment, since it affects the number of IoT devices that can be served by a single gateway. The more devices supported by a single gateway, the lower the total investment cost.

Securing communication

Device management requires a server infrastructure to mediate communications between devices and the management interface clients. MQTT is the communication protocol implemented in our reference architecture. MQTT is an ISO standard pub-sub messaging transport protocol, which makes it adequate for constrained bandwidth.

In this implementation, a client application is installed devices as a snap. A broker service is installed on the server-side. Communications occur through an encrypted port. Messages are entirely encrypted over the wire. Furthermore, client-server authentication is carried out using certificates issued by a single authority. The private keys remain securely stored on-device, they are never communicated over the wire. This measure adds a layer of security to protect privacy and integrity of exchanged

Service orchestration at the edge

The device management solution is made of several components implemented as microservices hosted at the edge. Each service plays a key role in the overall solution. These roles are described in this section.

MQTT broker

This service implements a message broker based on the MQTT protocol. Devices connect to this service through a client. The broker receives and sends messages in channels subscribed to by devices in a publisher-subscriber pattern.

Identity service

To maintain security and integrity, access to channels hosted by the broker should only be granted to trusted devices. The identity service vets devices requesting access to these channels. This vetting is done by verification of devices public keys against a registry of pre-authorised devices. This verification is carried out upon the first connection. If successful, the service issues certificates and authentification details, which are cached into devices for subsequent requests.

Device twin

Once connected and authenticated, devices can post telemetry data to channels hosted by the broker. Telemetry data is transmitted in time-series to the broker and stored on the server. Digital ‘twins’ can thus be effectively created for each managed device.

Management UI

Graphical web interfaces are more practical to manage fleets of IoT devices. An open-source management user interface was created within the scope of the reference solution. It allows access to telemetry, remote management, as well as authentication.


Kubernetes can be used to deploy the services described above at large scale, with availability levels adequate for mission-critical applications. The deployment can be carried out on edge gateways.


We have described how a simple and secure device management solution can be assembled from open-source components. Openness allows for customisation. A more detailed description of the implementation of each component will be provided in an upcoming Canonical whitepaper. Links to the source code of our implementation will also be shared in that whitepaper, for anyone to reuse and improve.

Related posts

Andreea Munteanu
13 June 2024

Solving newcomer data science challenges with Canonical’s Data Science Stack – now in beta

AI Article

Data science is one of the most exciting topics of the last century. With its utility in industries of all kinds, it’s easy to see why it has been rated as one of the top 20 fast-growing occupations in the US, according to the Bureau of Labour Statistics.  However, entering this fast-growing space isn’t’ easy: ...

13 June 2024

World’s first RISC-V Laptop gets a massive upgrade and equips with Ubuntu

Canonical announcements Article

DeepComputing partners with Canonical to unveil a huge boost to the DC-ROMA RISC-V Laptop family  The DC-ROMA RISC-V Laptop II is the world’s first RISC-V laptop pre-installed and powered by Ubuntu, which is one of the most popular Linux distributions in the world, providing developers with an outstanding mix of usability and reliability, ...

Henry Coggill
12 June 2024

NIST CMVP Interim Validation & Jammy FIPS

FIPS Article

If you need FIPS-validated cryptographic modules for your deployments, you may be aware that these have been turbulent times in the FIPS world. We have seen the introduction of the new FIPS 140-3 standard, with the older 140-2 being phased out (all existing certificates will expire by September 2026 at the latest). The industry has ...