How to design a PKI certificate lifecycle management process for IoT devices

Public key infrastructure (PKI) certificates are straightforward to use in internet of things (IoT) devices for secure communication, access control and code signing – but the design of the certificate lifecycle management processes requires thorough considerations. In this text, PKI expert Tamás Horváth explains how to design your processes for the best possible security and efficiency.

PKI is currently the best available technology to enable secure internet communication and software upgrades in IoT applications, and to control access to IoT services and devices.

PKI eliminates the need for pre-shared keys

PKI provides IoT devices and services with trusted identities based on certificates. This allows N-to-N point-to-point authenticated and encrypted communication without pre-shared cryptographic keys.

PKI also supports the use of authorization certificates that authorize the certificate holder (a device or a service) to access a certain resource or to belong to a specific infrastructure domain (such as a building). Authorization certificates can thus replace other types of central authorization services, such as OAuth and OpenID Connect, and can enable anonymity.

A large variety of possible IoT product lifecycles

It’s straightforward to use PKI certificates in IoT applications, since PKI certificates are supported by most communication protocols, authentication and access products, and digital services.

However, the design of secure and efficient certificate lifecycle management processes requires thorough considerations. This is due to the large variety of possible IoT product lifecycles, defined by the following factors:

  •  The production supply chain of an IoT product can include a number of different steps – such as the manufacturing of the chip set and electronic circuitry, device assembly, product branding, binding of the product to a network operator, installation of the product in an infrastructure domain, and handover of the product from the supplier to the operator – and may include several actors.
  • The operational context of IoT products – such as usage in a personalized context by a specific user, installation in a specific infrastructure domain (such as a building, a city, or an organization), or assignment to a specific service instance – varies greatly. Some contexts allow the IoT product to be activated by an authorized person in a secure environment, while others require activation via the internet, using remote administration services.
  • The post-production lifecycle of IoT products can also vary greatly. Some devices may change owners or operational contexts. Some are in public areas, and some may cause considerable damage when lost or stolen. And some may require regular or ad-hoc maintenance in a secure environment or in the field.

Critical to maintain trust during the entire lifecycle

When designing PKI certificate lifecycle management processes, you must make sure that you establish and maintain trust for the IoT devices throughout the supply chains and the product lifecycles. This is essential to protect against threats such as:

  • Counterfeit products sneaking into the supply chain or a protected operational context.
  • Unregistered and possibly manipulated products being inserted in the supply chain or in a protected operational context (such as an off-the-shelf product being connected by someone to your smart home network and service account without your knowledge).
  • Unauthorized access to devices or services in order to disturb, sabotage or cause damage (such as a criminal accessing a smart manufacturing device).
  • A device being accessed by or redirected to an unauthorized service or device (which enables eavesdropping of data).

A trusted identity must be established early on

To establish and maintain trust for IoT devices during their entire lifecycles, their identities must be controlled seamlessly. This means that a trusted identity must be established for the device or its components early in the product lifecycle. Validation of this identity must then be required when assigning another identity to the component or device in the next supply chain stage, or when the device enters its operational context (that is, personalized for a user or installed in an infrastructure domain).

Ideally, IoT device components such as SIM cards, eSIM chips, microcontroller boards, or car onboard units get their first certificate-based identity from their manufacturer during their production in a trusted and secured facility.


Download the guide: ”How to build a secure IoT infrastructure.”


New certificates for each life stage

When a manufacturer delivers IoT device components to the next manufacturer in the production chain, the manufacturer should also deliver a list of the components’ identities via a secure channel. This enables the next manufacturer to filter out unauthorized components and securely provision new manufacturer-specific or context-specific certificates to the products.

This process should be carried out in each stage of the IoT device production chain. When the final product is purchased by a consumer or an organization, the operator should provision it with a new certificate for the operational context (after verifying the identity the product got from the last manufacturer in the production supply chain).

Certificates help simplifying access control

The supplier name, the operational domain name, or other identifiers such as customer account ID can be expressed in registration requests, certificate requests and certificates in several ways. The most common are to use URIs (uniform resource identifiers), DNS (domain name system) domain names, or IP (internet protocol) addresses.

The main advantage of expressing the operational context in the certificate is that it can directly represent the authorization of the device or service to act in the context, such as in a specific facility. This means that the communicating parties can recognize each other without an additional authorization or access management system. For instance, a sensor or camera will deliver data only to the control and surveillance service of the same facility if their certificates refer to the same operational domain name.

Only the legal owner can control the device

In general, the certificate for the operational context ensures that:

  • Only the legal owner can control the device.
  • Only the owner’s own device can access the owner’s service account.
  • The device can only be used within the operational context.
  • The device will not deliver data unintentionally to other contexts or parties.

