You now have a hardware design in the correct form-factor and a working software application connecting to Device Management using a developer certificate. Before taking your device to market, you need to run a pilot, which includes:
- Field testing.
- Setting up a production process that manufactures devices that can securely connect to a Device Management account.
Field testing validates your product before you switch on your (expensive) production line; don’t run field tests after the production line has started - you'll risk an expensive product recall.
Test your product by deploying it in realistic scenarios that your customers might face. The questions that come up will help you refine your product as an entire package, including instructions and user experience. Get a list of questions and queries from multiple typical users to help your product managers address the most common and serious issues in upcoming releases. This results in a product that is fit for purpose, which translates to good reviews and better sales.
Since you developed the product and know too much to be unbiased, you need testers without any prior knowledge to give you the most useful feedback. Don't ask colleagues, family, friends, developers, or anyone who has been involved in earlier testing.
Set your test devices up in challenging places that test them in different circumstances: high or low temperatures, high humidity, low battery levels, vibrations, dust, edge-of-network signal coverage, very strong signals, intermittent connectivity, and so on. Your team can gather data and make minor adjustments to the product to ensure it works in all reasonable conditions. We don’t recommend deploying products around your own home or office, as that situation is unlikely to represent your end customers' experience.
How long you test your product is up to you, but we recommend at least 6 months to observe the majority of bugs and other issues.
While testing on the bench you were probably using a mains power supply, but field use is likely to rely on a battery. At this point, you need to remember that the most energy-heavy operation a device can perform is firmware update. Consider the number of firmware updates you perform and the device's:
- Updatable period: As the battery's power decreases, there is a point when the device is still operational - it continues to transmit and receive small sensor values - but can't perform a full firmware update.
- Working life: At some point, the battery is too weak even for simple sensor work and transmission; the device won't be operational until a new battery is installed.
You should understand the energy requirements of both firmware update and your device's normal operations, and plan update frequencies that don't drastically reduce the time between battery changes. For this, remember that the accessibility of the battery is important - a device placed in plain sight (for example, mounted on a wall in a normal house) can have a shorter battery life than a device buried in the ground along a pipeline.
Now that you've done informal testing, made adjustments, and know that the functionality is acceptable, it's a good idea to contact an EMC test house for formal certification (as opposed to self-certification). This helps you optimize product performance at the lowest cost and complexity, perhaps eliminating the need for expensive items like copper tape, gaskets and shielding material in the end product. The worst case scenario is having to halt shipments because a product does not meet legal requirements in your destination market.
A competent engineering team can often perform self-certification, but an official test house provides valuable information. A test house may also be more cost effective than purchasing expensive equipment for a one-off product.
Keep a copy of the Declaration of Conformance available for inspection.
Provisioning secure deployment devices
A secure IoT deployment relies on a secure production process and a secure connection to the services. Until now, you've been using the developer certificate we generate for your tests; you must now generate and use deployment-ready certificates.
We call the process of preparing devices for a secure connection provisioning: injecting certificates and parameters into the device so that it has the permissions and information it needs to establish a secure connection, trust firmware updates, and so on. We have developed a set of tools and best practices.
To design the correct process, you need to make a few decisions about how to onboard your device using Device Management Client:
- To connect to Device Management, each device must have a unique device certificate signed by a trusted Certificate Authority (CA).
- The private keys for these certificates must be on a secure machine, close to the manufacturing line.
- You need to upload your CA certificate's public key to Device Management, so that Device Management can verify devices attempting to connect with their unique private key.
The provisioning application
To provision a device for deployment, you need to inject certificates, keys and parameters to it. That requires an injecting side (a factory tool) and a receiving application (also called provisioning application) on the device side, which both moves the injected information to secure storage and confirms to the injecting side that everything was successfully received.
Arm offers the following provisioning tools:
- The factory configurator client (FCC) (C++), which accepts the provisioning parameters sent to the device. FCC code does not have to remain in the device's final (deployed) image; you can have a two-image process, where an image with FCC is used for provisioning and then replaced with an image that does not include FCC. This gives a smaller final image, but a slower process. To help you choose, consider:
- If your factory flow is highly time sensitive, you might wish to perform only a single image flash, meaning your image has both FCC and the main code. This increases the final image size.
- If your device, and therefore image size, is highly constrained, you might wish to use two images, and replace the factory image - which includes FCC - by an FCC-free main image. You need to flash the device twice, which means a longer factory process.
- The key and configuration manager (KCM) (C++), which stores and retrieves the KCM parameters.
- While we don't offer a complete factory tool, we do offer factory configurator utility (FCU) (Python), a set of APIs on your factory computer that manages the interaction between your own factory tool and FCC over a physical connection, such as Serial or Ethernet (TCP).
There is no requirement to use our tools (FCC, KCM and FCU); you are free to develop your own delivery system and tailor it to your security requirements.
Reference factory tool and application
To demonstrate the entire process, we have developed a reference implementation. Note that you must request access to FCU to use the full reference. Alternatively, you can use the device application portion of the reference with your own factory tool.
- An example device-side application, which includes both FCC and KCM.
- A factory tool example, which includes both a factory tool and its integration with FCU. It runs out-of-box if you are using the device-side application, and offers two injection methods: serial and Ethernet.
Together, these components allow injecting a full set of permissions and parameters to the device, and can serve as a baseline implementation that you can modify to suit your specific manufacturing process.
Choosing a device onboarding process
You need to decide whether to use the bootstrap server (recommended) or connect to the LwM2M server directly to onboard your device, as this choice impacts the information and certificates that you need to inject into the device before it leaves the factory. For an overview of various options, see the Device onboarding and connection options.
Please note that your choice of process, as well as the information you need to provision to the device, are constrained by your account association (whether or not you know which Device Management account the deployed device will connect to):
If you know which account your device connects to:
You can choose between bootstrap and LwM2M onboarding. Direct LwM2M onboarding is less flexible, so we recommend using Bootstrap onboarding.
Specify the account by passing the account ID in the
aidparameter of the
Note that when you use FCU downloaded from Device Management, this information is already filled in for you. If you are not using FCU, you need to manually set this parameter up in your own provisioning tool.
If you don't know which account your device connects to:
You can only use the bootstrap onboarding process.
You need to use our First-to-Claim feature, which allows a device to leave the factory without an account association; it's associated with an account when it first comes online.
For an overview of First-to-Claim, see Device Enrollment.
Update certificates for deployed devices
In previous stages, your firmware updates relied on developer certificates generated by the manifest tool. Since those are only valid for 90 days, they aren't suitable for deployment. You need to securely generate long-term update certificates, so that you can continue to update your deployed devices.
The authentication certificate has an asymmetrical public and private key pair, so you should:
- Store the private key on a secure machine that is only accessible to those permitted to do firmware updates.
- Distribute the public key and certificate to the application developers.
To maintain the security of your devices, generate the certificate using a Hardware Security Module (HSM), and store the private key on the HSM.
You must generate the authentication certificate and reference it in the KCM parameter
mbed.UpdateAuthCert. If the authentication certificate isn't in secure storage, the device won't be updatable in the field. See Update authentication for more information.