Volgend jaar gaat de Europese Cyber Resilience Act (CRA) in. De eerste verplichtingen gelden vanaf september 2026, de hele wet vanaf december 2027. De wet stelt eisen aan de cyberveiligheid van vrijwel elk connected product dat in Europa op de markt komt.
Belangrijk om te realiseren is dat de wet vooral het resultaat voorschrijft. De wet zegt wát er moet gelden, hoe je dat technisch oplost is aan jou als fabrikant. Dat geeft ruimte, maar het betekent ook dat je de vertaalslag van eis naar architectuur zelf moet maken. En het liefst vanaf de eerste ontwerpbeslissing.
In dit artikel kijken we naar drie concrete eisen uit de wet.
1. Firmware-updates moeten veilig zijn
Allereerst wordt het verplicht om een mechanisme te hebben voor firmware-updates, zodat je gevonden kwetsbaarheden zo snel mogelijk kunt patchen.
Maar zo'n update mag er niet zomaar naartoe gestuurd worden. Het apparaat moet zowel de authenticiteit als de integriteit van de update kunnen controleren voordat het die installeert.
Wat is het verschil tussen authenticiteit en integriteit?
Authenticiteit: je wil zeker weten dat de update afkomstig is van een betrouwbare bron. Dus van jou als fabrikant, en niet van iemand anders.
Integriteit: je wil zeker weten dat de update onderweg niet beschadigd is geraakt of gemanipuleerd is door een kwaadwillende.
Het zijn twee verschillende garanties. Een update kan van de juiste bron komen en toch onderweg beschadigd raken. Of perfect intact aankomen terwijl hij van een aanvaller komt. Je hebt ze allebei nodig.
Hoe je dat oplost, bijvoorbeeld met cryptografische handtekeningen, dat schrijft de wet niet voor. De wet schrijft het resultaat voor. Hoe dat technisch opgelost wordt, dat is aan de fabrikant.
2. Het spanningsveld tussen dataminimalisatie en logging
De tweede eis is eigenlijk een combinatie van drie eisen die met elkaar schuren. Juist daarom is dit interessant om goed over na te denken bij je systeemarchitectuur.
Dataminimalisatie: verzamel alleen de gegevens die je écht nodig hebt voor de functie van je product. (CRA Annex I Part 1 (2)(g))
Logging: monitor relevante activiteit, inclusief toegang tot of wijzigingen van data, services of functies. (CRA Annex I Part 1 (2)(l))
Opt-out: voor die logging moet de gebruiker bovendien een opt-out hebben. Hij mag de monitoring uitzetten. (CRA Annex I Part 1 (2)(l))
Zie je het spanningsveld? Aan de ene kant wil de wet dat je zo min mogelijk verzamelt. Aan de andere kant wil de wet dat je relevante activiteit logt. En vervolgens mag de gebruiker dat loggen ook nog uitzetten.
Dit los je niet achteraf op. Wat is "relevante" activiteit? Welke logging is beveiliging en welke is overbodige dataverzameling? En hoe bouw je een opt-out die de gebruiker respecteert zonder het apparaat onveilig te maken? Dat zijn ontwerpkeuzes die je vooraf moet maken.
3. De SBOM: weten wat er in je product zit
De derde eis is dat softwareleveranciers een SBOM moeten gaan bijhouden.
Hardwarebouwers kennen de Bill of Materials (BOM) goed: een lijst van alle onderdelen in een product. Een SBOM (Software Bill of Materials) is precies datzelfde idee, maar dan voor software. Een complete lijst van alle softwarecomponenten die in je product zitten.
En "complete" is het sleutelwoord. Het gaat om alle metadata, auteurs, licenties en versies. En ook om de onderliggende afhankelijkheden, de hele boom tot onderin.
Waarom?
Stel: morgen wordt er een kwetsbaarheid ontdekt in een veelgebruikte library. De vraag die je dan binnen een minuut wil kunnen beantwoorden is: zit die in een van mijn producten?
Mét een goede SBOM is dat een enkele CTRL-F.
Zonder SBOM begint op dat moment een zoektocht door je hele codebase en die van al je afhankelijkheden. Met een SBOM heb je het antwoord al voordat die zoektocht begonnen is.
Tot slot
De wet zegt wát er moet gelden: een veilige update, zorgvuldige omgang met data, en inzicht in je softwarecomponenten. Hóe je dat invult, bepaal je zelf.
Dat is precies waarom de CRA vraagt om vanaf de eerste ontwerpbeslissing over veiligheid na te denken. Wie de vertaalslag van eis naar architectuur vooraf maakt, heeft er bij elk volgend product profijt van.