In 12 stappen naar compliance met de Cyber Resilience Act

De Cyber Resilience Act brengt voor het eerst uniforme Europese regels voor de cybersecurity van digitale producten. Voor veel organisaties betekent dat: tijdig voorbereiden op strengere eisen aan software en hardware.

Begin dit jaar schreef mijn collega een inleiding tot de Cyber Resilience Act (CRA). In dit blog lees je in welke stappen organisaties zich kunnen voorbereiden op de naleving van de CRA, die in het Nederlands overigens de Verordening cyberweerbaarheid wordt genoemd.

1. Begrijp de scope en deadlines

Voordat je met de inhoudelijke eisen aan de slag gaat, is het belangrijk om te begrijpen wat de CRA precies omvat en welke organisaties onder de regeling vallen. Deze wet is gericht op het realiseren van een goede beveiliging en weerbaarheid van “producten met digitale elementen”. Dat wil zeggen hardware met software, zoals smart devices, maar ook software die op zichzelf staat, zoals apps. Houd er dus rekening mee dat de reikwijdte van deze wet erg breed is. Ieder bedrijf dat software ontwikkelt en op de markt brengt in de EU of EER valt in principe onder de CRA.

Belangrijke datums:
  • Vastgesteld: 10 december 2024.
  • Eerste meldplichten: vanaf 11 september 2026.
  • Algemene toepasselijkheid (markttoegang, CE-markering): 11 december 2027.
Acties:
  • Zorg voor een helder overzicht van alle producten met digitale elementen die jouw organisatie in de EU of EER op de markt brengt.
  • Overweeg een Product Security Officer en/of CRA-programmalead aan te wijzen die compliance kunnen helpen borgen voordat de verplichtingen ingaan.
  • Houd per product belangrijke kenmerken bij zoals: type, versie/release, markten, life-cycle of supporttermijn, en cloud- of back-end componenten.

Zodra je weet of jouw producten onder de CRA vallen, is de volgende stap om te bepalen welke rol jouw organisatie in de keten heeft.

2. Bepaal jouw rol(len) in de keten

De CRA kent verplichtingen voor fabrikanten, importeurs en distributeurs (marktdeelnemers). Voor elk product met digitale elementen dat jouw organisatie op de markt brengt of helpt brengen, is het belangrijk om vast te stellen welke rol de organisatie heeft volgens de CRA.

Acties:
  • Leg vast wat de rol is van jouw onderneming, of van elk van de entiteiten binnen de groep van bedrijven.
  • Focus daarbij in de eerste plaats op fabrikanten, omdat de CRA de meeste en de zwaarste verplichtingen oplegt aan deze rol.

3. Classificeer elk product volgens Bijlage III en IV en bepaal de conformiteitsroute

De CRA stelt zwaardere eisen aan producten die bij misbruik grotere schade kunnen veroorzaken. Hoe kritieker het product, hoe zwaarder de eisen en de beoordeling. Ook de conformiteitsbeoordeling zelf wordt zwaarder naarmate de producten belangrijker zijn of grotere risico’s kennen.

Producten moeten volgens de CRA worden ingedeeld in belangrijke categorieën (klasse I of II in Bijlage III) en kritieke categorieën (in Bijlage IV). De categorie of klasse beïnvloedt de conformiteitsbeoordelingsprocedure. De Commissie specificeert de technische beschrijvingen van belangrijke categorieën (klasse I of II) en kritische categorieën via een uitvoeringshandeling.

Acties:
  • Map je producten tegen de categorieën in Bijlage III en IV en documenteer de onderbouwing.
  • Bepaal per product de conformiteitsroute volgens artikel 32 en Bijlage VIII.
  • Maak een CRA-classificatiedossier met conformiteitsprocedure per product.

Wanneer de classificatie per product duidelijk is, kun je toetsen of jouw huidige beveiligingsmaatregelen voldoen aan de eisen van de CRA.

4. Voer een gap-analyse uit tegen Bijlage I (essentiële eisen)

