Cyber Resilience Act stap voor stap: gereedheid voor fabrikanten

Een praktisch CRA-gereedheidspad voor fabrikanten: bevestig scope en classificatie, sluit Bijlage I-hiaten, voer vulnerability handling en rapportage uit, en plan conformiteitsbeoordeling en CE-markering vóór december 2027.

Deze gids is voor fabrikanten van verbonden hardware en software, en voor de teams voor productbeveiliging, engineering en compliance die de Cyber Resilience Act (CRA) in de praktijk moeten brengen. De rollen van importeurs, distributeurs en open-source-beheerders worden ook behandeld. Aan het einde heb je een bevestigde scope en rol per product, een classificatiebeslissing, een Bijlage I-gapanalyse, een werkend kwetsbaarheidsafhandelings- en meldingsproces, en een plan voor documentatie, conformiteitsbeoordeling en CE-markering.

Voordat je begint

De CRA is productregelgeving in de CE-markeringstradtie, geen organisatorische norm zoals ISO/IEC 27001. Compliance wordt per product beoordeeld. Je hebt een portfoliolijst nodig die softwareproducten, firmware, companion-apps en cloud back-ends omvat; een benoemde product security owner (meestal een PSIRT-leider) met invloed op releasebeslissingen; en toegang tot architectuurdiagrammen, build pipelines en afhankelijkheidsmanifesten. De juridische tekst staat op EUR-Lex^[1], en de Commissie publiceert richtlijnen en veelgestelde vragen op haar implementatiepagina^[3]. Voor een overzicht, zie onze Cyber Resilience Act-pagina.

Stap 1: Bepaal de scope en je rol per product

De CRA dekt producten met digitale elementen waarvan het beoogde of redelijkerwijs voorzienbare gebruik een gegevensverbinding met een apparaat of netwerk omvat, inclusief de verwerking van externe gegevens die een product nodig heeft om zijn functies uit te voeren. Producten die onder specifieke sectorale regels vallen, zoals medische hulpmiddelen, motorvoertuigen en burgerluchtvaart, zijn uitgesloten. Standalone SaaS valt over het algemeen onder NIS2 in plaats van de CRA.

• Noteer per product of het binnen de scope valt, en eventuele uitsluitingen waarop je je beroept.
• Bepaal je rol. Een fabrikant ontwikkelt het product of laat het ontwikkelen en brengt het onder zijn eigen naam op de markt. Een importeur brengt het product van een fabrikant buiten de EU op de EU-markt. Een distributeur stelt het verderop in de keten beschikbaar. Een beheerder van open-source software is een rechtspersoon die systematisch vrije en open-source software voor commerciële activiteiten ondersteunt.
• Let op rolveranderingen: een importeur of distributeur die een product van een nieuw merk voorziet of aanzienlijk wijzigt, neemt fabrikantverplichtingen op zich.
• Noteer producten die al op de markt zijn. Ze worden alleen aan alle vereisten onderworpen als ze na 11 december 2027 aanzienlijk worden gewijzigd, maar artikel 14-rapportage is op hen van toepassing.

Stap 2: Classificeer elk product

De meeste producten vallen in de standaardcategorie. Bijlage III vermeldt belangrijke producten. Klasse I omvat besturingssystemen, browsers, wachtwoordbeheerders, VPN's, routers, SIEM-systemen en slimme beveiligingsproducten voor het huis, zoals deursloten en camera's. Klasse II omvat hypervisors en container runtimes, firewalls en inbraakdetectie- of preventiesystemen, en tamper-resistente microprocessors en microcontrollers. Bijlage IV vermeldt kritieke producten: hardwareapparaten met beveiligingskluizen, slimme meterkastgateways, en smartcards en beveiligde elementen.

Uitvoeringsverordening (EU) 2025/2392 van 28 november 2025 geeft de technische beschrijving van elke categorie en is op 21 december 2025 in werking getreden^[2]. Wat telt is de kernfunctionaliteit van het product. Een product dat alleen een vermeld onderdeel integreert, wordt daarom niet automatisch een belangrijk product.

• Vergelijk de kernfunctionaliteit van elk product met de beschrijvingen in de uitvoeringsverordening, niet alleen de korte labels in de bijlagen.
• Schrijf per product een korte motivering, vooral voor grensgevallen.

Stap 3: Beoordeel het risico en koppel de hiaten aan Bijlage I

