IoT certificate manager


IoT certificate manager provides complete control of the x.509 device certificate lifecycle removing the headaches of manually managing the renewal of the credentials on thousands of devices.

It leverages the Root of Trust in the u-blox module and a secure dedicated channel to automate all of the operations necessary to maintain fresh, valid device authentication for IoT platforms, even in challenging scenarios where credential replacement is required every month in big fleets.

Designed and optimized for IoT environments, it removes the errors that can occur when manually operating on large IoT deployments, freeing resources for other activities.

Managing the lifecycle

u-blox Zero Touch Provisioning (ZTP) provides an enormous advantage at the beginning of device life by simplifying and automating the tasks required to create and inject credentials in the device. While traditionally these operations are done on production line, causing additional costs due to maintenance of dedicated systems and error recovery, u-blox ZTP performs all the steps for X.509 device certificate generation (public and private key generation, certificate generation and signature with Root CA and finally the Over the Air provisioning) autonomously when the device is in the field. Of course It can be done during production line as well if internet connectivity is provided to the module.

ZTP provides up to 15 private Certificate Authorities for each Thingstream domain without the upfront investment and ongoing maintenance costs of operating your own private CA. It allows customers to be more agile by providing APIs and automatic functions to generate and deploy private certificates programmatically to address every scenario using different validity periods.

During the device lifetime, to keep an adequate level of security for the device authentication and for the integrity of your data in motion, you need to maintain the device credentials (certificates) to connect to your preferred IoT platform.

The u-blox IoT certificate manager service lets you easily address all the related operations that would otherwise become very complex and time consuming even for few tens of devices.

It provides full visibility and lifecycle control over all digital certificates and keys in your IoT environment. It automatically keeps tracks of each device certificate expiration, renewing it in advance without any manual action avoiding service interruption.

Ten years of device life is a very long time during which a security incidents could happen because of the increasing number and complexity of attacks. For this reason it is important to support your business with a solution that allows you to :

  • renew very frequently your credentials so that the authentication in the IoT platform is always valid

  • quickly and remotely recover compromised situations, by replacing the device certificate and key pair with a fresh set, without a manual intervention in the field or without calling back the device to the factory, avoiding additional costs and delay.

  • move devices in bulk, across different certificate authorities. E.g. to handle the certificate authority expiration or to switch from a test to production environment or for several other scenarios where you want to segment/group devices using different certificate authorities

u-blox's smart approach allows speed, flexibility, and scale for securing today's complex IoT environments while future-proofing your business against future threats.


To use the IoT certificate manager service you need:

  • an existing account in the Thingstream portal. If not yet done please refer to the Getting started guide

  • a u-blox module that supports the service (see the Availability section at the bottom of this page)

  • a SIM to connect the device to internet. The module configuration for the internet connection is out of scope of this guide but you can refer to [1] at the end of this guide

  • access to the Security services API documentation

Note: the IoT Certificate Manager is applicable to X.509 certificates generated using the u-blox Zero Touch Provisioning feature and not for certificates generated through third party tools or software. Before using the IoT Certificate Manager service the device certificate must be generated and provisioned using u-blox Zero Touch Provisioning.

Service activation and billing

The first action is to activate the service using the Security Service section of the Thingstream portal. You can activate the service by selecting the proper plan either at Device Profile level or at Thing level.

  • If you associate the plan to the device profile, every device that bootstrap with the selected DeviceProfileUID automatically gets the service activated during the bootstrap process

  • You can instead change the plan for a singe Thing (device) in the Thing details section of the UI

Details of the available price plans can be found on our pricing page.

For initial testing we suggest to use IoT certificate manager developer plan. Once you are ready for the deployment in production, you can simply switch to one of the commercial plans.

Use cases

Certificate renewal

When an X.509 certificate is created, you shall define the validity period. The recommended validity period of a device certificate has dramatically changed in the last years. While in the past a validity period of 10 years was acceptable with the main purpose to decrease the operational effort to renew it, nowadays because of the tremendous increase in cyber attacks, it is widely recognized by security experts that validity should not exceed 1 year, even for businesses that are not dealing with sensitive data. Regulation authorities are now moving to even shorter periods, close to 3 months, to further improve security levels.

With these recommendations, constantly extending the certificate validity on each device is a tremendous effort that cannot be addressed manually even for small fleets of hundreds of devices with a validity period of 12 months.

With IoT Certificate Manager you can:

  • extend the validity period, once, for all devices listed using the /ztp/devicecertificate/renew API. The new certificate, with an extended lifetime, will have a new serial number, keeping the same Common Name

  • Extend the validity period automatically before the expiration, by setting the proper option in the /ztp/rootca/create API when creating the Root CA or updating the setting at a later stage with /ztp/rootca/update API. Remember that the renewal happens at the next Security heartbeat of the device.

