Cyber Resilience Act: meldplicht vanaf 11 september

Managementsamenvatting

• De CRA-meldplicht geldt vanaf 11 september 2026; het gros van de verplichtingen vanaf 11 december 2027
• Melden vraagt een early warning binnen 24 uur — en dus een beslissingsbevoegdheid die vooraf is toegewezen
• De rolvraag (fabrikant, importeur, distributeur) bepaalt je verplichtingen en verrast bedrijven regelmatig
• Een SBOM is geen administratieve verplichting maar het instrument dat de meldtermijnen haalbaar maakt
• Scope bepalen is juridisch werk met een technisch antwoord; die twee gesprekken apart voeren is de belangrijkste vertraging
• Klanten vragen CRA-documentatie op ruim voor de wettelijke datum

Cyber Resilience Act: van verordening naar implementatieplan

Vanaf 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten melden onder de Cyber Resilience Act. De rest van de verordening volgt op 11 december 2027. Die volgorde is opvallend: de meldplicht komt vóór de productvereisten waaraan gemeld zou moeten worden.

Voor wie producten met digitale elementen op de EU-markt brengt, betekent dat iets heel praktisch. Je hebt vanaf deze maand een meldproces nodig, ook als je conformiteitsdossier nog lang niet af is. En dat proces vraagt beslissingen die vandaag in veel bedrijven bij niemand liggen.

NIS2 kijkt naar je organisatie. De CRA kijkt naar je product. Dat verschil bepaalt wie er in jouw bedrijf aan zet is — en het is zelden dezelfde persoon.

Wat is de Cyber Resilience Act?

De Cyber Resilience Act, Verordening (EU) 2024/2847, stelt cyberbeveiligingseisen aan producten met digitale elementen die op de Europese markt worden aangeboden. De redenering erachter is eenvoudig: als software en verbonden hardware onveilig op de markt komen, verschuift het probleem naar de gebruiker, en die kan er weinig aan doen.

De verordening werkt via het Europese productwetgevingsmodel. Dat brengt begrippen mee die niet uit de securitywereld komen maar uit de interne markt: making available, placing on the market, intended use, redelijkerwijs voorzienbaar misbruik, en vooral substantiële wijziging — het moment waarop een update je product juridisch opnieuw op de markt brengt.

Voor securityteams is die woordenschat nieuw. Voor juristen zijn de technische vereisten dat. Precies daar zit de moeilijkheid van dit dossier.

Welke producten vallen onder de CRA?

Dit is de vraag waar de meeste implementatietrajecten beginnen én vastlopen.

Een product met digitale elementen is ruimer dan de meeste mensen aannemen. Het gaat om software en hardware met een dataverbinding, inclusief losse softwarecomponenten en bepaalde remote data processing solutions die functioneel bij het product horen. Of iets in scope valt, hangt onder meer af van het core-functionality-criterion.

Daarbovenop komt de vraag naar componenten: wat als jouw product bouwt op onderdelen van derden, of op vrije en opensourcesoftware? De verordening kent daarvoor een due-diligenceverplichting en een bijzondere regeling voor open source.

En dan is er nog de rolvraag. Fabrikant, quasi-fabrikant, importeur, distributeur of gemachtigde: elke rol draagt andere verplichtingen. Bedrijven die menen dat ze alleen distribueren, blijken bij nader inzien geregeld fabrikant te zijn — bijvoorbeeld door een product onder eigen merk te verkopen.

De scopevraag is juridisch. Het antwoord komt uit engineering. Zonder allebei kom je er niet uit.

Wat verandert er op 11 september 2026?

Vanaf die datum geldt de meldplicht uit artikel 14. Concreet gaat het om twee sporen: actief misbruikte kwetsbaarheden in je product, en ernstige incidenten die de veiligheid ervan raken.

Het ritme is strak. Een early warning binnen 24 uur nadat je er kennis van krijgt, een meer uitgewerkte melding binnen 72 uur, en daarna een eindrapport — binnen veertien dagen zodra er een corrigerende maatregel beschikbaar is voor een actief misbruikte kwetsbaarheid. Melden gebeurt via het daarvoor voorziene Europese kanaal, met betrokkenheid van de nationale CSIRT en ENISA.