Artikel 13 vereist een cybersecurityrisicobeoordeling die planning, ontwerp, ontwikkeling, productie, levering en onderhoud informeert, en bepaalt hoe elke vereiste in Bijlage I van toepassing is. Bijlage I Deel I vraagt, samengevat, om producten die zonder bekende uitbuitbare kwetsbaarheden worden geleverd, met een veilige standaardconfiguratie, met beveiligingsupdates (standaard automatisch waar passend), toegangscontrole, vertrouwelijkheid en integriteitsbeveiliging, gegevensminimalisatie, beschikbaarheid, een beperkt aanvalsoppervlak, vermindering van incidentgevolgen, beveiligingslogboeken en veilige gegevensverwijdering.

• Maak een dreigingsmodel van elk product of elke productfamilie voor hardware, firmware, software en back-end.
• Noteer voor elke vereiste in Bijlage I de toepasbaarheid, hoe deze wordt nageleefd, bewijs en resterende hiaat. Rechtvaardig alles wat als niet van toepassing is gemarkeerd.

De bijbehorende sjabloon bevat een checklist voor Bijlage I met alle vereisten van Deel I en Deel II, een classificatiewerkblad en een tijdlijn.

Stap 4: Zet kwetsbaarheidsafhandeling op, inclusief een SBOM

Bijlage I Deel II is van toepassing gedurende de hele ondersteuningsperiode. Fabrikanten moeten componenten documenteren, inclusief een software bill of materials (SBOM) in een gemeenschappelijk machine-leesbaar formaat dat minstens top-level afhankelijkheden omvat; kwetsbaarheden zonder vertraging verhelpen; regelmatig testen; verholpen kwetsbaarheden openbaarmaken; een beleid voor gecoördineerde kwetsbaarheidsopenbaarmaking (CVD) en een contactpunt voor rapportage handhaven; updates veilig distribueren; en beveiligingsupdates gratis verstrekken met adviezen.

• Genereer SBOM's per build (SPDX of CycloneDX) en bewaar ze per release. Je hoeft ze niet te publiceren.
• Stel de ondersteuningsperiode in: minstens vijf jaar tenzij het product naar verwachting korter wordt gebruikt, en zichtbaar voor kopers.
• Publiceer een CVD-beleid en beveiligingscontact, bijvoorbeeld via security.txt, en voer een PSIRT-intake uit met triagestreefwaarden.
• Rapporteer kwetsbaarheden die je in geïntegreerde onderdelen vindt, inclusief open-sourcecode, aan hun onderhouders.

Stap 5: Zorg dat rapportage nu werkt

Sinds 11 september 2026 moeten fabrikanten elke actief misbruikte kwetsbaarheid en elk ernstig incident dat de productbeveiliging betreft, melden via het Single Reporting Platform van ENISA^[4]. Het rapport bereikt tegelijkertijd de coördinerende CSIRT van de lidstaat van de hoofdvestiging en ENISA.

Fase	Actief misbruikte kwetsbaarheid	Ernstig incident
Vroegtijdige waarschuwing	24 uur nadat je ervan op de hoogte bent geraakt	24 uur nadat je ervan op de hoogte bent geraakt
Melding	72 uur nadat je ervan op de hoogte bent geraakt	72 uur nadat je ervan op de hoogte bent geraakt
Eindrapport	14 dagen nadat een corrigerende maatregel beschikbaar is	Een maand na de melding

• Bepaal wie beslist dat een kwetsbaarheid actief wordt misbruikt, en wanneer de klok begint te lopen.
• Registreer je op het platform en oefen een indiening.
• Bereid rapportagesjablonen en een proces voor om getroffen gebruikers in te lichten. Ons draaiboek incidentmelding stemt CRA-rapportage af op NIS2, DORA en AVG.

Stap 6: Kies de route voor conformiteitsbeoordeling

Onder artikel 32 mogen standaardproducten interne controle gebruiken (module A). Belangrijke klasse I-producten mogen module A alleen gebruiken als geharmoniseerde normen, gemeenschappelijke specificaties of een certificeringsschema op niveau 'substantieel' volledig zijn toegepast; anders hebben zij modules B en C of module H met een aangemelde instantie nodig. Klasse II-producten hebben altijd een derde partij nodig. Kritieke producten moeten een Europees cybersecurity-certificeringsschema gebruiken waar een gedelegeerde handeling dit vereist, anders gelden de klasse II-routes. Belangrijke vrije en open-source producten mogen module A gebruiken als hun technische documentatie openbaar is.

