Device certificates and signed updates: how the edge box identifies and protects itself
Every box has its own certificate whose key never leaves the box. It only accepts updates if the signature is valid, the version is newer and the package arrives unaltered.
A device that is attached to a machine tool on your network and sends data to the outside must be able to answer two questions reliably: who am I, and is the software running on me really the manufacturer's? The first question is answered by a device certificate, the second by signed updates. Both are among the basic requirements that IEC 62443 and the Cyber Resilience Act place on networked components. This article shows how we have implemented device certificates and signed updates in our edge box, which algorithms we use and what is still open today.
Why every box needs its own identity
Our box sends features to the platform. Anyone who holds a box's identity can send data in its name. They could therefore inject false measurements or mask a genuine alarm. In the threat model of our system, the device keys are therefore an asset in their own right.
A shared password for all boxes would be the worst approach: once it is known, every device is affected. Instead, we work without password login. Every box has its own certificate containing its device ID. If a device is compromised, exactly that one device is affected.
The private key is generated on the box
The most important rule is: a box's private key never leaves the box. It is not generated by us and not transferred by USB stick or laptop. The process is therefore split into three parts:
- On the box: a command generates a key using EC P-256. The key file is readable only by the box user. An existing key is never overwritten. From the key, a certificate signing request (CSR) is created with the device ID as its name.
- At Forbach: only this request comes to us. It contains the public key but nothing secret. We sign it with our device CA.
- Back on the box: the signed certificate is stored on the box. From now on the box can identify itself to our broker.
A dedicated device CA with strict rules
Our boxes' certificates are issued by a dedicated certificate authority, the device CA. It runs offline on a computer at Forbach, never on a publicly reachable server. Its key is an EC P-384 key, protected by a passphrase of at least twelve characters. Before the CA signs a request, it checks four things:
| Check | Purpose |
|---|---|
| The request's signature is valid | The request comes from the owner of the key and was not altered in transit. |
| The name in the request is exactly the device ID | A box cannot request a certificate for another box. |
| The box is registered on the platform | Unknown devices do not receive a certificate. |
| Validity of at most two years, one year by default | A certificate is renewed regularly and is not valid indefinitely. |
The issued certificate may be used exclusively for client authentication. It can neither sign other certificates nor identify a server. So that renewal is not forgotten, the box regularly checks the remaining validity of its certificate and reports a warning to the platform from 30 days before expiry.
Mutual TLS between box and platform
The box sends its features via MQTT over TLS, version 1.2 at minimum, and always opens the connection itself, from inside to outside. Both sides verify each other:
- The box verifies the server. It only trusts a server certificate that matches the stored certificate authority. A peer posing as our platform is rejected.
- The broker verifies the box. For devices it trusts exclusively our device CA. A certificate from any other source is not sufficient.
Beyond that, the platform alone decides, based on its device registry, which customer a box belongs to. A box cannot assign itself to another customer, and data for someone else's machine is discarded. You can read more about the transmission itself in the article OPC UA or MQTT for production data.
Towards the CNC control, too, the box has its own certificate. It is likewise generated on the box and entered manually on the control as trusted. For comparison, the box displays its SHA-1 and SHA-256 fingerprints. The details are in the article Read-only: write protection for the CNC control.
Blocking a device
If a box is lost or there is a suspicion that it has been tampered with, it must be possible to exclude it immediately. Today this is done in two steps: the box is removed from the platform's device registry, after which the platform no longer accepts data from it. In addition, its access to the broker is revoked. Because every box has its own certificate, blocking affects only that one device; all others keep working.
Honest status
A certificate revocation list (CRL) and automatic renewal have not yet been implemented. Renewal is currently a scheduled, manual process: new request, signing, replacing the file. With a larger number of boxes we plan automatic renewal. We are also reviewing the access rules on the production broker separately before the first boxes go into field use.
Signed updates: what the box checks
All software needs updates, particularly for security reasons. But an update is also a way in: anyone who can inject a manipulated package has taken over the box. That is why our box only accepts an update if it passes a chain of checks.
Every update comes with a manifest. It states the version, file name, SHA-256 checksum and size of the package, a validity period, the oldest version from which a direct update is permitted, and whether it is a security update. This manifest is signed with an Ed25519 key. The exact bytes are signed; changing even a single character invalidates the signature.
Some of these steps deserve an explanation:
- Keys stored on the box: the public keys the box trusts are stored permanently on the box. There can be several, so that we can rotate a key in a planned way. The private signing key is kept offline by us and protected by a passphrase.
- No rollback: the box permanently remembers the highest version it has ever accepted. An old, genuinely signed manifest with a known vulnerability therefore cannot be replayed, even after a restart.
- Expiry date: a manifest is valid for 30 days by default. This means an attacker cannot keep presenting an old manifest to the box indefinitely and suppress new updates.
- Re-check: time may pass between download and installation. The staged package is therefore fully checked again immediately before installation.
What the box does if the signature is invalid
If any of the checks fails, the box discards the update. It stages nothing, installs nothing and continues running its current version unchanged. At the same time it reports the rejection, with a reason, as an event to the platform, for example “signature invalid”, “version not newer” or “checksum mismatch”. This lets us see immediately if someone attempts to install a manipulated package, or if a download arrives corrupted.
The box itself never installs anything. It only downloads outbound, checks and stages. The actual installation is carried out by a separate service on the box's computer, which only accepts checked packages and runs the re-check beforehand. This separation ensures that the software that talks to the internet needs no rights to replace programs.
Honest status
Verification of signed updates on the box has been implemented and is backed by tests for manipulated manifests, unknown keys, expired manifests, rollbacks and altered packages. The installer and the server for the update files depend on the choice of box hardware and will follow before series operation.
Why this matters for IEC 62443 and the Cyber Resilience Act
Device certificates and signed updates are not optional extras; they are explicitly required. IEC 62443-4-2 requires, among other things, that devices and software processes identify themselves unambiguously, that certificates are validated correctly and that the authenticity of software can be verified. For our box we are aiming for security level SL-C 2, i.e. protection against intentional attacks using simple means. In Annex I, the Cyber Resilience Act requires security updates, protection against unauthorised access, the integrity of programs and data, and mechanisms for distributing updates securely.
| Requirement | Implementation in our system |
|---|---|
| IEC 62443-4-2 CR 1.2: unique device identification | Own certificate per box, name equal to device ID |
| IEC 62443-4-2 CR 1.8 and 1.9: certificates and public key methods | Dedicated device CA, mutual TLS, limited validity |
| IEC 62443-4-2 CR 3.4: integrity and authenticity of software | Ed25519-signed manifest, SHA-256 checksum, no rollback |
| CRA Annex I Part I (2c): security updates | Signed updates with a flag for security updates |
| CRA Annex I Part I (2d): protection against unauthorised access | Login only with device certificate, no password |
The questions you as an operator should ask every supplier about this are described in the article Cyber Resilience Act and condition monitoring. An overview of all protective measures is on the Data security page. If your IT team has questions before a pilot project, contact us via the contact page.
Frequently asked questions
Where is the private key of the device certificate generated?
Directly on the box. Only the certificate signing request with the public key comes to us. The private key never leaves the box, not even during set-up.
How long is a device certificate valid?
One year by default, two years at most. From 30 days before expiry, the box reports a warning to the platform so that the certificate is renewed in good time.
What happens if an update has been manipulated?
The box detects this from the invalid signature or the mismatched checksum, discards the update and continues with its current version. The rejection is reported to the platform with a reason.
Can a lost box be blocked?
Yes. The box is removed from the device registry, after which the platform no longer accepts data from it, and its access to the broker is revoked. Because every box has its own certificate, other boxes are not affected.
Does the box need an inbound connection for updates?
No. The box downloads updates exclusively outbound via https. It accepts no connections from outside.
About the author
Sascha P. Forbach is the founder of Forbach & Partners and the software architect of its spindle monitoring system. For twelve years he has advised manufacturers on process quality and machine availability. About us