De EU Cyber Resilience Act: een praktische gids voor het mkb

Een veiligere digitale toekomst voor het mkb

Stel dat elke tool waar uw bedrijf op draait, van uw CRM tot de salarisadministratie en de chatapp van uw team, eerst moest bewijzen dat hij veilig is voordat u hem kocht.

Dat is wat de EU Cyber Resilience Act (CRA) naar de markt brengt. Hij verandert hoe kleine en middelgrote bedrijven in heel Europa hun software en verbonden apparaten kiezen, kopen en vertrouwen.

U hoeft geen cybersecurityexpert te zijn om ervan te profiteren. U moet weten welke vragen u stelt, welke waarschuwingssignalen u herkent, en hoe CRA-compliance van een juridisch vinkje een concurrentievoordeel kan worden. Deze gids geeft u alle drie.

Nog te veel producten worden geleverd met zwakke beveiliging: verouderde componenten, standaardwachtwoorden, geen langdurige ondersteuning. Als aanvallers die gaten uitbuiten, betaalt het mkb vaak de hoogste prijs in uitval, dataverlies en reputatieschade.

De CRA draait dat om. Fabrikanten moeten aantonen dat hun producten veilig zijn voordat ze op de EU-markt komen. Voor u betekent dat sterkere garanties van leveranciers en een stevige basis om bewijs te eisen voordat u tekent.

Denk aan de CE-markering op fysieke producten. Zoals dat label veiligheid aangeeft, wordt CRA-conformiteit het vertrouwenssignaal voor digitale producten. Beveiliging is niet langer optioneel.

Wat deze wet anders maakt

De AVG beschermt persoonsgegevens. De CRA gaat over de beveiliging van het product zelf, vanaf het ontwerp en gedurende de hele levensduur. Hij verplicht fabrikanten om:

• kwetsbaarheden snel te verhelpen en beveiligingsupdates gratis te leveren
• open te zijn over beveiligingsupdates en over hoe lang een product wordt ondersteund
• de componenten van derden in hun producten te documenteren
• conformiteit aan te tonen voordat het product wordt verkocht

Voor het mkb betekent dit dat u uw leveranciers kunt aanspreken en veiligere producten mag verwachten.

Het mkb als productmaker

De CRA is niet alleen iets wat u van uw leveranciers mag verwachten. Hij geldt ook voor u als u producten met digitale elementen maakt en in de EU verkoopt. Bouwt uw bedrijf hardware, verwerkt het software in apparaten of ontwikkelt het software die u verkoopt, dan hebt u dezelfde verplichtingen als grote fabrikanten. Importeurs en distributeurs die producten doorverkopen, hebben eigen, lichtere plichten, tenzij ze het product onder hun eigen naam verkopen.

De eerste stap is uw toeleveringsketen. Als fabrikant moet u zorgvuldigheid betrachten bij elk component dat u integreert, opensourcebibliotheken inbegrepen. Is het component van een leverancier onveilig, dan wordt dat risico uw risico.

De tweede stap is naar binnen kijken. De CRA maakt van security by design een wettelijke eis in plaats van goede praktijk. Dat omvat:

• uw ontwikkel- of integratieprocessen evalueren
• kwetsbaarheden snel vinden en patchen
• documenteren hoe beveiliging in elke fase van uw productlevenscyclus is ingebouwd

De praktische stappen komen verderop aan bod.

De CRA in het kort

Tijdlijn

Voor mkb-kopers: vraag uw leveranciers nu hoe ze zich voorbereiden. Vanaf 11 december 2027 mogen producten die niet aan de CRA voldoen niet meer op de EU-markt worden gebracht.

Voor wie het geldt

De CRA dekt producten met digitale elementen: software en hardware die verbinding maken met een apparaat of een netwerk. Veel tools die het mkb elke dag gebruikt, vallen eronder:

• geïnstalleerde bedrijfssoftware, zoals boekhoud-, CRM- en kantoorapplicaties
• clients voor samenwerking en videovergaderen
• laptops, telefoons, routers en printers
• beveiligingssoftware, zoals VPN-clients en wachtwoordmanagers

Pure SaaS valt buiten de CRA; veel cloudaanbieders vallen in plaats daarvan onder NIS2. Maar een cloudbackend die een product nodig heeft om te werken, zoals de server achter de app van een slim slot, telt als onderdeel van het product. Downloadbare apps en agents die bij een SaaS-dienst horen, vallen in de regel ook onder de CRA.

