A life cycle approach for IoT security

As with employee or customer identity management, the life cycle approach of connected objects within the Internet of Things (IoT) makes it possible to address all security issues. This article presents the key elements of this methodology and the major points to be addressed at each event in the life of a connected object.

What are the risks in the iot world?

The IoT advent has enabled millions of new potential technological advantages for consumers and companies. However, with these new advantages, certain risks are higher in the field of connected devices.


Figure 1 – Most significant risks in the IoT world


These business and technological risks which could cause significant potential impacts for consumers and companies, should be identified from the upstream phases of an IoT project.


Which project methodology to choose in order to ensure security of connected devices?

Even though security issues to address in IoT project are common for all project, we think necessary to structure reflections regarding the life cycle of the connected device.

The diagram below highlights all the stages of their life cycle.


Figure 2- A life cycle enabling to address all the security issues


Let us review  some important issues raised by this approach:

  1. Design, manufacturing, and distribution phases

This first phase addresses issues related to the design of the object, regarding business stakes, targeted users (B2B, B2C, B2E), deployment environment (controlled or not) and criticality of the use:

  • What are the regulatory constraints related to the use of the object?
  • What identity should be labeled and how is this identity created?
  • How is the security related to object’s hardware and software secrets and data stored in the object?
  • How is the state of a device on the management platform initialized, ensuring it has no right on the IS before the initialization step?

The determined choices during the manufacturing phases are crucial because they determine characteristics and capacities of the device. Some of them will therefore be immutable throughout the life of the device and will impose strong constraints in the following steps.

Furthermore, although the end of the manufacturing phase marks the beginning of the existence of the device on the device management platform, there is still no reason to consider an interaction with the IS.

Any interaction before the device’s association to a user (physical or moral) would mean that it has been diverted in the distribution phase. Any access to the IS before the initialization phase must be strictly limited to the firmware update (version N installed at the factory and version N+1 available when unpacking) or to the pre-customization of the object (operating settings or injection of secrets not related to the user). Beyond IS security, an object that is unused before any pairing phase will reduce the risk of theft of that object in the factory or during distribution.

  1. Initialization phase

Initialization phase materializes the association phase (also named pairing) between a device and its owner. Any data generated by the device (or realized action) is then declared as belonging or attributed to its owner..

Therefore, the main challenge is to ensure a reliable level of user / object association corresponding to the following business stakes:

  • Low level of association required (low-risk situation): An employee declares the usage of an attendance identification system in the meeting room;
  • Strong level of association required (high-risk situation): when purchasing a connected lock, a consumer provides a serial number and a one-time secret code to allow his mobile application to unlock the door of his home.

It is very important to find a balance between the user experience and security.

The robustness of the expected association will vary according to the nature of the services to which the customer has subscribed.

  1. Use phase

The definition of the use cases of connected devices is the most anticipated step by companies, however many aspects of security remain neglected.

Besides business use cases, additional questions must be raised:

  • How can regular updates of the connected device be implemented?
  • What are the different actors of the company roles regarding the maintenance of the device operating system layer: the application layer, and the network module?
  • What is the detection and response requirements for a compromised device?
  • How to take advantage of the company SIEM (Security Information and Event Management) and SOC (Security Operation Center) for technical security incidents (software compromise of the device) and for business security incidents (misuse or theft of a device)?
  • How can backward compatibility of protocols and APIs used by different versions of the same type of device be maintained?
  • What are the models of roles and interactions between different populations acting on the object?

Concerning this last question, and as an example, the scheme below illustrates the potential complexity stemming from the interactions and roles model such as a connected vehicle.


Figure 3- Example of a roles and interactions model with a connected vehicle (research carried out with IMT Atlantique)


  1. Resale phase

Today, the resale is the most neglected phase during the device design. This event essentially concerns devices for B2C markets and raises very specific issues:

  • How to detect and handle the resale of a device between individuals?
  • What privacy-by-design principles should be implemented to protect secrets and data from the former owner while resetting a device?
  • How can access rights of the former owner of the device be removed?
  • What are the ways to reset a device in a stable and clean state before re-pairing?

The major difficulty involves the detection of the resale event which triggers the device/user unpairing processes, reset the state of the object, etc.

Our experience allows us to identify some circumstances that could indicate a change of ownership.


Figure 4 – Examples of events that could indicate the change of ownership


Despite such examples, we witness that resale remains a complex event to identify. Thus, some companies choose not to authorize the device resale via a lease contract. The device must therefore be returned when the service is terminated; otherwise it must be made unusable. This model is comparable to renting an Internet box with an ISP (Internet Service Provider).

  1. End-of-life and recycling

Although essential, we currently have little perspective on this step, however there are multiple stakes:

  • Revoke access rights on the Information System of an end-of-life device;
  • Renew the identity of a recycled device;
  • Ensure the replacement of a defective object by re-associating a new one with the same owner and the same data;
  • Detect the inactivity of a device to trigger a replacement.

The main risks are the loss of access control over the company IS via identifiers associated with recycled devices, the disclosure of personal data of the former owner or the additional cost of license for data generated by devices considered out of the scope.


A variable capacity of action in response to the risks according to the nature of the project

At this stage of your reading, you probably think that this article is not your concern because you purchase pre-conceived connected modules or devices.

Unfortunately this mindset is wrong –  you are still exposed to the same risks! Even though you only purchase or welcome connected devices in your IS, by addressing all the issues above you will be able to feed the contents of requirement specifications to suppliers.

To conclude, whatever the nature of your IoT project, it is essential to design your object by structuring the reflections around its life cycle: from its manufacturing to its disposal. It is therefore necessary, at each stage, to address all the relevant security themes: Network / application / hardware security, standards, detection and reaction, governance, maintenance in security condition…


Figure 5 – Main security themes for an IoT project



Back to top