Regelgeving •

Cyber Resilience Act (EU) 2024/2847 — verplichtingen voor fabrikanten vanaf 11 september 2026

De Cyber Resilience Act geldt voor elk product met digitale elementen. Melden van kwetsbaarheden start op 11 september 2026, volledige toepassing op 11 december 2027.

Auteur: myDPP Team

Cyber Resilience Act (EU) 2024/2847 — verplichtingen voor fabrikanten vanaf 11 september 2026

Twintig jaar lang was productcyberbeveiliging in de EU versnipperd geregeld: deels via de radioapparatuurrichtlijn, deels via sectorale regels, grotendeels helemaal niet. Verordening (EU) 2024/2847 — de Cyber Resilience Act — maakt daar een einde aan. Zij geldt voor elk product met digitale elementen dat op de Uniemarkt wordt aangeboden, van een router tot een softwarebibliotheek die als product wordt verkocht, en koppelt dat aan de CE-markering.

De eerstvolgende deadline ligt niet ver weg. Op 11 september 2026 gaan de meldplichten in: actief misbruikte kwetsbaarheden en ernstige incidenten moeten binnen 24 uur worden gemeld. Dat geldt ook voor producten die al op de markt zijn. De volledige toepassing volgt op 11 december 2027. Voor fabrikanten betekent dat niet alleen nieuw technisch werk, maar ook een set gegevens die de gebruiker moet bereiken en jarenlang juist moet blijven — hetzelfde probleem dat het digitaal productpaspoort op andere complianceterreinen oplost.


De belangrijkste punten

  • Verordening (EU) 2024/2847 is op 10 december 2024 in werking getreden. Zij geldt gefaseerd: bepalingen over aangemelde instanties vanaf 11 juni 2026, meldplichten vanaf 11 september 2026, volledige toepassing vanaf 11 december 2027.
  • Het toepassingsgebied is horizontaal: producten met digitale elementen — hardware en software waarvan het gebruik een directe of indirecte gegevensverbinding met een apparaat of netwerk omvat. Uitgezonderd zijn producten onder eigen regimes: medische hulpmiddelen, motorvoertuigen, burgerluchtvaart, uitrusting van zeeschepen en het defensiedomein.
  • De meeste producten doorlopen een zelfbeoordeling (module A). Belangrijke producten uit bijlage III klasse I vereisen een aangemelde instantie als geharmoniseerde normen niet volledig zijn toegepast; klasse II en kritieke producten uit bijlage IV vereisen altijd een aangemelde instantie of certificering.
  • De ondersteuningsperiode stelt de fabrikant zelf vast, maar die mag in beginsel niet korter zijn dan vijf jaar, tenzij de verwachte gebruiksduur van het product korter is. De einddatum (maand en jaar) moet bij aankoop worden vermeld.
  • Een SBOM — een machineleesbare softwarestuklijst die ten minste de afhankelijkheden op het hoogste niveau dekt — is een eis uit bijlage I. Die moet actueel worden gehouden en op verzoek aan markttoezichtautoriteiten worden verstrekt.
  • Beveiligingsupdates zijn kosteloos en moeten na uitgifte ten minste tien jaar beschikbaar blijven, of tot het einde van de ondersteuningsperiode als die langer loopt.
  • Conformiteit wordt aangetoond met een EU-conformiteitsverklaring en CE-markering — dezelfde instrumenten als in de rest van het productrecht.
  • De hoogste boetecategorie voor schending van de essentiële eisen en van de verplichtingen uit de artikelen 13 en 14 bedraagt 15 miljoen euro of 2,5 % van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.
  • De CRA voert geen digitaal productpaspoort in. Zij creëert wel een set product- en versiegebonden informatie die jarenlang bereikbaar moet blijven — en dat is een vraagstuk van gegevensbeheer.

Wat de Cyber Resilience Act eigenlijk is