Dit zijn de partijen waar de CRA invloed op heeft:

Productklassen

De CRA verdeelt producten met digitale elementen in vier categorieën. Hoe hoger het risico, hoe strenger de conformiteitsbeoordeling. Hier is een overzicht, met per categorie wat u uw leverancier vraagt:

Standaard: de categorie met het laagste risico

De Europese Commissie schat dat ongeveer 90% van de producten onder de CRA in de standaardcategorie valt. Ze dragen minder inherent risico dan de genoemde categorieën, maar moeten nog steeds aan alle essentiële cyberbeveiligingseisen van de CRA voldoen.

Voorbeelden van standaardproducten die het mkb koopt:

• algemene software: kantoorpakketten, tools voor notities en projectmanagement, boekhoud- en factuursoftware, e-mailclients, chat- en videovergaderapps, foto- en videobewerking, en geïnstalleerde CRM-, HR- en ERP-software
• kantoorhardware: laptops, desktops, tablets, smartphones, monitoren, muizen, toetsenborden en webcams
• slimme kantoorapparaten zonder beveiligingsfunctie: slimme verlichting, thermostaten, klimaatregelingen, printers en verbonden projectoren
• consumentachtige apparaten die op het werk worden gebruikt: smart-tv’s, verbonden whiteboards en vergadersystemen, en digital signage

Een standaardproduct kan nog steeds componenten van klasse I bevatten. Een laptop is een standaardproduct, maar het besturingssysteem dat erop draait is zelf een product in klasse I.

Fabrikanten van standaardproducten beoordelen de conformiteit zelf. Dat verlaagt de lat niet: uw leveranciers hebben nog steeds security by design, kwetsbaarheidsbeheer en documentatie nodig. Gebruik de leverancierschecklist hieronder om om bewijs te vragen.

Belangrijk, klasse I: verhoogd risico

Producten in klasse I (bijlage III, deel I) vervullen beveiligingsfuncties of beheren de toegang tot netwerken en systemen, dus een compromittering heeft bredere gevolgen dan bij een standaardproduct. De lijst:

• software en hardware voor identiteitsbeheer en privileged access management, inclusief authenticatielezers zoals badge- en biometrische lezers
• browsers, wachtwoordmanagers en antimalwaresoftware
• VPN-producten, netwerkbeheersystemen en SIEM-systemen
• bootmanagers, PKI en software voor het uitgeven van certificaten, fysieke en virtuele netwerkinterfaces, en besturingssystemen
• routers, modems en switches
• microprocessors, microcontrollers, ASIC’s en FPGA’s met beveiligingsfuncties
• virtuele assistenten voor het slimme huis, en beveiligingsproducten voor het slimme huis zoals slimme sloten, beveiligingscamera’s, babyfoons en alarmsystemen
• verbonden speelgoed met sociale interactie of locatietracking, en wearables die de gezondheid monitoren of voor kinderen bedoeld zijn

Een fabrikant kan een product in klasse I alleen zelf beoordelen als hij geharmoniseerde normen, gemeenschappelijke specificaties of Europese cyberbeveiligingscertificering volledig toepast. Anders moet er een aangemelde instantie bij worden betrokken. Er zijn nog maar weinig geharmoniseerde normen vermeld (zie ons overzicht van de geharmoniseerde CRA-normen), dus reken erop dat veel producten in klasse I in eerste instantie langs een aangemelde instantie gaan.

Koopt u een product in klasse I, controleer dan of de leverancier zich verbindt om het op termijn veilig te houden: een CE-markering en EU-conformiteitsverklaring, regelmatige beveiligingsupdates, een duidelijke ondersteuningsperiode en end-of-lifebeleid, en veilige standaardinstellingen zoals sterke authenticatie en versleuteling. Vraag waar uw bedrijfsgegevens worden opgeslagen, hoe lang het product wordt ondersteund, en hoe snel de leverancier eerdere problemen heeft opgelost. Kies leveranciers die verantwoordelijkheid nemen voor beveiliging, niet alleen voor functies.

Belangrijk, klasse II: hoog risico

Klasse II (bijlage III, deel II) is een korte lijst:

• hypervisors en container-runtimesystemen
• firewalls en systemen voor inbraakdetectie en -preventie, waaronder next-generation firewalls en UTM-appliances
• manipulatiebestendige microprocessors en microcontrollers