Vierentwintig uur is kort. Niet omdat het technisch moeilijk is, maar omdat het een beslissing vraagt die snel genomen moet worden: is dit een actief misbruikte kwetsbaarheid, en wie in ons bedrijf mag dat vaststellen?

Het probleem is zelden dat het bedrijf niet weet hoe je een kwetsbaarheid oplost. Het probleem is dat niemand aangeduid is om te beslissen dat het er één is die gemeld moet worden. Dat is geen technische kwestie. Het is een governancekeuze die je vóór het eerste incident maakt, niet erna.

SBOM, kwetsbaarhedenbeheer en documentatie

De inhoudelijke vereisten uit bijlage I laten zich vertalen naar een concrete to-dolijst. Drie ervan komen in vrijwel elk traject terug.

Daarnaast blijven er documenten op te leveren: de technische documentatie, de EU-conformiteitsverklaring en de informatie en instructies voor de gebruiker. Dat zijn de stukken die je bij een controle door het CCB of de FOD Economie op tafel legt — en die je klanten steeds vaker in hun vragenlijsten opvragen, ruim voor de wettelijke datum.

Waarom dit juridisch én technisch werk is

De meeste CRA-trajecten stranden niet op onwil, maar op een vertaalprobleem. Legal kan bepalen wat een substantiële wijziging is, maar niet of deze release er één is. Engineering weet wat er in de release zit, maar niet welk juridisch gevolg dat heeft.

Zolang die twee gesprekken apart gevoerd worden, blijft het dossier steken bij een scope-analyse die niemand durft af te sluiten. De organisaties die vooruitgaan, zetten de jurist en de product-securityverantwoordelijke aan dezelfde tafel — en geven hen dezelfde woordenschat.

Waar begin je?

1. Maak een productlijst. Alles wat je op de EU-markt brengt, inclusief software die je meelevert of aanbiedt.
2. Bepaal je rol per product. Fabrikant, importeur, distributeur of gemachtigde — dit kan per productlijn verschillen.
3. Toets de scope met het core-functionality-criterion en bepaal de classificatie.
4. Zet je meldproces op. Wie ontvangt, wie beoordeelt, wie beslist binnen 24 uur, wie meldt. Leg het schriftelijk vast en test het.
5. Bouw je SBOM voor minstens één product, als proefproject. De praktische obstakels vind je pas als je het één keer echt doet.
6. Plan het conformiteitsdossier richting 11 december 2027, met de risicobeoordeling als eerste bouwsteen.

Bouw je eigen CRA-implementatie in twee dagen

CRA Lead Implementer blijft niet bij de uitleg van de wet. Je bouwt de implementatie zelf: scope, classificatie, SBOM, meldproces en documentatie, voor je eigen producten. Breng je productlijst mee — die classificeer je al op dag één.

De opleiding wordt samen gegeven door een cyberjurist en een product-securityexpert: Pedro Demolder (advocaat IP/IT en gegevensbescherming bij Timelex) en Maxim Baele (product security bij Toreon, chapter leader van OWASP België). Juridische vraag, technisch antwoord, en omgekeerd.

Wat je meeneemt:

• weten welke producten in scope vallen en in welke klasse ze zitten
• een meldproces dat de termijnen haalt
• bijlage I vertaald naar een concrete to-dolijst
• technische documentatie en EU-conformiteitsverklaring opgebouwd
• een verdedigbare roadmap voor je management

18–19 november 2026 — Park Inn by Radisson Diegem. De opleiding wordt in het Engels gegeven.
Maximaal 20 deelnemers.
Je legt een examen af en krijgt bij slagen het certificaat “CRA Lead Implementer”.
Daar hoort toegang bij tot jaarlijkse update-sessies, zodat je certificaat meegroeit met nieuwe normen en regelgeving.
€1.495 excl. btw, €1.195 voor overheidsinstellingen.

Bekijk het volledige programma en schrijf je vandaag nog in

Bronnen en verder lezen

• Verordening (EU) 2024/2847 (Cyber Resilience Act) — EUR-Lex
• Europese Commissie, implementatiepagina en FAQ over de CRA
• Centre for Cybersecurity Belgium (CCB)
• NIS2 Lead Implementer België — voor het organisatieluik naast het productluik

Veelgestelde vragen