De Europese Cyber Resilience Act komt eraan. Vanaf september 2026 gelden de eerste verplichtingen en in december 2027 gaat de gehele wet van kracht. Dit heeft impact op alle IoT apparaten en platforms.
- Producten moeten secure-by-design zijn. Tijdens de ontwikkeling moet cyber-veiligheid een integraal aspect zijn. Dus niet achteraf nog even alle gaten afdichten.
- Gevonden lekken moeten binnen 24 uur gemeld worden bij ENISA, de Europese organisatie voor cybersecurity.
- Fabrikant is verplicht om kosteloos en tijdig beveiligingsupdates uit te brengen gedurende een minimale levensduur van het product van 5 jaar.
- Deze updates moeten veilig zijn. Dit omvat het gebruik van cryptografische handtekeningen om de herkomst en integriteit van de update te verifiëren voordat deze wordt toegepast.
- De fabrikant moet verplicht een SBOM opstellen, dit is een Software Bill of Materials. Dit is een lijst van alle gebruikte softwarecomponenten en libraries.
Device Identity
Veel IoT producten gebruiken gedeelde geheimen. Bijvoorbeeld één API token of één wachtwoord dat door alle apparaten gebruikt wordt. Veel mensen begrijpen inmiddels dat het hergebruiken van wachtwoorden over verschillende websites een risico is. Hetzelfde geldt voor IoT apparaten: als het geheim via één apparaat uitlekt, zijn meteen alle andere apparaten in gevaar. Toch zijn er nog steeds fabrikanten die hier te laks in zijn.
Wat kan een aanvaller met een gestolen gedeeld geheim?
- Zich voordoen als élk apparaat in de vloot
- Vervalste meetdata sturen waar beslissingen op gebaseerd worden
- Het netwerk overspoelen met legitiem-ogend verkeer (DoS van binnenuit)
Maar het grootste probleem is de asymmetrie. De aanvaller kan heel veel terwijl de fabrikant er bijna niets tegen kan doen behalve het gedeelde geheim roteren. Elk apparaat heeft hiervoor een nieuwe firmware nodig, over-the-air of misschien zelfs een fysieke recall. Stel je hebt 4000 apparaten verspreid over Europa, dan is dat een groot probleem.
Hoe moet het dan wel?
De oplossing is bekend en bestaat al lang in de embedded wereld. Elk apparaat heeft zijn eigen cryptografische identiteit: Een uniek certificaat met bijbehorende private key, veilig opgeslagen op het apparaat. Dit is de architectuur die de CRA in de praktijk afdwingt, ook al staat het er niet letterlijk zo in de wet.
Ondanks alle voorzorgsmaatregelen kan een certificaat en private key nog steeds in handen van een aanvaller komen. Maar de impact is in dit geval fundamenteel anders:
- Alleen dat ene apparaat is gecompromitteerd
- De aanvaller kan zich uitsluitend voordoen als dat specifieke apparaat
- Voor elk volgend apparaat moet de aanvaller opnieuw fysiek aan de slag, wat slecht schaalt
En de respons schaalt wél. Zodra de inbreuk bekend wordt, trekt de fabrikant het certificaat in en is dat ene apparaat afgesneden van de cloud. Een chirurgische ingreep van seconden, in plaats van een fleet-wide firmware update.
Een bijkomend voordeel: zodra elk apparaat een eigen certificaat heeft, kan datzelfde certificaat ook worden gebruikt om de communicatie te versleutelen. Authenticatie en versleuteling worden zo één geïntegreerd mechanisme. Dit is wat de CRA expliciet vraagt onder Annex I.
Hoe wij dit invullen op het Jitter Platform
De bouwblokken van ons platform voldoen voor een groot deel al aan de eisen van de CRA. Zoals veel IoT systemen gebruiken we MQTT als protocol voor de communicatie tussen de apparaten en de cloud. Deze communicatie wordt gefaciliteerd door een MQTT Broker. Zowel het apparaat als de serverapplicatie loggen in bij de broker. De broker bepaalt wie welke berichten te zien krijgt.
Provisioning: identiteit bij geboorte
Elk apparaat krijgt een UID (Unique Identifier) toegewezen. Die printen we samen met een barcode op een label, dat fysiek op het apparaat wordt geplakt. De UID dient als uniek kenmerk om het apparaat in de database te vinden. Vervolgens genereren we een X.509 client-certificaat met de UID als Common Name. Dit certificaat wordt samen met de bijbehorende private key veilig in de microcontroller geprogrammeerd. Deze stap heet Provisioning.
Runtime: mutual TLS
De broker heeft zelf ook een X.509 servercertificaat. Zodra het apparaat verbinding maakt authenticeert de broker het apparaat. Het apparaat verifieert op zijn beurt dat de broker echt is. Op deze manier wordt een versleutelde verbinding opgezet. Dit heet mutual TLS (mTLS), omdat beide kanten elkaar authenticeren.
De broker gebruikt de Common Name van het clientcertificaat vervolgens als gebruikersnaam binnen het MQTT-protocol. Elke gebruikersnaam mag maximaal 1 keer tegelijk ingelogd zijn. Als een certificaat zou worden gekopieerd, kan het gekopieerde apparaat niet ongemerkt náást het origineel meedraaien.
Wanneer een apparaat moet worden geïsoleerd, wordt het certificaat geblokkeerd op de broker. Vanaf dat moment wordt elke verbindingspoging geweigerd.
Vertrouwensbasis: de Root CA
Een geldig clientcertificaat kan cryptografisch alleen worden uitgegeven door wie de private key van de Certificate Authority (CA) bezit. Die key wordt veilig bewaard door de fabrikant: door ons, of door klanten van ons platform die dit zelf willen beheren. Het bijbehorende rootcertificaat is publiek en zit ingebakken in elk apparaat, zodat het de keten kan verifiëren bij het opzetten van de verbinding.
Met deze opzet zijn drie van de CRA-essentials direct ingevuld: bescherming tegen ongeautoriseerde toegang, vertrouwelijkheid van data in transit, en de mogelijkheid om individuele apparaten te isoleren bij een incident.
Case Study: Frogwatch
Een voorbeeld van deze architectuur in de praktijk is Frogwatch: een trillingsmonitoringplatform voor de bouw- en infrasector dat we sinds 2017 ontwikkelen. Sensoren staan op publieke bouwlocaties, communiceren via 4G/LTE met de cloud, en leveren meetdata die gebruikt wordt voor SBR-compliance.
De eerste generatie (2017) gebruikte een eigen wachtwoord per sensor over TLS. Voor de tweede generatie (2023/2024) is dat vervangen door X.509-certificaten en mTLS, zoals hierboven beschreven.
Dezelfde opzet (broker met mTLS, X.509 client-certificaten per device, provisioning en revocation) is als bouwblok beschikbaar in het Jitter Platform, zodat fabrikanten deze basis niet zelf hoeven op te bouwen.
UID labels en barcodes te zien op Frogwatch Sensoren.
Wat dit voor een fabrikant betekent
Voor fabrikanten van connected producten betekent de CRA dat veiligheid voortaan vanaf de eerste ontwerpbeslissing meegenomen moet worden, niet als sluitstuk. De kantjes ervan af lopen of "tijdelijk" een minder veilige route kiezen om tijd te winnen, loont niet meer: alles wat je nu overslaat, kost later tijd én reputatie. Wie het fundament één keer goed legt, kan dat in elk volgend product hergebruiken.
Concreet:
- Minder werk voor compliance: als je platform al voldoet, hoef je niet voor elk product opnieuw aan te tonen dat het secure-by-design is
- Sneller op de markt: het beveiligingsfundament is al klaar; je bouwt erbovenop
- Lagere risico's bij incidenten: één device intrekken kost slechts enkele minuten