Secure device provisioning
How to bring new machines online with Things5 securely, in line with the Cyber Resilience Act
This guide is for manufacturers of machines and IoT modules, and for the developers of their firmware and end-of-line test stations. It explains how to connect a new machine to Things5 securely, in line with the EU Cyber Resilience Act (CRA).
Why it matters
Every machine connects to Things5 with its own certificate and private key. How the key reaches the device and how it is stored there is part of the product's security, and therefore of its CRA compliance, which remains the responsibility of the machine manufacturer.
Things5 is a general-purpose cloud service offered to many manufacturers: under the CRA it is a third-party component of your product, not something developed under your responsibility. This guide gives you what you need to assess Things5 as a supplier and to choose how to bring your machines online.
The CRA does not prescribe how keys are distributed, but it requires you to protect the confidentiality of credentials and to limit the attack surface. The two provisioning flows described below are the ones we recommend.
Who does what
| Area | Machine or module manufacturer | visup (Things5) | Organization using Things5 |
|---|---|---|---|
| Firmware and hardware | Secure development, security updates, SBOM, product vulnerability handling | — | — |
| Private key on the device | Safekeeping after delivery: protected storage, never exposed in logs or debug output | Generation and one-time delivery over an encrypted channel | — |
| Certificates | — | Issuing, binding certificate to machine, revoking the previous certificate when a new one is issued | — |
| Provisioning | Implement one of the recommended flows in the firmware or test station | Provide and maintain the flows, with server-side limits and checks | Decide who can bring machines online (roles, groups) |
| Cloud platform | Assess Things5 as a supplier | Infrastructure security, access control, encryption in transit | Manage users, roles and API integrations |
| Vulnerabilities | Report to ENISA/CSIRT for your own product | Fix platform vulnerabilities and notify affected customers | Report anomalies and suspicious activity to visup |
Things5 does not keep private keys
Things5 generates the private key and delivers it to the device once. It does not store it and cannot recover it. If a device loses its key, a new certificate is issued and the previous one stops working.
Provisioning flows
Provisioning is the step that turns a new device into a machine on Things5: the machine is registered, and the device receives the certificate, the private key and the CA certificate it needs to connect to the Things5 MQTT broker. It happens once per machine, and again only if its certificate has to be replaced.
A provisioning flow is the procedure that gets the certificate and key onto the device. Things5 supports two:
- Pairing code: a person enters on the device a short code generated in Things5, and the device downloads its certificate directly from Things5.
- Factory station: a station on the production line creates the machine through the API, gets its certificate and loads it onto the device.
Choosing a flow
| Pairing code | Factory station | |
|---|---|---|
| Who acts | A person, one device at a time | Software through the API, no operator on the device |
| What the device needs | A way to enter and show a code (display, configuration app) | A channel to receive certificates from the station (USB, serial, Bluetooth) |
| How the key travels | Straight from Things5 to the device, over HTTPS | From Things5 to the station, then from the station to the device |
| Credentials | None, neither on the device nor anywhere else | On the station: a dedicated API integration, never a person's credentials |
| Where the machine ends up | In the organization of whoever generated the code | In the Testing group, then moved to its destination group |
| Volume | One at a time | Batches, can be automated |
| Where | Anywhere, in the field or on the production line | Factory only |
| Repeating it after delivery (lost key, replaced board) | Yes, in the field: an authorized user generates a new code, even remotely, and it is entered on the device. The machine does not have to be returned | Not in the field: the device has to go back to a station |
| What the manufacturer builds | Code entry and display in the firmware or app | The station software, the loading channel and the station's protection |
The pairing code is the recommended flow
From a security standpoint it is the best option, and this is why we recommend it: the private key goes straight from Things5 to the device over HTTPS and never passes through any other computer. It also asks less of the manufacturer, and the end user can repeat it in the field if the device ever needs a new certificate.
The factory station is also secure, but the certificate and private key necessarily pass through a third system, the station, before reaching the device. That is why the station has to be protected, and why we suggest it only when volumes make manual entry impractical or the device has no user interface.
The two flows can be combined. Even if you use a factory station in production, it is good practice to also support the pairing code in the firmware: it is the only way to restore a device in the field, for example after a board replacement, without sending it back to the factory.
Practices to avoid
Never put Things5 API credentials on a device
Neither a user's username and password nor an API integration's secret, not even temporarily during production with the plan of deleting them afterwards. The device only needs its own certificate and private key.
Credentials on a device can be extracted: from the firmware image, from memory, or from a copy left behind in storage after deletion. Whoever extracts them gets every permission of that user or integration, not just on that machine. If the same credentials have been used on several devices, the access covers all of them.
On a station, use an API integration, never a user's credentials.
Avoid downloading certificates from the browser and copying them by hand
The private key passes through a PC that is neither the device nor a protected station, and copies may remain there (downloads folder, backups, email). Use this only in exceptional cases such as repairs or replacements, and delete the downloaded file as soon as it has been transferred.
Personal credentials for the API
Some systems currently access the Things5 API with a user's username and password. For stations and integrations these must be replaced with API integrations:
| Date | What happens |
|---|---|
| December 1, 2026 | API users can no longer be created. Existing API users keep working; affected organizations will be contacted |
| June 30, 2027 | Existing API users are no longer supported: API access with username and password is switched off |
References
- Regulation (EU) 2024/2847 (Cyber Resilience Act): Art. 13(5) (due diligence on third-party components); Annex I, Part I, point 2(e) and (j) (data confidentiality, attack surface).
- Commission guidelines C(2026) 5252 of July 27, 2026.
- ETSI EN 303 645 (consumer IoT security); EN 18031 (Radio Equipment Directive security requirements).
This guide describes visup's position and the flows supported by Things5; it is not a conformity assessment of your products.
Contacts
For technical support with the integration and for security reports, write to [email protected].
Updated about 4 hours ago