As connected devices become more present in our daily lives, the topic of IoT security is progressively gaining interest among users and the industry alike.

IoT devices are characterized by being smart, omnipresent, and connected. They handle and are conscient of sensitive data when integrated into users’ personal lives or when used by businesses in their activities. Guaranteeing that the information being transmitted is secure should be a top priority.

But then why is it that many infrastructures are vulnerable to the point where perpetrators can still easily infiltrate and overtake entire networks? (See the Mirai botnet attacks of 2016, for example).

The reality is that the vast majority of IoT devices have limited computing resources. Most operate on low memory and reduced operating system functionalities. Some devices do not support updates or patches to the operating system. Furthermore, traditional security solutions are not guaranteed to work on all devices, making it difficult to standardize the security process.

In an IoT infrastructure, connected devices represent several possible network entry points, as they may be placed in different locations. The number of connected devices, as well as the distance between them and the point of control, makes it difficult and costly to ensure the physical security of devices. They risk being stolen, reverse engineered, used to break into the network as a whole, and repurposed to be used for malicious ends.

When a network is intercepted, all connected devices become vulnerable and subject to being impersonated. This is why one of the important things to keep an eye on when securing an IoT ecosystem is the network.

Using TLS certificates is a popular method for ensuring network security, as the certificates are lightweight and provide strong authentication.

Generating the Certificates

Scaleway IoT Hub allows users to attribute a TLS certificate to each connected object, allowing encryption and mutual authentication between them and the IoT Hub. Encryption prevents exchanged messages from being intercepted. Mutual authentication certifies to the object that it is connecting to the IoT Hub and vice versa.

IoT Hub allows you to choose between 2 levels of security:

  • Deny insecure connection: the object will only be able to connect with encryption and mutual authentication (mTLS).
  • Allow insecure connection: the object will also be able to connect without mutual authentication (TLS), or even without encryption.

One of these must be chosen when adding the Device to the Hub. The most secure setting, "Deny insecure connection", is selected by default.


  • If "Allow insecure connection" is chosen, then it is only necessary to save the certificate created for the device if you still want to use the mTLS. The connected object will be able to choose between an encrypted (port 8883) and an unencrypted (port 1883) connection.
  • Otherwise, you must imperatively install this certificate on your connected object to allow it to communicate with IoT Hub. It will have to connect to port 8883.

Connection Modes

  • Mutual-authentication TLS
    This is the strongest security for a device. The connection is encrypted with TLS, and during the handshake, the Hub will verify the identity of the device, and the device the identity of the Hub.
    For that two-way verification to occur, the client must possess the device’s certificate and private key, which are displayed only once at the creation of the device (Scaleway does not store them). It must also possess the certificate authority of the Hub, which can be downloaded from the Hub Networks tab, in your Scaleway Console.
  • Server-authentication TLS
    This mode offers an intermediate level of security. The connection is still encrypted, but only the device verifies the identity of the Hub, not the other way around.
    For that one-way verification to occur, the physical device must only possess the certificate authority of the Hub.
  • Plain
    This mode offers no security. The connection is neither encrypted nor authenticated. We do not recommend using it on production systems.

Note: In Server-TLS and Plain modes, your devices will use a token to identify themselves to the Hub.

Depending on the level of security, you can select different connection modes:

Securing the Certificates

Ensuring that the certificates are securely stored in the device is also very important. Yet, since most devices are different, a built-in standardized approach to the application of security measures is not always possible.

Best practices to ensure security yourself include reinforcing the physical security of the object, storing the certificates in a space that cannot be removed from the object, like a flash component soldered on the motherboard, for example, and blocking remote access to the file system of the object (usually done via debug ports or SSH). These can be efficient alternatives, but do not solve the problem with the lack of standard processes.

One of the most popular practices among IoT device manufacturers is integrating Secure Elements into the devices during production.

Secure Elements are cryptographic chips that can be embedded into IoT devices. They provide secure storage environments for sensitive data, such as TLS certificates. They act as vaults, ensuring that the data is stored in an encrypted space. They also perform cryptographic operations so the certificate keys never leave the chip.

On Scaleway IoT Hub you can replace the default certificate, generated by Scaleway, with one generated by a third party, using Certificate Authority. With this feature, you can have your Secure Element vendor issue certificates on your behalf and program them into the chip. Alternatively, you can also use self-generated certificates.

Going further

To dive deeper into the topic IoT Security, you can check out our blog post about mTLS, and by taking a look at our documentation page.