De CRA is een horizontale verordening: zij beschrijft geen sector, maar een gemeenschappelijke eigenschap van producten. Die eigenschap is de aanwezigheid van een digitaal element en het vermogen om gegevens uit te wisselen. Structureel hoort zij bij de familie van productrecht die bekend is van de CE-markering: essentiële eisen in een bijlage, conformiteitsbeoordeling, technische documentatie, een verklaring en een merkteken.

Het nieuwe zit elders. Het productrecht beoordeelde tot nu toe de waar op het moment van het in de handel brengen; daarna hield de belangstelling van de regelgever in de praktijk op. De CRA aanvaardt die aanname niet. De plicht om kwetsbaarheden af te handelen, updates uit te brengen en incidenten te melden loopt over de hele verklaarde ondersteuningsperiode. Een product dat op de verkoopdag conform was, kan twee jaar later niet meer conform zijn als de fabrikant bekende kwetsbaarheden niet langer verhelpt.

Vermeldenswaard is ook het opruimwerk dat de CRA in het bestaande recht verricht. Gedelegeerde Verordening (EU) 2022/30, die sinds 2025 cyberbeveiligingseisen via de radioapparatuurrichtlijn uitvoerde, wordt ingetrokken op de datum waarop de CRA volledig van toepassing wordt: 11 december 2027. De essentiële eisen van bijlage I dekken alles wat de radioapparatuurregels dekten, waardoor het dubbele regime verdwijnt.

Wat een «product met digitale elementen» is

De definitie is ruim, en dat is bewust. Het gaat om een hardware- of softwareproduct waarvan het beoogde of redelijkerwijs te voorziene gebruik een directe of indirecte gegevensverbinding met een apparaat of netwerk omvat. Ook oplossingen voor gegevensverwerking op afstand vallen eronder, voor zover die nodig zijn om het product te laten werken.

In de praktijk is het eenvoudiger te benoemen wat buiten het toepassingsgebied valt, want de lijst met uitzonderingen is gesloten en concreet:

  • Medische hulpmiddelen en medische hulpmiddelen voor in-vitrodiagnostiek — Verordeningen (EU) 2017/745 en (EU) 2017/746.
  • Motorvoertuigen — Verordening (EU) 2019/2144.
  • Burgerluchtvaart — Verordening (EU) 2018/1139.
  • Uitrusting van zeeschepen — Richtlijn 2014/90/EU.
  • Producten die uitsluitend voor nationale veiligheid of defensie zijn ontwikkeld, en producten die niet in het kader van een handelsactiviteit worden geleverd.

Buiten die uitzonderingen is het bereik zeer breed. Software die als product wordt verkocht valt er net zo goed onder als een apparaat. Vrije en opensourcesoftware die niet-commercieel wordt ontwikkeld niet — maar artikel 24 creëert een afzonderlijke, lichtere rol van beheerder van opensourcesoftware, voor entiteiten die de ontwikkeling van dergelijke software voor commercieel gebruik duurzaam ondersteunen.

Drie risiconiveaus, drie beoordelingsroutes

De verordening schaalt haar strengheid naar de gevolgen die een beveiligingsinbreuk bij een product kan hebben.

Standaardproducten — de grote meerderheid van de markt. De fabrikant voert interne controle uit (module A) en stelt zelf de technische documentatie en de verklaring op. Een aangemelde instantie is niet nodig.

Belangrijke producten, bijlage III klasse I — onder meer wachtwoordmanagers, antivirussoftware, systemen voor identiteits- en privileged-accessbeheer, VPN, besturingssystemen, routers en switches, microprocessors met beveiligingsgerelateerde functies, virtuele assistenten voor thuis, met internet verbonden speelgoed en wearables. Zelfbeoordeling blijft mogelijk, maar alleen bij volledige toepassing van geharmoniseerde normen of gemeenschappelijke specificaties. Zonder die normen komt er een aangemelde instantie aan te pas.

Belangrijke producten, bijlage III klasse II — bijvoorbeeld firewalls, systemen voor inbraakdetectie en -preventie, hypervisors en manipulatiebestendige microprocessors. Hier is een aangemelde instantie of een Europees cyberbeveiligingscertificeringsschema verplicht.

