The European Cyber Resilience Act is on its way. The first obligations apply from September 2026, and the full law takes effect in December 2027. This has an impact on every IoT device and platform.
- Products must be secure-by-design. Cybersecurity must be an integral aspect during development, not patched in after the fact.
- Discovered vulnerabilities must be reported to ENISA, the European cybersecurity agency, within 24 hours.
- Manufacturers are required to release security updates free of charge and in a timely manner for a minimum product lifetime of 5 years.
- These updates must themselves be secure. This includes the use of cryptographic signatures to verify the origin and integrity of an update before it is applied.
- Manufacturers must produce an SBOM, a Software Bill of Materials. This is a list of all software components and libraries used.
Device Identity
Many IoT products rely on shared secrets. For example, a single API token or password used by all devices. Most people now understand that reusing passwords across websites is a risk. The same applies to IoT devices: if the secret leaks via one device, every other device is immediately at risk. Yet there are still manufacturers who are too lax about this.
What can an attacker do with a stolen shared secret?
- Impersonate any device in the fleet
- Send falsified measurement data that decisions are based on
- Flood the network with legitimate-looking traffic (DoS from the inside)
But the biggest problem is the asymmetry. The attacker can do a lot, while the manufacturer can do almost nothing about it except rotate the shared secret. Every device needs new firmware for that: over-the-air, or perhaps even a physical recall. If you have 4,000 devices spread across Europe, that is a serious problem.
How should it be done?
The solution is well-known and has existed in the embedded world for a long time. Each device has its own cryptographic identity: a unique certificate with a corresponding private key, securely stored on the device. This is the architecture the CRA enforces in practice, even if it isn't spelled out literally in the law.
Despite all precautions, a certificate and private key can still end up in the hands of an attacker. But in this case the impact is fundamentally different:
- Only that one device is compromised
- The attacker can only impersonate that specific device
- For each additional device the attacker has to start over physically, which scales poorly
And the response does scale. As soon as the breach is known, the manufacturer revokes the certificate and that one device is cut off from the cloud. A surgical intervention of seconds, instead of a fleet-wide firmware update.
An additional benefit: once each device has its own certificate, that same certificate can also be used to encrypt the communication. Authentication and encryption become a single integrated mechanism. This is what the CRA explicitly requires under Annex I.
How we implement this on the Jitter Platform
The building blocks of our platform already meet a large part of the CRA's requirements. Like many IoT systems, we use MQTT as the protocol for communication between devices and the cloud. This communication is facilitated by an MQTT Broker. Both the device and the server application log in to the broker. The broker decides who gets to see which messages.
Provisioning: identity at birth
Each device is assigned a UID (Unique Identifier). We print it together with a barcode on a label that is physically applied to the device. The UID acts as a unique key to find the device in the database. Next, we generate an X.509 client certificate with the UID as its Common Name. This certificate, together with the corresponding private key, is securely programmed into the microcontroller. This step is called provisioning.
Runtime: mutual TLS
The broker also has its own X.509 server certificate. As soon as a device connects, the broker authenticates the device. The device in turn verifies that the broker is authentic. This way, an encrypted connection is established. This is called mutual TLS (mTLS), because both sides authenticate each other.
The broker then uses the Common Name of the client certificate as the username within the MQTT protocol. Each username may be logged in only once at a time. If a certificate were copied, the cloned device cannot quietly run alongside the original undetected.
When a device needs to be isolated, its certificate is blocked at the broker. From that moment on, every connection attempt is rejected.
Foundation of trust: the Root CA
A valid client certificate can cryptographically only be issued by whoever holds the private key of the Certificate Authority (CA). That key is kept safe by the manufacturer: by us, or by customers of our platform who want to manage this themselves. The corresponding root certificate is public and is baked into every device, so that the device can verify the chain when establishing a connection.
With this setup, three of the CRA essentials are directly addressed: protection against unauthorized access, confidentiality of data in transit, and the ability to isolate individual devices in case of an incident.
Case study: Frogwatch
An example of this architecture in practice is Frogwatch: a vibration monitoring platform for the construction and infrastructure sector that we have been developing since 2017. Sensors are placed on public construction sites, communicate with the cloud over 4G/LTE, and deliver measurement data used for SBR compliance.
The first generation (2017) used a per-sensor password over TLS. For the second generation (2023/2024) that has been replaced by X.509 certificates and mTLS, as described above.
The same setup (broker with mTLS, X.509 client certificates per device, provisioning and revocation) is available as a building block in the Jitter Platform, so that manufacturers don't have to build this foundation themselves.
UID labels and barcodes visible on Frogwatch sensors.
What this means for a manufacturer
For manufacturers of connected products, the CRA means that security must be considered from the very first design decision onwards, not as an afterthought. Cutting corners or temporarily choosing a less secure route to save time no longer pays off: anything you skip now will cost you time and reputation later. Whoever lays the foundation correctly once can reuse it in every subsequent product.
In concrete terms:
- Less work for compliance: if your platform already complies, you don't have to demonstrate secure-by-design from scratch for each product
- Faster time to market: the security foundation is already in place; you build on top of it
- Lower risk during incidents: revoking a single device only takes a few minutes