Certificates can, in principle, contain wildcards, which means that all devices in a domain would share the same key and certificate. I recommend not making use of such wildcard certificates in IoT applications, since this means that the device lifecycles can’t be individually controlled.

The four steps of issuing a new device identity

In technical terms, issuing a new identity for an IoT device includes the following four steps:

  • Registration (enrolment) of the device at a specific manufacturer, supplier or operator.
  • Generation of a new cryptographic key pair, either on the device or by a secure service (this step is optional).
  • Request and issuance of a PKI certificate for the device.
  • Provisioning of the certificate (and optionally of the private key) to the intended device in a secure way.

For all these steps, security requirements must be fulfilled so that only authorized parties can perform these steps, and so that the cryptographic key and PKI certificate are bound to the intended device.

Registration and certificate authorities

For this, a registration authority (RA) and a certificate authority (CA) are needed:

  • The RA’s role is to verify the authorization for any device registration, so that only the intended devices are registered to obtain certificates for the next life stage. The registration data contains a link from the existing identity of the device to the requested identity or to a narrower identity name domain.
  • The CA’s role is to issue certificates, and to make sure that only registered (authorized) devices obtain certificates for the next life stage. The CA also ensures that the public keys and certificates are linked to the intended devices, which possess the respective private keys. The devices’ existing certificates can be used to provide a proof of identity to the CA.

Automating the certificate provisioning process

Due to the potentially vast number of devices in IoT applications, it is highly recommended to automate the device registration and certificate provisioning processes. This makes the processes both more secure and economical.

Registration and certificate requests may be generated by a CRM (customer relationship management) system, the manufacturing equipment, or a device management system such as an IoT platform. Certificate requests can also be generated and sent by the connected device itself, which is called certificate autoenrollment. Provisioning keys and certificates directly from the CA to the devices greatly simplifies the security infrastructure.

There are no standardized protocols for registration, but that’s not a big problem since the transfer of registration data to a service is a simple operation. More importantly, there are several standardized certificate management protocols for requesting and provisioning certificates, such as SCEP, CMC, CMP, EST and ACME. CMP and EST are the best for managing the certificates during the products’ lifecycles, partly because they allow for certificate autoenrollment based on authentication of the requesting device using its existing certificate.

Events during the operational lifecycle

After placing an IoT device in its intended operational context, it’s normally in operational state, but it may get lost, stolen, broken, compromised, or removed from operations. It may also be brought in for maintenance service, or change owners or operational contexts. The validity of the certificate the device has gotten from the operator may also end, leading to the need to renew it.

Automated replacement or renewal of the certificates is supported by the abovementioned protocols CMP and EST. The IoT device itself or an IoT device management system can monitor the validity of the current certificate and automatically request a new certificate with prolonged validity when needed.

Revoked certificates are not accepted

Loss, compromise, or retirement of devices should of course also be acted on. Standard PKIs include a revocation service, which can invalidate certificates. As a part of standard certificate validation, the validating party retrieves the revocation status of the certificate from either a repository of certificate revocation lists (CRLs) or an online certificate status protocol (OCSP) server.

A revoked certificate will not be accepted when its device requests access to a service, neither will encrypted messages be sent to the device. CRLs and OCSP responses can be cached for better response times and availability (I’ll go through the possible drawbacks of these certificate validation infrastructures and suggest alternative approaches in an upcoming blog post).

Loss or compromise requires reporting the event to an IoT support or device management system, which in turn can revoke the affected certificate via an interface to the certificate authority. The certificate authority announces revocations via abovementioned CRLs and OCSP services. Change of ownership or operator, or device retirement due to events such as a terminated contract, may be monitored by a CRM system, which can trigger the revocation. Among the standard certificate management protocols, only CMP supports revocation.

How to design the processes – a summary

To summarize, designing the best possible PKI certificate management processes for IoT devices includes the following steps:

  • Analyze the product lifecycle.
  • Define the proper point in time and the proper mechanism for provisioning the first certificate to the product or its components (ideally in a secured manufacturing facility).
  • Design an unbroken chain of trusted identities throughout the supply chain and the product lifecycle.
  • Make sure to automate the issuance of manufacturer-specific or context-specific certificates, as well as the renewal, revocation, retirement and replacement of these certificates – automation of these processes is key to the security and economy of the IoT solution.
  • If applicable, rely on certificate autoenrollment directly to the devices from the CAs. This greatly simplifies the security infrastructure.
  • Consider making use of the ability of PKI certificates to represent the operational domain or other authorization data, since this can simplify the access control infrastructure.

Download Guide: How to build a secure IoT infrastructure

Published 28/9 2018

News, customer cases and blog posts