Kritieke producten, bijlage IV — het strengste niveau, met verplichte aangemelde instantie of certificering. De technische beschrijvingen van de categorieën staan in Uitvoeringsverordening (EU) 2025/2392.

De praktische conclusie is dezelfde als bij elke regeling met aangemelde instanties: classificeer vroeg. Valt een product in klasse II of bijlage IV, dan wordt de doorlooptijd van de aangemelde instantie onderdeel van de introductieplanning en geen formaliteit aan het eind.

Verplichtingen van de fabrikant — wat er echt moet gebeuren

Essentiële eisen, deel één: producteigenschappen

Bijlage I deel I beschrijft hoe het product moet zijn. De kernpunten: in de handel gebracht zonder bekende exploiteerbare kwetsbaarheden, geleverd met een veilige standaardconfiguratie en de mogelijkheid tot terugzetten naar de fabrieksstaat, bescherming van vertrouwelijkheid, integriteit en beschikbaarheid van gegevens, minimalisering van het aanvalsoppervlak, beperking van gegevensverzameling tot het noodzakelijke, en de mogelijkheid om beveiligingsupdates te installeren — waar mogelijk automatisch en met duidelijke melding aan de gebruiker.

Essentiële eisen, deel twee: afhandeling van kwetsbaarheden

Bijlage I deel II beschrijft een proces dat gedurende de hele ondersteuningsperiode moet werken:

  • Een SBOM in machineleesbaar formaat, die ten minste de afhankelijkheden op het hoogste niveau dekt en actueel wordt gehouden. Publiceren richting gebruikers is niet verplicht, verstrekken aan markttoezichtautoriteiten op verzoek wel.
  • Kwetsbaarheden onverwijld verhelpen, mede door beveiligingsupdates uit te brengen.
  • Regelmatige beveiligingstests en -beoordelingen.
  • Openbaarmaking van informatie over verholpen kwetsbaarheden zodra een update beschikbaar is.
  • Een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden en één contactpunt voor meldingen.
  • Kosteloze verspreiding van beveiligingsupdates zonder vertraging.

De ondersteuningsperiode — een nieuw gegevensveld met commerciële gevolgen

Dit is de verplichting die het vaakst verrast. De fabrikant bepaalt zelf de periode waarin hij kwetsbaarheden van het product doeltreffend afhandelt, maar die mag niet korter zijn dan vijf jaar — tenzij de verwachte gebruiksduur van het product korter is. De einddatum, op maand en jaar nauwkeurig, moet bij aankoop duidelijk worden vermeld.

Daarboven ligt een tweede horizon. Een eenmaal uitgebrachte beveiligingsupdate moet ten minste tien jaar na uitgifte beschikbaar blijven, of tot het einde van de ondersteuningsperiode als die later afloopt. Dat is een infrastructuurtoezegging: iemand moet bestanden en informatie een decennium lang bereikbaar houden, door systeem- en domeinwijzigingen heen.

Melden van kwetsbaarheden en incidenten — de datum 11 september 2026

Artikel 14 introduceert de verplichtingen die het eerst ingaan en die ook producten treffen die al op de markt zijn. Gemeld moeten worden: actief misbruikte kwetsbaarheden en ernstige incidenten die de beveiliging van het product raken — bij het CSIRT van de lidstaat van de hoofdvestiging van de fabrikant en bij ENISA, via één meldplatform.

FaseTermijn
Vroegtijdige waarschuwing24 uur
Eigenlijke melding72 uur
Eindverslag — kwetsbaarheid14 dagen nadat een corrigerende maatregel beschikbaar is
Eindverslag — ernstig incident1 maand

De 24 uur voor de vroegtijdige waarschuwing is een operationele termijn, geen juridische abstractie. Dat betekent dat bereikbaarheidsdienst, escalatiepad en platformtoegang vooraf moeten bestaan. Micro-ondernemingen en kleine ondernemingen krijgen geen boete voor het missen van de termijn van 24 uur, maar de meldplicht zelf geldt ook voor hen.

