Mistake on this page? Email us

Requirements for Client Linux production devices

Device Management Client runs on any Linux system.

Hardware and software requirements for Pelion Device Management Client production devices

Capability Device Management Client Comments
CPU Any CPU. *1 Any single-core capable of running Linux is enough.
RAM 1 MB Device Management Client itself is extremely light, but your Linux distribution and other parts of your stack can impact this significantly. Typical Linux boards have 256 MB to 1 GB of RAM which is typically more than enough for the Device Management Client.

Verify your assumptions according to your Linux distribution and application stack combination.

Flash/Storage Minimum 4 MB Typical Linux distributions require at least 30 MB for the root FS. However, if you add heavy stacks, the size can easily grow up to 1 GB. The storage must be partitioned in a particular way for firmware update to work.

Verify your assumptions according to your Linux distribution and application stack combination.

Networking IP-based networking. Ethernet, Wi-Fi or similar. For non-IP based connectivity, see Edge and its protocol translator capability.
Root-of-Trust (RoT) Recommended. Secure memory for hardware root of trust.
On-die flash as minimum. See note *2.
True Random Number Generator (TRNG) Recommended. See note *3.
Clock Optional. Either a
- Real Time Clock or
- some low-frequency crystal (for sleepy devices) or
- SW clock (non-sleeping devices) that provides the device proper time.

This is needed to handle any certificate validity time attacks.

Secure boot module Recommended. The secure boot module checks the integrity and authenticity of the firmware at boot time to protect the device from re-flash attacks.


*1 Device Management Client does not require any specific CPU. All code is C/C++ and as long as we have a working C and C++ toolchain, any CPU will do. Currently, porting has been done to multiple Arm, Intel x86, Intel x64 and MIPS architectures.

*2 Device identity and keys stored on the device need to be protected for their integrity and confidentiality. Some of these must be immutable.

The recommended practice is to use a local RoT, stored on die, which protects information stored on an external flash. The local RoT is stored on die in one-time-programming bits or an internal flash, with access control and optional write protection. This protects the device from physical access attacks (such as re-flash attacks) and software vulnerability exploitations, which extract the keys and remotely take over the device.

*3 For secure communication and secure device identity, a random number generator (RNG) needs to be seeded with cryptographically strong entropy. The recommended practice to provide such a seed is to use TRNG hardware capability. Alternatively, if your platform has no TRNG, we offer software-based deterministic random bit generation (DRBG) and rely on entropy or key injection during device production.

Software stack

You need to choose an OS for your IoT Device. Device Management Client is pre-integrated with Mbed OS, which provides the capabilities described below. However, you can choose a different RTOS and port Device Management Client by implementing a Platform Abstraction Layer (PAL) for it. See the porting guide for more information. We provide a porting layer to Linux.

If you plan to use Device Management Client with an OS other than Mbed OS, you need to choose a platform and components that provide the following capabilities.

Capability Description Comments
OS * Mbed OS v5: See the compatibility matrix.
* Linux: Ubuntu 16.04 LTS, Yocto v2.3.x
For porting to other OS/RTOS, see the porting guide.
Storage Flash and filesystem drivers.
Networking * Networking Drivers.
* DNS resolver.
* Optional (recommended): DHCP.

* IP over the HW supported bearer.
* DNS and DHCP simplifies the device configuration during deployment.
Crypto/TLS Mbed TLS or equivalent Crypto and TLS/DTLS libraries. You should configure Mbed TLS to use only the latest TLS cipher suites, because older ones become vulnerable.
TRNG Driver Platform’s TRNG driver.
Crypto module programmed to use the TRNG.
System Tick System’s tick availability at a rate of at least one tick per millisecond (higher than one Khz tick). The tick is the OS (platform) kernel system tick counter.
Software-reboot Ability to software-reboot the device. Required for tests and for Device Management Update.
Bootloader Bootloader with firmware update capability. Required for Device Management Update.
Optional, if you do not use Device Management Update.
We provide a bootloader you can use with Mbed OS and reuse in other platforms.