Fabrikanten kunnen deze producten niet zelf beoordelen, ook niet als ze geharmoniseerde normen toepassen. Ze hebben een aangemelde instantie nodig, of een Europees cyberbeveiligingscertificaat op zekerheidsniveau “substantieel” of hoger.

Koopt u een product in klasse II, vraag dan om de CE-markering, de EU-conformiteitsverklaring en de gegevens van de aangemelde instantie. De verklaring laat zien dat de fabrikant de cyberbeveiligingsrisico’s van het product heeft beoordeeld en zich verbindt om het met updates veilig te houden. Kan een leverancier die niet leveren zodra de CRA geldt, zoek dan een ander product.

Kritieke producten: de hoogste zekerheid

Bijlage IV noemt drie soorten producten:

• hardwareapparaten met beveiligingsboxen
• gateways voor slimme meters en andere apparaten voor geavanceerde beveiligingsdoeleinden, waaronder veilige cryptoverwerking, zoals hardware security modules (HSM’s)
• smartcards en vergelijkbare apparaten, waaronder secure elements

De Commissie kan voor deze producten via een gedelegeerde handeling een Europees cyberbeveiligingscertificaat verplicht stellen, bijvoorbeeld onder EUCC, de regeling op basis van Common Criteria. Waar dat niet is gebeurd, volgen kritieke producten de route van klasse II.

Koop kritieke producten alleen als de leverancier geldige certificering kan tonen. Controleer of het certificaat actueel is, of het product gedurende de volledige ondersteuningsperiode beveiligingsupdates krijgt, en of de leverancier een plan heeft om problemen snel op te lossen. Deze apparaten beschermen uw gevoeligste gegevens en bedrijfsfuncties.

CRA-conforme producten kiezen

Leverancierschecklist voor het mkb

Gebruik deze checklist in gesprekken met leveranciers. CRA-conformiteit, regelmatige updates en kwetsbaarheidsbeheer zijn niet onderhandelbaar. De rest versterkt uw positie.

1. CRA-conformiteit

• De leverancier levert een EU-conformiteitsverklaring en het product heeft de CE-markering.
• De categorie van het product is duidelijk: standaard, klasse I, klasse II of kritiek.
• Waar een certificaat verplicht is, is het actueel en dekt het de versie die u koopt.

2. Beveiligingsupdates

• Beveiligingsupdates komen regelmatig en gratis.
• De ondersteuningsperiode is vermeld. Voor de meeste producten eist de CRA ten minste vijf jaar.
• Updates kunnen automatisch worden geïnstalleerd en zijn digitaal ondertekend.

3. Kwetsbaarheidsbeheer

• De leverancier heeft een formeel proces om kwetsbaarheden te melden en te verhelpen.
• Er is een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden en een beveiligingscontact gepubliceerd.
• Kwetsbaarheden worden snel gecommuniceerd en gepatcht.
• Bonus: de leverancier heeft een bugbountyprogramma.

4. Gegevensbescherming en privacy

• Het is duidelijk waar uw bedrijfsgegevens worden opgeslagen.
• Het product ondersteunt uw verplichtingen onder de AVG.
• Gegevens zijn versleuteld in opslag en tijdens transport.

5. Ingebouwde beveiligingsfuncties

• Veilige standaardinstellingen: geen standaardwachtwoorden, meerfactorauthenticatie beschikbaar, versleuteling aan.
• Rolgebaseerde toegangscontrole is beschikbaar.
• Er zijn logging en audit trails.

6. Verantwoording en documentatie

• De leverancier biedt beveiligingsrichtlijnen en gebruikersinstructies.
• Het end-of-lifebeleid is duidelijk.
• De leverancier neemt verantwoordelijkheid voor beveiliging, niet alleen voor functies.

7. Interoperabiliteit en overdraagbaarheid

• Het product ondersteunt open standaarden.
• U kunt uw gegevens exporteren als u van leverancier wisselt.
• Het product werkt samen met uw bestaande IT-systemen.

8. Onafhankelijke zekerheid (optioneel maar aanbevolen)

• De leverancier heeft certificeringen van derden, zoals ISO/IEC 27001, SOC 2 of, voor industriële producten, IEC 62443.
• De leverancier deelt rapporten van penetratietests of beveiligingsaudits.
• Resultaten van beveiligingstests zijn gepubliceerd of te verifiëren.

Een stap verder: controleer secure-by-designpraktijken

Wilt u meer dan basale CRA-conformiteit, vraag dan om meer bewijs dat het product secure by design is gebouwd:

• Vraag naar het beleid voor de veilige softwareontwikkellevenscyclus (SSDLC) van de leverancier. Dat hoort de beveiligingsactiviteiten in detail te beschrijven. Vraag per activiteit om bewijs dat die het afgelopen jaar is uitgevoerd.
• Vraag hoe dreigingen tijdens het ontwerp worden geïdentificeerd en beperkt. Threat modeling hoort deel uit te maken van het SSDLC-beleid.
• Vraag om de software bill of materials (SBOM) en laad die in een gratis tool als OWASP Dependency-Track om bekende kwetsbaarheden in de vermelde componenten te zien. Fabrikanten moeten een SBOM opstellen maar hoeven die niet te publiceren, dus sommigen delen hem alleen onder NDA.
• Vraag om het incidentresponsplan, inclusief hoe de leverancier voldoet aan de vroegtijdige waarschuwing binnen 24 uur die de CRA eist voor actief uitgebuite kwetsbaarheden en ernstige incidenten.
• Vraag of het product bekende kritieke kwetsbaarheden heeft en hoe die worden aangepakt. De CRA eist dat producten worden geleverd zonder bekende uitbuitbare kwetsbaarheden.

Deze controles vertellen u of beveiliging vanaf het begin deel uitmaakte van het product of er achteraf op is geschroefd.

Waarschuwingssignalen

Behandel een product als hoog risico, en kijk naar alternatieven, als u een van deze signalen ziet:

Geen bewijs van CRA-conformiteit

• De leverancier kan geen EU-conformiteitsverklaring of CE-markering leveren zodra de CRA geldt.
• Certificering is verouderd, onvolledig of onduidelijk.

Geen transparantie

• Er is geen documentatie over hoe kwetsbaarheden worden afgehandeld.
• Er is geen gepubliceerd beveiligingscontact, zoals een security@-adres, een PSIRT of een openbaarmakingsbeleid.
• Er is geen duidelijke verklaring over CRA-conformiteit.

Verouderde of niet-ondersteunde software en hardware

• Apparaten worden geleverd met een besturingssysteem dat end-of-life is of met ongepatchte bibliotheken.
• Er is geen toezegging voor beveiligingsupdates gedurende de ondersteuningsperiode van het product.
• Release notes ontbreken of zijn vaag.

Een slecht updateproces

• Updates moeten met de hand worden geïnstalleerd, komen van een willekeurige website of zijn niet digitaal ondertekend.
• Er is geen automatisch of veilig updatemechanisme.
• De leverancier zegt niet hoe lang er updates komen.

Zwakke of onveilige standaardinstellingen

• Het product wordt geleverd met standaardwachtwoorden die niet te wijzigen zijn.
• Meerfactorauthenticatie wordt niet ondersteund.
• Het product gebruikt verouderde protocollen zoals SSL of TLS 1.0.

Geen veilige ontwikkelpraktijken

• Er is geen bewijs van security by design of veilig programmeren.
• De leverancier kan niet uitleggen hoe hij op kwetsbaarheden test.
• Penetratietests, code reviews of threat modeling worden nergens genoemd.

Geen onafhankelijke zekerheid

• Er is geen ISO/IEC 27001 of, voor industriële producten, IEC 62443, en geen beveiligingsbeoordeling door een derde partij, zelfs geen vrijwillige.
• De leverancier wuift compliancevragen weg als “niet nodig” of “te duur”.

Riskant zakelijk gedrag

• Er is geen duidelijk proces voor het afhandelen van incidenten of datalekken.
• De leverancier heeft een geschiedenis van het negeren van kwetsbaarheidsmeldingen of het uitstellen van fixes.

Verplichtingen voor mkb-bedrijven die verbonden producten maken

Zoals de inleiding uitlegde, geldt de CRA voor elke fabrikant die producten met digitale elementen in de EU verkoopt, niet alleen voor softwareleveranciers. Mkb-bedrijven die hardware bouwen, software in apparaten verwerken of eigen software verkopen, hebben dezelfde verplichtingen als grote fabrikanten. En het gaat veel verder dan inkoop: het raakt ontwerp, ontwikkeling, productie en onderhoud na verkoop.

De rest van deze gids gaat technischer in op de details voor productontwikkelteams.

Kernverplichtingen voor beveiliging