Informatie voor de gebruiker — bijlage II

Bijlage II somt de informatie op die het product moet vergezellen: identificatie van type, partij of serienummer, gegevens van de fabrikant met adres en contactpunt, één contactpunt voor het melden van kwetsbaarheden en een verwijzing naar waar het openbaarmakingsbeleid te vinden is, het beoogde gebruik, instructies voor veilige installatie en veilig gebruik, hoe beveiligingsupdates worden verkregen en de einddatum van de ondersteuningsperiode.

Tijdlijn

DatumWat er gebeurt
10 december 2024Inwerkingtreding van Verordening (EU) 2024/2847
11 juni 2026Toepassing van de bepalingen over aangemelde instanties (hoofdstuk IV)
11 september 2026Toepassing van de meldplichten (art. 14) — ook voor producten die al op de markt zijn
11 december 2027Volledige toepassing: essentiële eisen, conformiteitsbeoordeling, CE, documentatie
11 juni 2028Verstrijken van in de overgangsperiode afgegeven certificaten van EU-typeonderzoek

Producten die vóór 11 december 2027 in de handel zijn gebracht, vallen pas onder de volledige eisen als zij na die datum substantieel worden gewijzigd. De meldplichten gelden echter hoe dan ook voor hen.

Het loont deze data naast de machineverordening (EU) 2023/1230 te leggen, die vanaf 20 januari 2027 van toepassing is. Een machine met digitale elementen valt binnen minder dan elf maanden onder beide regimes: de machineverordening behandelt cyberbeveiliging als eis van functionele veiligheid, terwijl de CRA horizontale verplichtingen oplegt aan software, besturingen en connectiviteit. Het zijn twee elkaar aanvullende regimes, geen alternatieven.

Wat dit betekent voor productdata

Laten we het duidelijk zeggen, want dit wordt vaak verward: de Cyber Resilience Act voert geen digitaal productpaspoort in. Er staat geen paspoortplicht in, geen gegevensdrager en geen register. De paspoortplicht volgt uit de ESPR en uit sectorale regelgeving die haar uitdrukkelijk voorschrijft.

Maar de set informatieplichten die de CRA creëert is in een mate een vraagstuk van gegevensbeheer dat moeilijk te negeren valt:

  • Identiteit op versieniveau. De SBOM verandert bij elke softwarerelease. Een stuklijst die niet zegt op welke versie zij betrekking heeft, is als bewijs waardeloos. Dat is hetzelfde principe van versioneren in plaats van overschrijven waarop het paspoort rust.
  • De einddatum van ondersteuning als veld, niet als zin in een folder. Die moet bij aankoop worden gegeven, consistent zijn over alle verkoopkanalen en jaren later verifieerbaar zijn. Een verschil tussen de productpagina in de eigen winkel en die bij de distributeur is dan niet langer cosmetisch.
  • Een oplosbare gegevensdrager. Het contactpunt voor kwetsbaarheden, het openbaarmakingsbeleid en de update-informatie moeten de hele ondersteuningsperiode bereikbaar blijven. Een code die naar het actuele record verwijst, doet dat beter dan een adres dat zes jaar geleden in een handleiding is gedrukt. De varianten bespreken we in ons artikel over QR-code en GS1 Digital Link.
  • Meertaligheid. De informatie uit bijlage II moet begrijpelijk zijn voor gebruikers in de landen waar het product wordt aangeboden. Bij digitale documentatie is dat geen vertaalproject, maar een veld met taalversies.
  • Continuïteit over een decennium. Tien jaar beschikbaarheid van updates en informatie is een servicetoezegging die migraties, rebrandings en leverancierswissels overleeft.

Voor elektronica komt daar een praktisch argument bij. Dezelfde productcategorie staat tegelijk in het vizier van de ESPR, de RoHS-richtlijn en de regels voor afgedankte elektronica. Een bedrijf dat stoffendata apart, repareerbaarheidsdata apart en softwareondersteuningsdata weer apart bijhoudt, onderhoudt drie registers over hetzelfde product. Productdata één keer goed ordenen bedient al die richtingen — het beginpunt is ons artikel over waarom productdata de basis vormen voor het DPP.