Note: with renewal the new certificate use the same key pair (private and public keys, that are unique for each device) generated during the initial Zero Touch Provisioning. If you also want to replace the key pair, you need to update the certificate as explained in the next section.

The certificate renewal API implements generation, signature and provisioning in the device of the new certificate. If you are using Azure or AWS and the configurations suggested in our guides, the re-provisioning of the new certificate in those platforms happens automatically at every renewal without the need to implement any additional logic.

The previous certificate is automatically removed from the device but not from the IoT platform.

Each certificate renewal is counted as a billing event, only when the renewal effectively happens in the device, and is charged accordingly to your plan.

Note: if you need to manually force the certificate renewal triggering a security heartbeat on the device (after having issued the /ztp/devicecertificate/renew), it is suggested to wait at least 5 mins before checking the new certificate because of the protection mechanism implemented to prevent flooding (see Security Heartbeat section on Getting started guide)

Update certificate

If your device certificate has been compromised or you want an enhanced level of security, you can update the device certificate with /ztp/devicecertificate/update API that triggers the automatic generation of:

  • the new keypair (private and public key)

  • the device certificate generation and signing

  • the device certificate provisioning in the device

The API can be applied to a list of devices at the same time, and triggers the whole re-provisioning process as described for certificate renewal.

Note: the update procedure needs two Security Heartbeat. The new certificate is provisioned after the second Heartbeat

Note: as for the certificate renewal it is suggested to wait at least 5 mins , before checking the new certificate, in case you need to manually force the certificate renewal with a a security heartbeat on the device(see Security Heartbeat section on Getting started guide)

Each certificate update is counted as a billing event, only when the update effectively happens in the device, and is charged accordingly to the selected plan.

Delete certificate

If you no longer need the certificate in the device, you can maintain security by removing it for free, using the /ztp/devicecertificate/delete API.

NOTE: this action does not remove the certificate from the IoT platform (Azure, AWS, etc.).

Replace Root CA certificate

There are some use cases where it is necessary to replace the Root CA certificate used to sign the device certificate. For example:

  • if the Root CA certificate has been compromised

  • you are moving devices from test environment to production environment and you prefer to use different Root CA certificates for each environment

  • the ownership of the device changes

  • you are moving a device to a different IoT Platform

This action can be extremely complex and time consuming if performed on a significant number of devices, or when continuously done as part of a test-deployment process, because you need to repeat the whole process of certificate generation, signing and provisioning.

By using the /ztp/devicecertificate/rootca/transfer API you can automate the entire procedure specifying the list of devices (using the RoTPublicUID identifier) that needs to be moved.

Each certificate transfer is counted as a billing event, only when the transfer effectively happens in the device, and is charged accordingly to the selected plan.

Certificate revocation

Certificate revocation is the action of invalidating the certificate before the scheduled expiration date so that it can no longer used by the device for authentication and (D)TLS sessions. A certificate should be revoked immediately when its private key shows signs of being compromised. It should also be revoked when the domain for which it was issued is no longer operational.

If you are using the certificate in sensitive business applications you may want a way to revoke that certificate to invalidate it immediately if you have the feeling that it is misused.

To revoke a certificate

  • use the /ztp/devicecertificate/revoke to invalidate it on Thingstream platform and and trigger its addition to the Revocation list (CRL)

  • disable the certificate on your IoT platform

NOTE: certificate revocation does not remove the certificate in the device. This action can be performed using the previously described API.

Certificate revocation is not charged.

Certificate Revocation List

A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. CRL is a sort of backlist for certificates and is used by various endpoints (for example your IoT platform) to verify whether a certificate is valid and trustworthy.

You can use the /ztp/rootca/crl/get API to get a list of the certificates revoked using the certificate revocation API.

CRL is not subject to charging


To keep device certificate lifecycle status under control you can subscribe to the main events, like certification expiration and renewal, using the dedicated webhook /notification/webhook/create.

Notifications are not subject to charging


Invoices are raised on the 1st of each month and will include usage for any services configured via the Thingstream platform. Only completed subscriptions will be included so a plan which starts on 5th May, renewing on 5th June, would be included in the invoice raised on 1st July. Any usage from the renewed plan would not be invoiced until 1st August.

Invoices are sent by email from Please add this address to your safe senders list to avoid invoices being lost in your junk folder.


IoT certificate manager service is available from the following FW version an subsequent releases:

  • SARA-R500S-01B-00

  • SARA-R510S-01B-00

  • SARA-R510M8S-01B-00

  • ALEX-R510M8S-01B-00

Reference documentation