Het doel van de CRA is dat elk product met digitale elementen op de EU-markt secure by design is gebouwd en na verkoop een redelijke periode wordt ondersteund. Fabrikanten moeten bewijs van hun beveiligingsactiviteiten kunnen tonen, van governance en ontwerp tot end-of-life.

De CRA verwacht gevestigde beveiligingspraktijken gedurende de hele ontwikkellevenscyclus. Hier is een voorbeeld van een veilige softwareontwikkellevenscyclus (SSDLC) met de bijbehorende beveiligingsactiviteiten:

Security by design

Beveiliging moet vanaf het eerste ontwerp deel uitmaken van het product, niet later worden toegevoegd. Fabrikanten passen principes van secure by design en secure by default toe in de hele ontwikkellevenscyclus. Dat omvat:

• een cyberbeveiligingsrisicobeoordeling uitvoeren en beveiligingseisen vastleggen tijdens planning en architectuur, bijvoorbeeld met threat modeling
• veilige programmeerpraktijken en geautomatiseerd testen toepassen
• leveren met veilige standaardconfiguraties die de blootstelling minimaliseren

U documenteert deze praktijken in de technische documentatie voor uw conformiteitsbeoordeling.

Kwetsbaarheidsbeheer

Beveiliging na de release telt even zwaar als veilige ontwikkeling. Fabrikanten hebben een proces voor kwetsbaarheidsbeheer nodig dat het volgende omvat:

• de componenten in het product identificeren en monitoren op bekende kwetsbaarheden, in uw eigen code en in componenten van derden
• beveiligingsadviezen publiceren en kwetsbaarheden zonder vertraging verhelpen
• beveiligingsupdates gratis verspreiden, waar mogelijk los van functionele updates

De ondersteuningsperiode moet aansluiten bij hoe lang het product naar verwachting in gebruik is, en moet ten minste vijf jaar zijn, tenzij het product naar verwachting korter in gebruik is. Elke beveiligingsupdate moet ten minste tien jaar beschikbaar blijven, of voor de rest van de ondersteuningsperiode als die langer is.

Transparantie

Fabrikanten moeten zorgen voor:

• een SBOM in een algemeen gebruikt, machineleesbaar formaat, die ten minste de afhankelijkheden op het hoogste niveau dekt. Die maakt deel uit van de technische documentatie, dus u hoeft hem niet te publiceren.
• technische documentatie die de beveiligingsfuncties van het product beschrijft en hoe de conformiteit is beoordeeld
• een EU-conformiteitsverklaring
• gebruikersinformatie, inclusief de einddatum van de ondersteuningsperiode en één contactpunt voor kwetsbaarheidsmeldingen

Producten krijgen de CE-markering volgens de gebruikelijke CE-regels: op het product waar mogelijk, anders op de verpakking en in de documentatie. Voor software staat de CE-markering in de EU-conformiteitsverklaring of op de website die bij de software hoort.

Transparantie strekt zich uit tot de toeleveringsketen: u moet zorgvuldigheid betrachten zodat componenten van derden, open source inbegrepen, de beveiliging van het product niet in gevaar brengen.

Meldplicht

Sinds 11 september 2026 moeten fabrikanten actief uitgebuite kwetsbaarheden en ernstige incidenten melden via het centrale meldplatform van ENISA. De melding gaat naar het nationale CSIRT dat als coördinator is aangewezen en naar ENISA:

• een vroegtijdige waarschuwing binnen 24 uur nadat u ervan op de hoogte bent
• een melding met meer details binnen 72 uur
• een eindverslag binnen 14 dagen nadat er een fix voor een kwetsbaarheid beschikbaar is, of binnen een maand voor een ernstig incident

U moet ook getroffen gebruikers informeren en hun vertellen hoe ze het probleem kunnen beperken. Deze verplichtingen gelden voor alle producten met digitale elementen, ook voor producten die alleen uit software bestaan, en ook voor producten die al vóór december 2027 op de markt waren.

De CRA verschuift cybersecurity van reactief naar proactief. Security by design, gestructureerd kwetsbaarheidsbeheer, transparantie en snelle meldingen worden de standaard voor het verkopen van digitale producten in de EU.

Een praktisch stappenplan voor compliance

Losse beveiligingsfixes brengen u niet tot CRA-compliance. U hebt een gestructureerde, meetbare aanpak voor veilige softwareontwikkeling nodig. Volwassenheidsmodellen voor de SSDLC zijn een van de effectiefste manieren om daar te komen, bijvoorbeeld:

• OWASP SAMM (Software Assurance Maturity Model)
• BSIMM (Building Security In Maturity Model)

