Device lifecycle management for fleets of IoT devices – Bits&Chips – Bits&Chips

6 minutes, 10 seconds Read

By Xavier Bignalet, Product Line Manager, Microchip Technology, Inc. and Nicolas Demoulin, EMEA Marketing Manager – Secure Products, Microchip Technology, Inc.

We hear a lot about device management, but what exactly is it, how do we implement it and how do we roll over the device management during the roll out phase and when the products are in the field?

Some large companies have started doing it themselves, but they are essentially managing the lifecycle of the certificate. Looking at changes in the security standard industry, the major ones are EN 303645, the initial European security standard, OCPP and IEC15118 for EV charging, from the Open Charge Alliance, Matter and many more.

All of these call for certificate revocation. This is good, but once we look at a certificate, there are a few things needed following this stage. You need to renew the certificate once revoked, and before anything goes wrong with it, you need to take action to audit the connectivity involving the certificates to make sure you’re not suffering from a DDoS attack for example. Some companies implement this better than others, but the standards are increasingly calling for certificate rotations, which is not an easy task.

If we regard it as a four-step process, the first step is onboarding the device. If you have an embedded device that’s composed of silicon devices that will connect to a cloud platform, how do you onboard your device identity, that’s represented by a certificate chain, into virtually any cloud platform? Step two, once that device represented by the certificate is in the cloud platform, how do you revoke the device? And once it’s revoked, you will want to renew the identity. Once you have that, you want to audit. This means that the four steps are onboard, revoke, rotate and audit.

Onboarding before product launch

Onboarding needs to occur before the product is launched to the market. If we take the example of thermostats for a house, before the customer buys the thermostat, the company that makes the product needs to onboard the device into its platform. Following this, the company needs to be able to transfer the ownership.

To onboard the fleet into the platform, the product company needs to choose a certificate authority. There are multiple providers to choose from or alternatively they can be their own authorities. Companies that choose that route are essentially becoming a customer of Microchip. Microchip initiates a secret exchange between its hardware secure module in its factories and in its secure element, and the customer itself. The customer signs a CSR and gives Microchip the authority to provision the secure element on their behalf with the credential associated to that chain of certificates. This sets up a chain of trust between Microchip and the customer.

Microchip conducts its secure provisioning using its HSM, provisioning the keys inside its secure element. What Microchip would recommend here is the TrustFLEX secure element, because it is pre-configured to know exactly that actual use case implementation.

Once we have a defined use case that uses the birth certificate and the key attestation, the next step is to load the birth certificate that is inside the secure element.

The birth certificate could be formed in two ways, either it’s built based on the custom PKI of the customer, or the customer is using the birth certificate already provided by Microchip. Once that birth certificate is loaded in the cloud platform, the fleet of devices, the thermostat or whatever product it is, is on-hold until the end customers purchase the product. The company then performs a transfer ownership from the company to the individual customer, who will start to pair with the thermostat that they bought.

However, the lifecycle of the product moves on, for example when a house is sold, the thermostat is sold with it, so what happens to the certificate? This is where revoke and rotate come in.  Revocation and renewal go hand in hand. If we simply revoke the certificate, the device is essentially dead. With a renewal system you can push a new identity to the thermostat and pair it with a new user.

There is also another use case that illustrates the need for rotation. This is the short-term rental market, when we can imagine a door lock that needs to be opened by a renter for a week, following which, a different renter will need access.

Ideally the owner of the house would want the different renters to have different passwords, which may need to change every week of the year. This is where certificate rotation can be used, synchronized to the calendar of the short-term rental companies to give that user experience. Everything is synchronized to how well you revoke and renew those certificates.

Once the attestation of that new keeper is done so that the new keeper can be trusted by the platform, thanks to the managed certificate chain, the chain of trust is preserved. The result is the generation of a new keeper that the device management platform can take over and control depending on their customer needs or customer requirements or the situation.

The Microchip ATECC608 TrustFLEX and another similar device, the TA100 both address this device management use case. They also go beyond device management, offering secure authentication, secure boot and OTA verification. The key attestation needs to be inside that secure boundary of the silicon, which allows key rotation because the keys are attested. There are also many other use cases of access or disposable authentication.

Microchip Trust Flex

Managing change

The above describes device management from the perspective of the secure element. The market sees the secure element as locked, allowing nothing to move, but this is not totally true. We can set policies to allow things to change in the configuration. This is exactly how the TrustFLEX is configured. It allows those things to happen and the TA100 is probably even more powerful because of the variety of rights and permissions it can handle.

If we look at challenges, there is a challenge of skills, – how do you implement that device management across the regions of the world? How do you implement device management during the prototyping phase, during the production phase? What happens when your product is released and what occurs after that?

When you want to remove the product from the market, you need to deactivate it, so a way is needed to terminate the usage of the product on the market. This allows companies to manage their warranties in a very controlled way, one that is better than just returning it with nobody knowing what happens to it afterwards. A company could apply a revocation at the time the device is returned to the store and then knows that that certificate is associated with a product that was a warranty return.

There is also the issue of acquisitions. If we imagine our thermostat company growing and acquiring another thermostat company, what happens to the first certificate architecture. How do you grow it to acquire that next company? Device management services can help deal with these issues of scale.

At Microchip, we would encourage our customers to implement device management for several reasons. Legislation standards, transfer of ownership, scalability and end-of-life of the product warranty are all drivers that are encouraging the market to adopt device management.

For more information:


Any Streams

AI Enabled Business & IT Automation

Similar Posts