Provisioning information

This section describes all of the information and parameters that you must provision to the device so it can connect to Device Management. A collection of such parameters is called a bundle.

This section covers:

1. General device information.
2. Connection configurations.
3. Update auth.
4. Ownership claiming (or first to claim).
5. Secure device access.
6. Custom properties.

Parameter rules

Parameters can be in one of the following formats:

• String: A collection of bytes (typically printable characters) of arbitrary size. The String is not a null-terminated string.
• Integer: A number, represented in exactly the specified amount of bytes, expressed in machine endianness.
• DER: A key or certificate in format X.509 DER.

To avoid conflicts, all the Arm Device Management defined device parameters listed below are prefixed with mbed.. For example, mbed.UseBootstrap. If you define your own custom properties, you should use your own prefixes, with the pattern customerName.parameterName.

Injection requirements

At a minimum, the provisioning information injected to the device must contain all of the mandatory parameters (as detailed in the tables below).

KCM stores these as key-value pairs. You need to format the provisioning information in a way that your factory tool understands and the delivery protocol supports. Then, parse and process it yourself on the device. Pay special attention to the following (detailed for each parameter in the tables below):

• Name on the device: You need to inject to KCM the parameter with the name the device expects.
• KCM type: KCM uses the type to determine how to save the parameter on the device storage, which verification to perform and how to retrieve the parameter.
• Format in KCM: Ensure that you create parameters in the correct format.

If you are using FCU, the provisioning information is formatted by FCU in a bundle and parsed by FCC on the device. The bundle's format is internal - you don't need to manipulate it. In the tables below, pay special attention to:

• FCU configuration source: Defines where FCU takes the parameter's value from.
• FCU parameter name: This is the name by which FCU knows that parameter; it is the name of either a configuration option or an API parameter.

Understanding the tables

Whether or not you are using FCU, the tables below contain information you'll need for your factory process:

• If you are using your own tools to generate and inject all parameters to the device, please use these tables to ensure that you pass the required parameters in the correct format.
• If you are using FCU to generate all parameters, you may still find these tables useful for your own understanding.
• In all cases, you may need to refer to these tables while debugging the parameter generation process.