Deze frameworks helpen u om:

• uw huidige softwarebeveiliging te beoordelen
• realistische verbeterdoelen te stellen
• uw ontwikkelpraktijken af te stemmen op de kernverplichtingen van de CRA: security by design, kwetsbaarheidsbeheer, transparantie en meldplicht

Met een volwassenheidsmodel in uw stappenplan worden deze principes onderdeel van hoe uw engineeringteams werken, in plaats van een reeks regelgevende vinkjes.

OWASP SAMM: gestructureerde begeleiding voor veilige ontwikkeling

Het diagram hieronder toont de beveiligingspraktijken die OWASP SAMM definieert.

Het OWASP SAMM-model. Bron: owaspsamm.org, CC BY-SA 4.0.

De modulaire opbouw van SAMM ondersteunt:

• een nulmeting van de huidige beveiligingsvolwassenheid van uw organisatie
• doelniveaus van volwassenheid op basis van risico, bedrijfsdoelen en CRA-eisen
• een stappenplan op maat om de gevonden hiaten te dichten
• concrete richtlijnen voor activiteiten in governance, ontwerp, implementatie, verificatie en beheer

Die flexibiliteit maakt SAMM geschikt voor de voorbereiding op de CRA: u kunt verbeteringen prioriteren op productklasse, marktblootstelling en de capaciteiten die u al hebt.

Stap 1: Toets uw productportfolio aan de reikwijdte van de CRA

Begin met vast te stellen welke van uw producten producten met digitale elementen zijn onder de CRA.

• Neem producten die alleen uit software bestaan mee, net als hardware met ingebouwde software.
• Deel elk product in een categorie in: standaard, klasse I, klasse II of kritiek.
• Bepaal welke producten een aangemelde instantie nodig hebben en voor welke interne controle (module A) volstaat.

Dit legt de grenzen van uw compliance vast en laat zien waar u eerst op moet focussen, op basis van risico en regelgevende blootstelling.

Stap 2: Vind de hiaten in uw ontwikkel- en aftersalesprocessen

Gebruik SAMM om uw huidige softwarebeveiliging te beoordelen over de vijf bedrijfsfuncties: Governance, Design, Implementation, Verification en Operations.

• Voer een nulmeting van de volwassenheid uit met het scoresysteem van SAMM.
• Identificeer ontbrekende of zwakke praktijken, zoals geen threat modeling, traag patchen of onduidelijke rollen bij incidentrespons.
• Let extra op verplichtingen na de verkoop, zoals het monitoren van kwetsbaarheden en ondersteuningsperiodes, die vaak over het hoofd worden gezien.

De website van OWASP SAMM heeft richtlijnen om te beginnen, plus gratis tools om uw softwarebeveiligingsvolwassenheid te beoordelen, te visualiseren en te communiceren. Daarmee vindt u makkelijker hiaten, plant u verbeteringen en volgt u de voortgang. De grafiek hieronder toont een voorbeeldbeoordeling, met de huidige sterke punten en de geplande voortgang over vier kwartalen.

Stap 3: Voer veilige ontwikkelpraktijken in

Stel op basis van uw gapanalyse een doelniveau van volwassenheid vast voor elke bedrijfsfunctie en begin met de verbeteringen met de hoogste prioriteit.

• Begin met de gebieden die direct aan CRA-verplichtingen gekoppeld zijn, zoals standaarden voor veilig programmeren, het genereren van SBOM’s en veilige updatemechanismen.
• Gebruik de richtlijnen van SAMM om beveiliging in het dagelijkse ontwikkelwerk in te bouwen.
• Stem de diepgang van maatregelen en documentatie af op de productklasse. Kritieke producten hebben van beide meer nodig.

Stap 4: Bereid openbaarmaking van kwetsbaarheden en patchbeheer voor

De CRA eist een proces voor kwetsbaarheidsbeheer en tijdige updates.

• Publiceer een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden (CVD).
• Definieer interne workflows voor triage, herstel en communicatie, inclusief de meldtermijn van 24 uur.
• Zorg dat de levering van uw patches veilig, betrouwbaar en gedocumenteerd is.

De bedrijfsfunctie Operations van SAMM beschrijft praktijken voor incidentbeheer en patchen in detail.

Stap 5: Train uw teams op de doorlopende verplichtingen

Compliance is geen eenmalige gebeurtenis. Het vraagt voortdurende aandacht en duidelijk eigenaarschap.

