Verkoop je een connected product in de EU, dan is de Cyber Resilience Act nu jouw probleem.
De eerste deadline is dichtbij. Vanaf 11 september 2026 heb je 24 uur om te melden dat iemand een lek in je product actief misbruikt. De rest, waarbij security onderdeel wordt van de CE-markering zelf, gaat in op 11 december 2027.
Wij bouwen en certificeren IoT-hardware, dus we volgen deze wet van dichtbij. Dit is wat hij van je vraagt, voor wie hij geldt, en wat je dit jaar al kunt doen.
Wat de wet is
De CRA is Verordening (EU) 2024/2847. Hij is sinds december 2024 van kracht en gaat over "producten met digitale elementen": alles met software erin dat verbinding kan maken met een apparaat of een netwerk, direct of via iets anders.
In de praktijk betekent dat elk IoT-product. Sensoren, trackers, wearables, gateways, en de app en clouddienst die erbij horen.
De verandering is simpel te formuleren. Security is nu een voorwaarde voor de CE-markering, net zoals elektrische veiligheid en radiogedrag dat al waren. Kun je het niet aantonen, dan mag je niet verkopen.
De datums
| Datum | Wat er geldt |
|---|---|
| 10 december 2024 | De CRA is in werking getreden |
| 1 augustus 2025 | Securityregels uit de Radio Equipment Directive (artikel 3.3 d/e/f). Nu al verplicht voor de meeste draadloze IoT-apparaten |
| 11 september 2026 | Je moet misbruikte kwetsbaarheden en ernstige incidenten melden |
| 11 december 2027 | De rest: de eisen zelf, de beoordeling, de documentatie, de CE-markering |
Twee dingen in die tabel worden vaak gemist.
Draadloze producten hebben sinds augustus 2025 al securityeisen onder de Radio Equipment Directive, getoetst aan een normenreeks die EN 18031 heet. Is je apparaat recent door de RED-certificering gegaan, dan heb je al een deel gedaan van wat de CRA straks vraagt. Zo niet, dan voldoe je vandaag mogelijk al niet, nog vóór de CRA begint.
De meldplicht van september 2026 geldt bovendien voor producten die al in het veld staan. Niets is uitgezonderd omdat het eerder is geleverd. Staat je apparaat ergens en misbruikt iemand een lek, dan meld je dat, ongeacht wanneer je het op de markt bracht.
Wat september 2026 concreet vraagt
Vanaf die datum meld je bij ENISA en je nationale CSIRT, via het meldplatform van de EU, zodra je weet dat een kwetsbaarheid in je product wordt misbruikt of dat je een ernstig securityincident hebt gehad:
- Een eerste waarschuwing binnen 24 uur nadat je het weet
- De volledige melding binnen 72 uur, met wat je tot dan weet en wat je eraan doet
- Een eindrapport zodra het is opgelost: binnen 14 dagen bij een misbruikte kwetsbaarheid, binnen een maand bij een incident
Die termijnen zijn genadeloos als je nog nooit een securityrespons hebt gedraaid. Je hebt iemand nodig wiens taak het is op de klok te letten. Je hebt een manier nodig waarop onderzoekers en klanten je kunnen bereiken, dus minstens een security.txt en een mailbox die iemand echt leest. En je moet je eigen firmware goed genoeg kennen om een melding snel te kunnen beoordelen.
Dat is werk voor dit jaar, niet voor volgend jaar.
Wat er in december 2027 verandert
Vanaf 11 december 2027 betekent een product met digitale elementen op de EU-markt brengen: voldoen aan de eisen van de CRA, een beoordeling doorlopen, en de papieren hebben om het aan te tonen. Kort samengevat:
Je ontwerpt het veilig en levert het veilig. Dat betekent een risicobeoordeling tijdens het bouwen, geen bekende misbruikbare lekken bij release, een veilige configuratie uit de doos, en data beschermd zowel onderweg als in rust.
Je kunt beveiligingsupdates los van feature-updates uitleveren, gedurende een ondersteuningsperiode die je aan je kopers meldt. Vijf jaar is de gangbare verwachting.
Je houdt een Software Bill of Materials bij in je documentatie. Dat is een lijst van elk softwareonderdeel in je product, en het nut ervan is bot: je kunt geen component patchen dat je niet kunt benoemen.
Je hebt een manier om met kwetsbaarheden om te gaan. Een disclosurebeleid, een contactpunt, en een proces om te testen en te repareren.
Je documentatie en CE-markering sluiten aan op hetzelfde raamwerk dat je al kent van RED en EMC. De meeste gewone IoT-producten mogen zichzelf beoordelen. Alleen de klassen "belangrijk" en "kritiek" hebben een externe partij nodig.
Producten die vóór die datum al op de markt zijn, vallen pas onder de volledige eisen zodra je er een substantiële wijziging in aanbrengt. Een grote firmware-herziening kan daaronder vallen, dus "wij verkochten al in 2027" beschermt je minder dan het klinkt.
Boetes lopen op tot 15 miljoen euro of 2,5% van de wereldwijde omzet. Voor een kleine fabrikant is het saaiere risico waarschijnlijker: een distributeur die je product weigert omdat de papieren er niet zijn.
Wat je dit jaar doet
Dit is de volgorde die we aanraden aan de teams waarmee we werken.
Begin met in kaart brengen wat je risico is. Elk product met digitale elementen dat je in de EU verkoopt, de firmwarestack, hoe het verbindt. Bepaal daarna per product of het in de klasse standaard, belangrijk of kritiek valt.
Maak per product een SBOM. Moderne buildtooling als Zephyr, ESP-IDF en Yocto kan er een genereren. Hem kloppend krijgen is het echte werk.
Zet het meldproces op vóór je het nodig hebt. Wijs een eigenaar aan, publiceer een securitycontact, registreer je op het ENISA-platform zodra het opengaat, en loop de 24- en 72-uursroute één keer door als oefening.
Bepaal je ondersteuningsperiode, publiceer die, en controleer of je OTA-infrastructuur hem waar kan maken.
Dicht het RED-gat nu. Is je draadloze product niet getoetst aan EN 18031, dan is dat een probleem van vandaag.
Ontwerp nieuwe producten vanaf de eerste schets tegen de CRA aan. Secure boot, gesigneerde updates, een uniek wachtwoord per apparaat, een dichtgetimmerde standaardconfiguratie. Het is allemaal goedkoop tijdens het ontwerp en pijnlijk om achteraf in te bouwen.
En vouw de CRA-papieren in je technisch dossier voor CE, zodat certificering één klus blijft in plaats van twee.
Waar dit de certificering raakt
De CRA draait op dezelfde machinerie als de rest van de CE-markering. De route erdoorheen is dus de route die je al kent: compliance vroeg in het ontwerp meenemen, het technisch dossier bijhouden terwijl je bouwt, en zelf testen voordat het geaccrediteerde lab dat doet.
Zo werken wij bij CE- en FCC-certificering. Pre-compliance ingebouwd in de print en de firmware, documentatie die tijdens de ontwikkeling ontstaat, en labtijd geboekt voor het moment dat slagen een formaliteit is. De CRA voegt een securitylaag toe aan dat dossier, met de SBOM, de risicobeoordeling en het updatebeleid, in plaats van een tweede dossier dat je moet bijhouden.
Plan je nu een connected product, dan is het goedkoopste moment om de CRA aan te pakken vóór je eerste schema. Heb je al producten in het veld, dan is september de datum waar je wakker van moet liggen.
Neem contact op als je je roadmap tegen beide datums wilt laten leggen, of lees onze gids over CE-certificering voor het bredere plaatje.
Bronnen: Europese Commissie — Cyber Resilience Act, Europese Commissie — CRA-meldplicht.
