Wat is de EU Cyber Resilience Act?
De EU Cyber Resilience Act (CRA) is een verordening die verplichte cyberbeveiligingsvereisten vastlegt voor producten met digitale elementen die in de Europese Unie worden verkocht. Hij werd eind 2024 formeel aangenomen en wordt volledig afdwingbaar in december 2027.
In tegenstelling tot de AVG, die zich richt op de verwerking van persoonsgegevens, richt de CRA zich op de beveiliging van het product zelf — hoe het is gebouwd, hoe kwetsbaarheden worden gemeld en hoe software-updates worden beheerd tijdens de levensduur van het product.
Als je WordPress-plugins, thema's, SaaS-producten of een ander verbonden digitaal product aan EU-klanten verkoopt, is deze verordening waarschijnlijk op jou van toepassing.
Wie heeft de CRA invloed op?
De verordening richt zich op "fabrikanten" en "distributeurs" van producten met digitale elementen. In de praktijk omvat dit:
WordPress-plugin- en thema-ontwikkelaars die betaalde producten verkopen op de EU-markt. Als je plugin gegevens verwerkt, verbinding maakt met externe diensten, of deel uitmaakt van een groter software-ecosysteem, valt het binnen het toepassingsgebied.
SaaS-aanbieders die op abonnement gebaseerde tools aanbieden aan EU-bedrijven of -consumenten.
Agentschappen en freelancers die aangepaste software of webapplicaties ontwikkelen die aan EU-klanten worden geleverd. Als je een op WordPress gebaseerd product overdraagt aan een klant in Duitsland, Frankrijk, Italië of een ander EU-land, kun je worden beschouwd als "fabrikant" onder de CRA.
Eigenaren van e-commercesites die hun eigen digitale producten aan EU-klanten verkopen.
Opmerkelijk is dat opensourcesoftware die niet-commercieel wordt ontwikkeld en gedistribueerd grotendeels is uitgezonderd. Maar als je geld verdient aan een WordPress-plugin — zelfs deels, zelfs via een freemium-model — val je waarschijnlijk binnen het toepassingsgebied.
Belangrijke vereisten onder de CRA
De CRA introduceert verschillende specifieke verplichtingen. Hier zijn de meest relevante voor WordPress-beheerders:
1. Vulnerability Disclosure Policy (VDP)
Je moet een openbaar toegankelijk beleid hebben dat uitlegt hoe beveiligingsonderzoekers kwetsbaarheden in je product kunnen melden. Dit heet een Vulnerability Disclosure Policy of VDP.
De VDP moet beschikbaar zijn op een voorspelbare locatie (je website), in duidelijke taal zijn geschreven, en specificeren:
- Hoe een kwetsbaarheidsrapport in te dienen
- Welke informatie op te nemen
- Hoe lang het duurt om ontvangst te bevestigen
- Of je een gecoördineerd openbaarmakingsproces hanteert
2. security.txt-bestand (RFC 9116)
De standaardlocatie voor beveiligingscontactinformatie is /.well-known/security.txt op je domein. Dit machineleesbare bestand verwijst beveiligingsonderzoekers naar je contactinformatie en VDP.
De CRA maakt dit feitelijk een vereiste voor producten binnen het toepassingsgebied. Het formaat is gedefinieerd in RFC 9116 en ziet er zo uit:
Contact: mailto:security@jouwsite.com
Expires: 2027-12-31T23:59:59.000Z
Policy: https://jouwsite.com/vulnerability-disclosure-policy
3. Software Bill of Materials (SBOM)
Een SBOM is een formele lijst van alle softwarecomponenten in je product — in essentie een ingrediëntenlijst voor software.
Voor een WordPress-plugin betekent dit het documenteren van:
- Je plugin zelf (naam, versie, licentie)
- Alle externe bibliotheken of afhankelijkheden die het gebruikt
- WordPress-kern als afhankelijkheid
SBOM's moeten op verzoek beschikbaar zijn voor bevoegde autoriteiten en, voor producten met hoger risico, mogelijk openbaar toegankelijk zijn.
4. Actief kwetsbaarheidsbeheer
De CRA vereist dat fabrikanten:
- Hun producten controleren op bekende kwetsbaarheden
- Tijdig beveiligingsupdates uitbrengen
- Gebruikers informeren over beveiligingsupdates
- Beveiligingsupdates gratis aanbieden tijdens een vastgestelde supportperiode
Voor WordPress-plugins betekent dit dat je niet simpelweg een versie kunt uitbrengen en deze daarna kunt verlaten. Als een CVE wordt ontdekt die jouw plugin treft, ben je verplicht om een oplossing uit te brengen.
5. Conformiteitsbeoordeling en CE-markering
De meeste "standaard" digitale producten (Categorie I onder de CRA) moeten een zelfbeoordeling doorlopen tegen de vereisten van de verordening en de CE-markering op hun product aanbrengen. De beoordeling moet worden gedocumenteerd.
Producten met hoger risico (Categorie II) vereisen beoordeling door een derde partij via een aangemelde instantie — vergelijkbaar met hoe medische hulpmiddelen of speelgoed worden getest.
De meeste WordPress-plugins vallen in Categorie I en kunnen zichzelf certificeren.
Hoe zit het met AVG en NIS2?
De CRA vervangt de AVG of NIS2 niet — ze werken naast elkaar.
De AVG dekt de verwerking van persoonsgegevens. Als je WordPress-site of plugin persoonsgegevens van EU-inwoners verwerkt, geldt de AVG onafhankelijk van de CRA.
NIS2 (de richtlijn netwerk- en informatiebeveiliging 2) legt beveiligingsvereisten op aan "essentiële" en "belangrijke" entiteiten — voornamelijk grotere bedrijven in sectoren zoals energie, gezondheidszorg, financiën en digitale infrastructuur. Als jouw bedrijf of dat van je klant in een van deze categorieën valt, gelden NIS2-verplichtingen naast de CRA.
Voor de meeste kleine WordPress-bedrijven en freelancers zijn AVG en CRA de primaire aandachtspunten. NIS2 geldt voor een kleinere groep grotere entiteiten.
De tijdlijn — wat moet wanneer gebeuren
| Datum | Verplichting |
|---|---|
| Nu | Begin met hiaatanalyse: identificeer wat je moet doen |
| September 2026 | CRA-rapportageverplichtingen gaan in (actief misbruikte kwetsbaarheden binnen 24 uur melden aan autoriteiten) |
| December 2027 | Volledige CRA-vereisten gelden: VDP, SBOM, security.txt, conformiteitsbeoordeling, CE-markering |
De rapportageverplichting van september 2026 wordt vaak over het hoofd gezien. Hoewel volledige naleving niet vereist is tot december 2027, moet je in staat zijn om actief misbruikte kwetsbaarheden binnen 24 uur aan ENISA te melden — en dat vereist dat er al vóór die datum monitoringprocessen aanwezig zijn.
Hoe je je huidige status controleert
Als je niet zeker weet waar je staat, begin met deze vragen:
- Heb je een beveiligingscontact? Is er een manier voor onderzoekers of gebruikers om een beveiligingsprobleem in je product te melden?
- Is er een security.txt-bestand op
/.well-known/security.txtop je domein? - Kun je alle softwarecomponenten in je product opsommen? Weet je welke externe bibliotheken je plugins gebruiken en hun huidige versies?
- Heb je een proces om kwetsbaarheden te volgen in de afhankelijkheden van je product?
- Heb je je beveiligingspraktijken gedocumenteerd? Zou je bewijs van een conformiteitsbeoordeling kunnen leveren als een toezichthouder dat vraagt?
Als je de meeste van deze vragen met nee hebt beantwoord, heb je werk te doen — maar het is beheersbaar met een duidelijke checklist.
Een plugin gebruiken om de checklist te automatiseren
In plaats van deze vereisten handmatig door te werken, automatiseert Erdo CRA Compliance de hiaatanalyse en helpt het bij het genereren van vereiste documentatie rechtstreeks vanuit je WordPress-dashboard.
De plugin:
Scant je site tegen CRA-, AVG- en NIS2-controles en produceert een kleurgecodeerd compliancedashboard — groen (geslaagd), oranje (aandacht nodig), rood (gefaald).
Genereert je security.txt-bestand in het juiste RFC 9116-formaat en host het automatisch op /.well-known/security.txt. Geen FTP, geen serverconfiguratie.
Maakt een Vulnerability Disclosure Policy-sjabloon op basis van je sitegegevens, klaar om te publiceren als pagina op je site.
Produceert een SBOM met alle actieve plugins, hun versies en hun licentie-informatie — de kern van wat een software bill of materials vereist voor een op WordPress gebaseerd product.
Exporteert PDF-auditrapporten die je compliancestatus documenteren, geschikt om te delen met klanten, auditors, of als bewijsstukken voor een conformiteitsbeoordeling.
Genereert een conformiteitsverklaringssjabloon — het zelfbeoordelingsdocument vereist voor Categorie I-producten onder de CRA.
Niets hiervan garandeert juridische naleving — dat hangt af van je specifieke product, hoe het wordt gebruikt, en je juridische context. Maar het geeft je een gestructureerd startpunt en zorgt ervoor dat de basistechnische vereisten aanwezig zijn.
Praktisch advies voor verschillende doelgroepen
Als je WordPress-pluginontwikkelaar bent: Begin met het documenteren van de afhankelijkheden van je plugin (controleer je composer.json of alle externe bibliotheken die je hebt gebundeld). Stel een beveiligingscontact-e-mailadres in. Publiceer een eenvoudige VDP. Deze drie stappen dekken de meeste basisverplichtingen en duren een paar uur, geen weken.
Als je freelancer bent die WordPress-projecten levert: Controleer of je klanten in de EU zijn gevestigd en of de sites die je voor hen bouwt binnen het toepassingsgebied vallen. Overweeg om CRA-compliancedocumentatie als een te leveren onderdeel in je contracten op te nemen.
Als je een agentschap bent: Bouw een CRA-compliancechecklist in je projectoverdrachtsproces. Klanten die digitale producten op de EU-markt ontvangen, zullen steeds meer documentatie nodig hebben dat je deze vereisten hebt overwogen.
Als je een EU-gerichte e-commercesite runt die digitale producten verkoopt: Behandel de deadline van december 2027 zoals bedrijven de deadline van mei 2018 van de AVG behandelden — maar begin deze keer eerder.
Tot slot
De EU Cyber Resilience Act is de grootste verandering in softwarecomplianceverplichtingen sinds de AVG. In tegenstelling tot de AVG, die de meeste sitebeheerders grotendeels negeerden tot het laatste moment, heeft de CRA specifieke technische vereisten die niet alleen met een beleidsupdate kunnen worden aangepakt — ze vereisen daadwerkelijke implementatie.
Het goede nieuws: als je WordPress gebruikt, zijn de tools om aan de meeste CRA-vereisten te voldoen nu beschikbaar. Door in 2026 met de beoordeling te beginnen, heb je een vol jaar om de checklist door te werken vóór de deadline van december 2027.
Download Erdo CRA Compliance gratis van WordPress.org en voer vandaag je eerste compliancescan uit.