• Train engineering-, product- en supportteams op CRA-verplichtingen en veilige ontwikkelpraktijken.
• Neem CRA-onderwerpen zoals CE-markering, meldtermijnen en documentatie op in de onboarding en in doorlopende trainingen.
• Gebruik de bedrijfsfunctie Governance van SAMM om rollen, verantwoordelijkheden en metrics te formaliseren.

Onze EU CRA Practitioner Training behandelt deze verplichtingen voor engineering-, product- en complianceteams. Wilt u het niet alleen doen, dan doorloopt de EU CRA Compliance Journey deze stappen samen met u, van de productclassificatie tot de EU-conformiteitsverklaring.

Opensourcesoftware

De CRA reguleert de ontwikkeling van open source zelf niet. De verplichtingen gelden als software in het kader van een commerciële activiteit op de markt wordt aangeboden. Vrijwilligers en gemeenschappen die code delen zonder commercieel oogmerk, worden niet direct geraakt.

Niet-commerciële open source

Opensourcesoftware die zonder commercieel oogmerk wordt ontwikkeld en gedeeld, zoals hobbyprojecten, onderzoekstools of communitybibliotheken op GitHub, valt buiten de CRA. Bijdragers hebben geen conformiteitsbeoordelingen of documentatie nodig.

Commercieel gebruik van open source

Een bedrijf dat open source integreert in een product dat het in de EU verkoopt, is verantwoordelijk voor de CRA-compliance van het hele product, de opensourcedelen inbegrepen. Het moet zorgvuldigheid betrachten bij deze componenten, hun kwetsbaarheden afhandelen en ze documenteren. De aansprakelijkheid ligt bij het bedrijf dat het product op de markt brengt, niet bij de individuele bijdrager. Vindt en verhelpt u een kwetsbaarheid in een opensourcecomponent, dan moet u die ook melden en de fix delen met de beheerders van het project.

Opensourcesoftwarestewards

De CRA introduceert de opensourcesoftwaresteward: een rechtspersoon, anders dan een fabrikant, die de ontwikkeling van opensourcesoftware voor commercieel gebruik stelselmatig ondersteunt en levensvatbaar houdt. Stichtingen als de Eclipse Foundation en de Linux Foundation zijn typische voorbeelden, net als bedrijven die opensourceprojecten hosten en onderhouden.

Stewards hebben een licht regime. Ze moeten:

• een cyberbeveiligingsbeleid opstellen en documenteren dat kwetsbaarheidsbeheer dekt
• samenwerken met markttoezichtautoriteiten
• actief uitgebuite kwetsbaarheden en ernstige incidenten melden, voor zover ze bij de ontwikkeling betrokken zijn

Stewards voeren geen conformiteitsbeoordelingen uit en brengen geen CE-markering aan. Dat verandert als een organisatie de software zelf in het kader van een commerciële activiteit aanbiedt, bijvoorbeeld door er geld voor te vragen. Ze wordt dan fabrikant, met de volledige set verplichtingen.

Niet elk opensourceproject heeft een steward. De CRA legt individuele bijdragers geen verplichtingen op, maar maakt bedrijven volledig verantwoordelijk voor de open source die ze leveren. Daardoor gaan de kwaliteit, transparantie en het onderhoud van opensourcecomponenten zwaarder wegen als bedrijven ze kiezen.

Veelgemaakte fouten en hoe u ze voorkomt

De CRA stelt duidelijke verwachtingen voor veilige ontwikkeling en levenscyclusbeheer, maar veel organisaties struikelen bij de invoering. De meeste misstappen komen voort uit het behandelen van de CRA als checklist in plaats van als een verandering in hoe software wordt gebouwd, onderhouden en bestuurd. Hier zijn drie veelgemaakte fouten, en hoe OWASP SAMM u helpt ze te voorkomen.

1. De CRA behandelen als eenmalig project

Veel teams benaderen de CRA als een compliancesprint vóór een deadline, zonder beveiligingspraktijken voor de lange termijn op te bouwen. Dat leidt tot oppervlakkige fixes die na verloop van tijd vervallen en producten na de release kwetsbaar laten.

SAMM bouwt continue verbetering in. Met de volwassenheidsscores volgt u de voortgang in de tijd, stelt u doelen die met uw producten meegroeien, en beoordeelt u uw praktijken opnieuw als producten en dreigingen veranderen. Met SAMM in uw SSDLC wordt CRA-compliance een doorlopend proces.