Een eerlijke kanttekening bij de grenzen van de rol van een leverancier: myDPP voert geen beveiligingstests uit, genereert of valideert geen SBOM, voert geen proces voor kwetsbaarheidsafhandeling, beoordeelt geen CRA-conformiteit, is geen aangemelde instantie en dient geen meldingen op grond van artikel 14 in. myDPP bewaart, versioneert en publiceert geverifieerde productdata en onderhoudt de drager die deze opent. De verantwoordelijkheid voor conformiteit blijft bij de fabrikant.

Voorbereiding — vijf stappen

  1. Classificeer het portfolio. Stel vast welke producten producten met digitale elementen zijn, en welke daarvan onder bijlage III klasse I of II dan wel bijlage IV vallen. Daarvan hangt af of een aangemelde instantie nodig is — en hoe lang de beoordeling duurt.
  2. Zorg dat melden werkt vóór 11 september 2026. Wijs verantwoordelijken aan, leg het escalatiepad voor de waarschuwing binnen 24 uur vast, regel platformtoegang en oefen het op een testcasus. Deze termijn wacht niet tot de rest van het project klaar is.
  3. Stel ondersteuningsperioden vast en leg ze vast als data. Bepaal per productfamilie een einddatum van ondersteuning, onderbouw die met de verwachte gebruiksduur en zet die in het systeem dat webshop, distributeurs en documentatie voedt — niet alleen in een productpresentatie.
  4. Bouw SBOM-generatie in het releaseproces in. Een stuklijst die eens per kwartaal met de hand wordt bijgewerkt, loopt bij de eerste patchrelease uit de pas. De SBOM aan versie en exemplaar koppelen is werk aan de datakant, niet aan de juridische kant.
  5. Breng de informatie uit bijlage II op orde. Contactpunt, openbaarmakingsbeleid, instructies voor veilige configuratie en de einddatum van ondersteuning moeten in alle talen en kanalen consistent en jarenlang bereikbaar zijn.

Het bredere dataprogramma behandelen we in onze DPP-implementatiechecklist.

Veelgestelde vragen

Geldt de CRA voor producten die ik vóór 2027 heb verkocht?

Gedeeltelijk. De volledige eisen — essentiële eisen, conformiteitsbeoordeling, CE — bereiken een product dat vóór 11 december 2027 in de handel is gebracht pas als het na die datum substantieel wordt gewijzigd. De meldplichten uit artikel 14 gelden daarentegen voor producten die al op de markt zijn, vanaf 11 september 2026, ongeacht de verkoopdatum.

Moet ik de SBOM voor mijn klanten publiceren?

Nee. Bijlage I vereist het opstellen en actueel houden van een machineleesbare stuklijst die ten minste de afhankelijkheden op het hoogste niveau dekt, en het verstrekken daarvan aan markttoezichtautoriteiten op verzoek. De SBOM publiceren richting gebruikers is een commerciële keuze, geen wettelijke plicht.

Mag ik een ondersteuningsperiode korter dan vijf jaar vaststellen?

Alleen als de verwachte gebruiksduur van het product korter is dan vijf jaar, en dat moet onderbouwd kunnen worden. In andere gevallen is vijf jaar de ondergrens, en als het product in werkelijkheid langer wordt gebruikt, zou de ondersteuningsperiode de feitelijke gebruiksduur moeten volgen.

Voert de Cyber Resilience Act een digitaal productpaspoort in?

Nee. De CRA bevat geen paspoortplicht en geen voorschrift voor een gegevensdrager. Zij legt wel product- en versiegebonden informatieplichten op die gedurende de ondersteuningsperiode en een decennium na het uitbrengen van een update beschikbaar moeten blijven. De data-eisen lopen samen met die van het paspoort, dus één keer opruimen bedient beide richtingen.

Verder lezen

Bronnen