Bijlage I bevat productveiligheidseisen (Deel I) en vulnerability-handling-eisen (Deel II). Denk aan: “secure-by-design en default”, geleverd zonder bekende exploiteerbare kwetsbaarheden, logging, update-mechanismen en SBOM (software bill of materials of ‘softwarestuklijst’; minstens top-level dependencies) als onderdeel van vulnerability-beheer.

Acties:
  • Review architectuur en software development life cycle (SDLC) tegen de 13 kernvereisten; leg per eis vast of er een tekortkoming (gap) is voor compliance.
  • Stel een remediation plan op (met prioriteiten, budget, deadlines).

De uitkomsten van de gap-analyse geven richting aan de verbeteracties binnen de software development life cycle (SDLC).

5. Integreer “secure development” in software development life cycle (SDLC)

Acties:
  • Neem bijvoorbeeld treat modeling, third-party component governance, code review, statische of dynamische tests en fuzzing op, waar relevant.
  • Borg communicatie aan klanten over updatebeleid (security updates binnen redelijke termijn) en supporttermijn.
  • Stel een SDLC-beleid op of werk deze bij en geef ook aan welk bewijs er verzameld en bewaard moet worden om secure development aan te tonen (zoals checklists, pipelines, testverslagen).

Naast veilig ontwikkelen is het belangrijk om kwetsbaarheden na oplevering goed te beheren.

6. Richt vulnerability management en incidentrespons in (vóór 11-09-2026)

Vanaf 11 september 2026 gelden meldplichten via het ENISA single reporting platform en de nationale CSIRT-coördinator. In Nederland is dat het Nationaal Cyber Security Centrum (NCSC). Deadlines uit de wetstekst (art. 14):

  • Early warning van een actief misbruikte kwetsbaarheid: zonder onnodige vertraging en binnen 24 uur nadat de fabrikant er kennis van kreeg.
  • Vulnerability notification met details: zonder onnodige vertraging en binnen 72 uur na bekendwording.
  • Vergelijkbare termijnen voor ernstige incidenten die de productbeveiliging raken.
  • Eindverslag binnen 14 dagen met o.a. de update of andere maatregel om de kwetsbaarheid te verhelpen.
Acties:
  • Stel processen of werkstromen vast voor triage, detectie en respons, interne escalatie en rapportage (incl. legal review).
  • Koppel tooling voor kwetsbaarhedenscans, exploit-monitoring en advisories; beheer SBOM’s en kwetsbaarheidsdata actief.
  • Stel standaardprocedures en sjablonen op voor melding van de juiste informatie binnen 24 uur en 72 uur en voor de eindrapportage na 14 dagen. Oefen het doen van meldingen op basis van de sjablonen en stel oefenrapporten op.

7. Bouw een technisch dossier volgens art. 23-29 en Bijlage II

Het dossier onderbouwt conformiteit: risicoanalyse / threat model, ontwerpkeuzes, testresultaten, SBOM, patch/updatestrategie, gebruikersinformatie (incl. veilige configuratie), en bewijs van vulnerability-processen. Dit dossier moet up-to-date zijn en aan toezichthouders kunnen worden verstrekt.

Met een compleet technisch dossier wordt duidelijk hoe jouw organisatie de CRA naleeft. De volgende stap is aantonen dat je aan de eisen voldoet, bijvoorbeeld via geharmoniseerde normen.

8. Gebruik (waar beschikbaar) geharmoniseerde normen of bewijs gelijkwaardigheid

Als er geharmoniseerde Europese normen komen, geeft toepassing een vermoeden van conformiteit. Zonder norm moet de organisatie bewijzen dat de maatregelen de Bijlage-I-eisen dekken. (Notified bodies toetsen dit bij Klasse I/II of kritische producten.)

Acties:
  • Volg normontwikkeling; plan tijdig (her)testen.
  • Definieer interne “security requirements to test” als je (nog) geen norm kunt volgen.

9. Doorloop de conformiteitsbeoordeling