2. Alles aan engineering overlaten

Beveiliging komt vaak alleen bij engineering terecht, zonder juridische zaken, inkoop of productmanagement. Dat creëert blinde vlekken in aansprakelijkheid, leveranciersrisico en marktverplichtingen.

De bedrijfsfunctie Governance van SAMM maakt beveiliging een afdelingsoverstijgende inspanning. Ze helpt u rollen en verantwoordelijkheden over afdelingen heen te definiëren, juridische, inkoop- en productteams op één lijn te brengen met de beveiligingsdoelen, en elke CRA-verplichting, zoals CE-markering, meldplicht en zekerheid over leveranciers, een duidelijke eigenaar te geven. Beveiliging is een verantwoordelijkheid van het hele bedrijf, en engineering is daar één deel van.

3. De documentatie onderschatten

Teams richten zich vaak op technische maatregelen en verwaarlozen de documentatie die de CRA eist, waaronder de risicobeoordeling, SBOM’s, procedures voor kwetsbaarheidsbeheer en de conformiteitsverklaring.

SAMM koppelt documentatie aan elke bedrijfsfunctie:

• Design en Implementation leggen architectuurbeslissingen en veilige programmeerpraktijken vast.
• Verification registreert testresultaten en bewijs voor de conformiteitsbeoordeling.
• Operations houdt patchlogs, incidentrapporten en ondersteuningsperiodes bij.

De documentatie groeit dan mee met het werk, in plaats van onder druk te worden geschreven vlak voor een beoordeling.

Vooruitblik

De CRA is onderdeel van een breder pakket EU-regels. NIS2 dekt de cyberbeveiliging van essentiële en belangrijke entiteiten, en de AI Act regelt betrouwbare kunstmatige intelligentie. Ze hangen ook samen: een AI-systeem met een hoog risico dat aan de essentiële eisen van de CRA voldoet, wordt geacht aan de cyberbeveiligingseis van de AI Act te voldoen.

Voor bedrijven is die samenloop een kans. Wie CRA-praktijken vroeg invoert, met ingebouwde beveiliging, transparantie en levenscyclusbeheer, kan zich als betrouwbare leverancier positioneren terwijl concurrenten zich vóór december 2027 nog moeten haasten.

Belangrijkste punten

De CRA bepaalt uw toegang tot de EU-markt

• Vanaf 11 december 2027 is CRA-conformiteit een voorwaarde om producten op de EU-markt te brengen.
• Niet-conforme producten riskeren uit de handel te worden genomen, terugroepacties en boetes tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet.
• De meldplicht geldt nu al.
• Vroeg voorbereiden geeft u tijd om secure-by-designpraktijken op te bouwen in plaats van op het laatste moment fixes door te drukken.

Gebruik een gestructureerde aanpak en een volwassenheidsmodel als SAMM

• Ad-hocbeveiliging komt niet door een conformiteitsbeoordeling. De CRA eist systematische, aantoonbare praktijken.
• OWASP SAMM helpt u uw huidige situatie te beoordelen, verbeterdoelen te stellen en een stappenplan op te bouwen dat aansluit op de CRA-verplichtingen.
• Een volwassenheidsmodel verspreidt beveiliging over teams en de hele levenscyclus, in plaats van het bij één team te laten of op incidenten te reageren.

Kies componenten en leveranciers op een nieuwe manier

• U bent verantwoordelijk voor elk component in uw product, inclusief open source en software van derden.
• Beoordeel leveranciers en bibliotheken op beveiliging, onderhoudsactiviteit en aansluiting op de CRA.
• Reken op meer vragen over SBOM’s, licenties en openbaarmaking van kwetsbaarheden, zowel van uw klanten als aan uw leveranciers.

Wilt u weten waar u staat? Doe de gratis EU CRA Self Assessment of plan een gratis EU CRA Strategy Call.

Begrippenlijst

Nuttige bronnen

• Wettekst van de CRA op EUR-Lex: de officiële publicatie van de verordening.
• EU-cyberbeveiligingsbeleid: het overzicht van de Europese Commissie, inclusief de CRA en NIS2.
• CRA-FAQ op de CRA-hub van de ORC WG: een door de gemeenschap onderhouden FAQ over veelgestelde CRA-vragen.
• CRA-overzicht van de ORC WG: bronnen van de Open Regulatory Compliance Working Group.
• OWASP SAMM: het model, de tools en de richtlijnen.