Cyber Resilience Act
In het IoT-hoofdstuk zag je het probleem al: een slimme camera of router gaat vlot tien jaar mee, maar de fabrikant stopt vaak na een paar jaar met updates (of bestaat gewoon niet meer). Default wachtwoorden, onnodige netwerkservices en verouderde bibliotheken waren jarenlang de norm, omdat niemand de fabrikant er iets over kon zeggen. Wie een onveilige broodrooster verkocht, riskeerde niets.
De Cyber Resilience Act (CRA) maakt daar een einde aan. Het is een Europese verordening (EU 2024/2847) die de fabrikant verantwoordelijk maakt voor de cyberveiligheid van zijn product, en dat gedurende de hele levensduur ervan. Waar NIS2 kijkt naar de organisaties in kritieke sectoren, kijkt de CRA naar de producten die we kopen.
Voor welke producten?
De CRA geldt voor alle producten met digitale elementen die op de Europese markt komen: hardware en software die (rechtstreeks of onrechtstreeks) met een toestel of netwerk verbonden kan worden. Dat gaat van babyfoons en smartwatches tot apps, besturingssystemen, routers, firewalls en industriële sturingen (Europese Commissie).
Een paar zaken vallen erbuiten, omdat daar al eigen regels voor bestaan: medische hulpmiddelen, auto’s, luchtvaart en scheepsuitrusting, en producten die enkel voor defensie of nationale veiligheid gemaakt worden. Ook pure clouddiensten (SaaS) vallen er in principe niet onder: die worden eerder door NIS2 gevat.
De meeste producten (denk aan een slimme speaker of een gewone app) mag de fabrikant zelf beoordelen: hij controleert zelf of zijn product aan de eisen voldoet en verklaart dat officieel. Voor gevoeligere producten gelden strengere procedures, waarbij een onafhankelijke, door de overheid erkende instantie (een aangemelde instantie) mee moet controleren:
- Belangrijke producten, klasse I: onder meer wachtwoordmanagers, browsers, VPN’s, antimalware, routers en switches, besturingssystemen en slimme-huisproducten zoals deursloten en camera’s.
- Belangrijke producten, klasse II: onder meer firewalls en inbraakdetectiesystemen, hypervisors en tamper-resistant microprocessoren.
- Kritieke producten: onder meer smartcards, secure elements en hardware security modules (HSM’s).
Voldoet een product aan de CRA, dan mag de fabrikant er een CE-markering op aanbrengen, net zoals een elektrisch toestel dat vandaag al moet voor elektrische veiligheid. Met die markering verklaart de fabrikant zelf dat zijn product aan alle Europese eisen voldoet. Het is dus geen keurmerk dat je van een overheid “krijgt”.
Ook open source zit in het verhaal, maar met een uitzondering. Een hobbyproject op GitHub dat je gratis deelt, valt er niet onder. Wie echter open-source software in een commercieel product verwerkt, is als fabrikant wél verantwoordelijk voor de veiligheid van die componenten. Voor stichtingen die open-source projecten structureel ondersteunen (de open-source software stewards) geldt een lichter regime, zonder boetes.
Wat moet de fabrikant doen?
De verplichtingen staan in bijlage I van de verordening. Je zal er heel wat OWASP IoT Top 10-problemen in terugzien, maar dan omgedraaid tot wettelijke eis:
- Geen gekende uitbuitbare kwetsbaarheden bij het op de markt brengen.
- Security by default: het product komt uit de doos met een veilige standaardconfiguratie, en je moet het kunnen resetten naar die toestand. Een toestel dat geleverd wordt met hetzelfde wachtwoord
admin/adminvoor elke klant, kan je moeilijk veilig noemen. - Beperkt aanvalsoppervlak: geen onnodige poorten en services (denk aan de printers met een open poort 9100 uit het IoT-hoofdstuk).
- Bescherming van data: vertrouwelijkheid en integriteit, onder meer via encryptie, in rust én tijdens transport. De McCumber kubus in wetsvorm, zeg maar.
- Dataminimalisatie: enkel de data verwerken die echt nodig is.
- Security-updates, waar mogelijk automatisch, en gratis.
Updates gedurende de supportperiode
De fabrikant moet een supportperiode vastleggen die past bij hoe lang het product naar verwachting gebruikt wordt, en die is minstens vijf jaar (tenzij het product duidelijk korter meegaat). Die einddatum moet bij aankoop duidelijk vermeld worden. Een eenmaal uitgebrachte security-update moet daarna nog minstens tien jaar beschikbaar blijven.
SBOM: weten wat er in je product zit
Herinner je de supply chain-aanvallen en de BrakTooth-kwetsbaarheid in de Bluetooth-chip. De fabrikant moet voortaan weten welke componenten er in zijn product zitten, en daarvoor een SBOM (Software Bill of Materials) bijhouden: een stuklijst van alle softwarecomponenten en bibliotheken, in een gangbaar, machineleesbaar formaat (bv. SPDX of CycloneDX), met minstens de rechtstreekse afhankelijkheden.
Duikt er een nieuwe Log4Shell op, dan kan een fabrikant met een deftige SBOM in enkele minuten opzoeken welke van zijn producten getroffen zijn. Zonder SBOM begint de zoektocht bij nul.
De fabrikant moet daarnaast een beleid voor gecoördineerde bekendmaking van kwetsbaarheden (coordinated vulnerability disclosure) hebben: een duidelijke manier waarop een ethische hacker een lek kan melden.
Kwetsbaarheden en incidenten melden
Sinds 11 september 2026 moeten fabrikanten twee soorten problemen melden:
- Actief misbruikte kwetsbaarheden in hun product: lekken waarvan vaststaat dat stropers ze effectief gebruiken.
- Ernstige incidenten die de veiligheid van het product raken, bijvoorbeeld wanneer de updateserver van de fabrikant gehackt wordt en er malafide updates verspreid worden (zoals bij SolarWinds).
De melding verloopt via het Single Reporting Platform van ENISA, het Europese agentschap voor cyberbeveiliging, dat die ook op 11 september 2026 lanceerde. De melding komt tegelijk terecht bij ENISA en bij het CSIRT van het land waar de fabrikant gevestigd is (voor een Belgische fabrikant dus het CCB). De termijnen zullen je bekend voorkomen: 24 uur voor een vroegtijdige waarschuwing, 72 uur voor de eigenlijke melding en een eindverslag binnen 14 dagen nadat er een patch beschikbaar is (voor een ernstig incident: binnen een maand). De fabrikant moet ook de getroffen gebruikers verwittigen en uitleggen wat ze kunnen doen.
Let op: die meldplicht geldt voor alle producten op de markt, ook die van vóór de CRA.
Tijdlijn
| Datum | Wat? |
|---|---|
| 10 december 2024 | De CRA treedt in werking. |
| 11 juni 2026 | Regels voor de instanties die conformiteitsbeoordelingen mogen doen. |
| 11 september 2026 | Meldplicht voor actief misbruikte kwetsbaarheden en ernstige incidenten. |
| 11 december 2027 | Volledige toepassing: nieuwe producten moeten aan alle eisen voldoen en een CE-markering dragen. |
Boetes kunnen oplopen tot € 15 miljoen of 2,5% van de wereldwijde jaaromzet voor het niet naleven van de essentiële eisen of de meldplicht.
Meldplichten naast elkaar
Een ransomware-aanval op een ziekenhuis waarbij patiëntgegevens gestolen worden via een lek in de software van een leverancier, kan zomaar drie meldplichten tegelijk in gang zetten: het ziekenhuis meldt onder NIS2 en de GDPR, de leverancier van de software onder de CRA.
| GDPR | NIS2 | CRA | |
|---|---|---|---|
| Wat? | Datalek met persoonsgegevens | Significant incident | Actief misbruikte kwetsbaarheid of ernstig incident in een product |
| Wie meldt? | Elke organisatie die persoonsgegevens verwerkt | Essentiële en belangrijke entiteiten | Fabrikanten van producten met digitale elementen |
| Aan wie? | GBA, en bij hoog risico ook de betrokken personen | CCB, en waar nodig de afnemers van de dienst | CSIRT (in België het CCB) en ENISA via het Single Reporting Platform, en de gebruikers |
| Eerste melding | Zo mogelijk binnen 72 uur | Early warning binnen 24 uur | Early warning binnen 24 uur |
| Vervolg | Aanvullen in fasen | Incidentmelding binnen 72 uur | Melding binnen 72 uur |
| Eindverslag | Geen vaste termijn | Binnen 1 maand na de incidentmelding | 14 dagen na de patch (kwetsbaarheid), 1 maand na de melding (incident) |
| Van toepassing sinds | 25 mei 2018 | 18 oktober 2024 | 11 september 2026 |
| Maximale boete | € 20 miljoen of 4% | € 10 miljoen of 2% (essentieel), € 7 miljoen of 1,4% (belangrijk) | € 15 miljoen of 2,5% |
Dat een organisatie voor één incident bij meerdere instanties moet aankloppen, heeft Europa ook gemerkt. Het Digital Omnibus-voorstel van november 2025 wil daarom één Europees meldpunt voor GDPR, NIS2 en andere regels. In september 2026 is dat nog een voorstel.
Samenvatting
- De Cyber Resilience Act (verordening EU 2024/2847) maakt fabrikanten verantwoordelijk voor de cyberveiligheid van producten met digitale elementen, van babyfoon tot besturingssysteem.
- Producten komen op de markt zonder gekende kwetsbaarheden, secure by default en met een beperkt aanvalsoppervlak.
- De fabrikant legt een supportperiode vast van normaal minstens vijf jaar, met gratis security-updates.
- Een SBOM brengt in kaart welke componenten er in het product zitten.
- Sinds 11 september 2026 meldt de fabrikant actief misbruikte kwetsbaarheden en ernstige incidenten binnen 24 uur via het Single Reporting Platform van ENISA.
- Vanaf 11 december 2027 geldt de CRA volledig en dragen conforme producten een CE-markering.