Afhankelijk van de klasse: interne controle (self-assessment) of beoordeling door een notified body; voor bepaalde kritische categorieën kan EUCC-certificering verplicht zijn.

10. CE-markering & EU-conformiteitsverklaring

Na geslaagde beoordeling: stel de EU-DoC (Declaration of Conformity) op en breng de CE-markering aan voordat je het product in de EU op de markt brengt. Vanaf 11 december 2027 is CRA-conformiteit een harde voorwaarde voor verkoop.

Zorg dat gebruikersinformatie compleet is incl. veilige default en updatebeleid.

11. Contractuele borging in de keten

Leg CRA-vereisten vast richting leveranciers, importeurs en distributeurs (bijv. SBOM-aanlevering, kwetsbaarheids-SLAs, updateverplichtingen, auditrechten). Dit ondersteunt de verantwoordelijkheden als fabrikant en het markttoezichtskader.

Pas het beleid en de processen aan voor leveranciersmanagement, inkoopvoorwaarden, DPA’s, SLA’s en vragenlijsten (questionnaires).

Compliance stopt niet bij de markttoelating. De CRA vereist voortdurende monitoring en onderhoud van cyberveiligheid gedurende de hele levenscyclus.

12. Post-market surveillance & continue compliance

Je moet actief monitoren, updates leveren en gebruikers informeren bij kwetsbaarheden/incidenten gedurende de gecommuniceerde supporttermijn. Documenteer alles; houd het technisch dossier actueel.

Zorg voor zaken als release-notes, security advisories, update-telemetrie en een jaarlijks CRA-compliance-rapport.

Tijdlijn & mijlpalen, samenvatting

  • Nu → 11-09-2026: classificeer producten, sluit gaps t.o.v. Annex I, bouw SBOM-beheer en meldprocessen. Meldplichten starten 11-09-2026 (24u early warning, 72u vervolg).
  • 11-09-2026 → 11-12-2027: afronden conformiteitsbeoordelingen, CE-markering, supply-chain contractupdates, opleiding/support-processen.
  • Vanaf 11-12-2027: alleen nog CRA-conforme (CE-gemarkeerde) producten op de EU-markt.

Sancties (globaal)

Niet-naleving van de essentiële cybersecurity-eisen kan leiden tot boetes tot €15 miljoen of 2,5% van de wereldwijde jaaromzet (welke hoger is). Lagere schijven gelden voor andere overtredingen. Het geven van misleidende informatie kan beboet worden tot €5 miljoen of 1% omzet.

Praktische quick-wins (direct starten)

  1. SBOM-basis op orde (top-level dependencies in een machine-leesbaar formaat) en koppelen aan kwetsbaarheidsmonitoring.
  2. 24u/72u meldingen oefenen met tabletop-scenario’s en een standby-jurist.
  3. Secure-by-default baseline en hardening-gids aan eindgebruikers leveren.
  4. Productclassificatie en conformiteitsroute vastleggen, zodat development-roadmaps realistisch blijven.

Het implementeren van ISO 27001 helpt niet alleen bij DORA (zie mijn vorige blog) en de CRA, maar vormt ook een solide basis voor toekomstige Europese regelgeving op het gebied van cybersecurity. Onze ervaring leert dat organisaties die hier tijdig op inzetten, straks veel soepeler door de CRA-verplichtingen heen zullen gaan.

Wil je een sleutelrol spelen om jouw organisatie en haar producten cyberweerbaarder te maken? Dan is onze opleiding tot Certified Cybersecurity Compliance Officer (CCCO®) iets voor jou. Deze opleiding geeft jou begrip van wet-en regelgeving omtrent cybersecurity en informatiebeveiliging, inclusief de NIS2, AI Act, DORA, CRA, CER en ISO 27001. Je leert hoe deze regels zich tot elkaar verhouden en hoe je ze in de praktijk toe moet gaan passen.

Bekijk hier onze brochure.

CCCO® brochure

Terug naar overzicht