• Volg geharmoniseerde normen. Op het moment van schrijven plant de Commissie de eerste oplevering in 2026 en meer in 2027^[3].
• Als je een aangemelde instantie nodig hebt, reserveer dan vroeg. Hun regels gelden vanaf 11 juni 2026 en de capaciteit zal rond december 2027 krap zijn.

Stap 7: Stel de technische documentatie samen

Artikel 31 en Bijlage VII vereisen documentatie over het product en het beoogde doel, ontwerp en productie, het proces voor kwetsbaarheidsafhandeling, de SBOM, de risicobeoordeling, de motivering van de ondersteuningsperiode, toegepaste normen, testrapporten en de conformiteitsverklaring. Bewaar deze tien jaar na het op de markt brengen, of voor de ondersteuningsperiode als deze langer is. Bijlage II bepaalt de gebruikersinformatie, inclusief het kwetsbaarheidscontactpunt en het einde van de ondersteuning.

In Secrato wordt deze stap gekoppeld aan Beleid en bewijs, waar elk controleresultaat van bijlage I en het bijbehorende bewijs verband houden met de documentatieset van het product.

Stap 8: Verklaar conformiteit, breng CE-markering aan en onderhoud

Na de beoordeling stel je de EU-conformiteitsverklaring op (Artikel 28, Bijlage V) en bevestig je de CE-markering (Artikel 30). Voor software kan deze op de verklaring of de bijbehorende website worden geplaatst. Naleving gaat door tijdens de ondersteuningsperiode: blijf kwetsbaarheden afhandelen, houd elke beveiligingsupdate minstens tien jaar of de resterende ondersteuningsperiode beschikbaar als deze langer is, en beoordeel of wijzigingen substantiële wijzigingen zijn die een nieuwe beoordeling vereisen.

• Informeer importeurs en distributeurs over wat zij moeten controleren voordat zij verkopen.
• Beoordeel de risicobeoordeling en de bijlage I-matrix opnieuw met elke grote release, en voer jaarlijks een managementbeoordeling uit.

Hoe dit aansluit op andere frameworks

De CRA regelt het product; NIS2, ISO/IEC 27001 en CyFun regelen de organisatie. Veilige ontwikkeling, kwetsbaarheidsbeheer, leveranciersbeheer en incidentrespons onder ISO/IEC 27001 Bijlage A of NIS2 artikel 21 leveren nog steeds veel van het procesbewijs dat de CRA verwacht. Tot geharmoniseerde CRA-normen bestaan, zijn IEC 62443-4-1 en 4-2 (industrieel) en ETSI EN 303 645 (consument-IoT) nuttige referenties.

Veelgestelde vragen

Geldt de CRA voor producten die we al verkopen?

Producten die vóór 11 december 2027 in de handel zijn gebracht, hoeven alleen aan de volledige vereisten te voldoen als zij daarna substantieel zijn gewijzigd. Artikel 14-rapportage is op hen van toepassing vanaf 11 september 2026.

Moeten we onze SBOM publiceren?

Nee. Het maakt deel uit van de technische documentatie en moet op verzoek aan markttoezichtautoriteiten worden verstrekt.

We ontwikkelen alleen open-source software. Zijn we een fabrikant?

Niet noodzakelijk. Open-source software buiten een commerciële activiteit valt buiten het toepassingsbereik. Een stichting die dit systematisch voor commercieel gebruik ondersteunt, kan een beheerder zijn, met een lichter regime en geen boetes. Als je het product zelf te gelde maakt, ben je waarschijnlijk een fabrikant.

Valt SaaS onder de werkingssfeer?

Standalone SaaS is dat over het algemeen niet. Een cloud-backend waarvan een apparaat afhankelijk is om zijn functies uit te voeren, maakt deel uit van dat product.

Welke tools helpen softwarefabrikanten zich voor te bereiden op de CRA?

Begin met onze gratis CRA-readiness checklist om te zien waar elk product staat. Een GRC-platform zoals Secrato koppelt vervolgens de CRA-vereisten aan controls, eigenaren en bewijzen, en laat je werk dat al voor ISO/IEC 27001 of NIS2 is gedaan, hergebruiken.