CRA-eisen: hier moeten digitale producten aan voldoen

De CRA-eisen zijn de essentiële cyberbeveiligingsvereisten uit bijlage I van de Cyber Resilience Act. Ze bestaan uit twee delen: eisen aan de eigenschappen van het product, en eisen aan hoe u als fabrikant met kwetsbaarheden omgaat. Daar komen de meldplicht en een dossier bij waarmee u aantoont dat u voldoet.

De meldplicht geldt al sinds 11 september 2026. De overige eisen gelden voor producten die vanaf 11 december 2027 op de markt komen. Hoe die tijdlijn werkt en welke productcategorieën er zijn, leest u in het overzicht van de CRA.

Op deze pagina loopt u de eisen langs, met per onderdeel wat het in de praktijk betekent. Of ze voor u gelden, hangt af van uw rol. Zie daarvoor voor wie geldt de CRA.

Twee soorten CRA-eisen: het product en uw proces

Deel I van bijlage I gaat over het product zelf: hoe het is ontworpen, gebouwd en ingesteld. Deel II gaat over uw processen: hoe u kwetsbaarheden vindt, verhelpt en communiceert, zolang het product wordt ondersteund.

De verbindende schakel is de risicobeoordeling. U beoordeelt per product welke risico’s er zijn. Op basis daarvan bepaalt u welke eisen uit deel I van toepassing zijn en hoe u ze invult. Vindt u een eis niet van toepassing, dan legt u in het technisch dossier uit waarom.

Die beoordeling is geen eenmalig document. U werkt hem bij zolang het product wordt ondersteund, bijvoorbeeld als er nieuwe kwetsbaarheden of gebruikssituaties bijkomen. Wie al risicomanagement volgens ISO 27005 toepast, herkent de aanpak.

Deel I: eisen aan het product

De productvereisten zeggen wat het product moet kunnen, niet met welke techniek. Samengevat gaat het om het volgende.

• Geen bekende lekken. Het product komt op de markt zonder bekende kwetsbaarheden die te misbruiken zijn.
• Veilig standaard ingesteld. De standaardconfiguratie is veilig, met de mogelijkheid om terug te gaan naar de fabrieksinstelling. Een wachtwoord dat op elk apparaat hetzelfde is, past daar slecht bij.
• Updates. Kwetsbaarheden zijn met updates te verhelpen, waar passend automatisch en standaard ingeschakeld, met een duidelijke manier om dat uit te zetten.
• Toegang en gegevens. Bescherming tegen ongeautoriseerde toegang, versleuteling van gevoelige gegevens, bescherming tegen manipulatie, en niet meer gegevens verwerken dan nodig.
• Beschikbaarheid. Kernfuncties blijven werken, ook bij een aanval die het product wil platleggen, en het product verstoort andere netwerken zo min mogelijk.
• Klein aanvalsoppervlak. Zo weinig mogelijk openingen naar buiten, en mechanismen die de gevolgen van een incident beperken.
• Logging en verwijderen. Relevante activiteit wordt vastgelegd, met een uitschakelmogelijkheid voor de gebruiker, en gebruikers kunnen hun gegevens veilig en blijvend verwijderen.

Voor veel softwareteams is dit geen nieuwe lijst. Het zijn de principes van security by design. Nieuw is dat u moet kunnen laten zien dat u ze toepast.

Deel II: kwetsbaarheden beheren

Het tweede deel gaat over wat er na de levering gebeurt. Als fabrikant regelt u het volgende.

• Weten wat erin zit. U legt componenten en kwetsbaarheden vast, onder meer in een softwarestuklijst.
• Snel verhelpen. U lost kwetsbaarheden zonder vertraging op, waar mogelijk met beveiligingsupdates die los staan van nieuwe functies.
• Regelmatig testen. U test en beoordeelt de beveiliging van het product doeltreffend en regelmatig.
• Open zijn over opgeloste lekken. Na een update publiceert u informatie over de verholpen kwetsbaarheid, met de ernst, de gevolgen en wat gebruikers moeten doen.
• Melden makkelijk maken. U heeft een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden en een contactadres waar iedereen een kwetsbaarheid kan melden.
• Veilig en gratis updaten. U verspreidt updates veilig en biedt beveiligingsupdates kosteloos aan, tenzij u met een zakelijke klant iets anders afspreekt voor maatwerk.

Het beleid voor gecoördineerde openbaarmaking staat ook wel bekend als responsible disclosure. Hoe u dat inricht, inclusief een security.txt-bestand op uw website, leest u in dat artikel.

De softwarestuklijst (SBOM) in de praktijk

Een SBOM, voluit software bill of materials, is een lijst van de onderdelen waaruit uw software bestaat: bibliotheken, frameworks en andere componenten, met hun versies. De CRA vraagt een SBOM in een gangbaar, machineleesbaar formaat, met ten minste de directe afhankelijkheden van het product.

Bekende formaten zijn SPDX en CycloneDX. Veel buildtools kunnen zo’n lijst automatisch aanmaken, zodat hij bij elke nieuwe versie klopt.

De waarde zit in het gebruik. Wordt er een kwetsbaarheid bekend in een veelgebruikte bibliotheek, dan ziet u met een actuele SBOM snel in welke producten en versies die zit. Zonder SBOM begint dan een zoektocht.

Ondersteuningsperiode en beveiligingsupdates

U bepaalt zelf hoe lang u een product ondersteunt, maar niet willekeurig. De ondersteuningsperiode moet passen bij hoe lang het product naar verwachting wordt gebruikt. Ze duurt minstens vijf jaar, tenzij het product korter meegaat.

Vijf jaar is daarmee een ondergrens, geen standaard: gaat een product langer mee, dan hoort daar een langere periode bij. Dat benadrukken ook de richtsnoeren van de Europese Commissie.

De einddatum, minstens maand en jaar, maakt u bij aankoop duidelijk bekend. Elke beveiligingsupdate blijft na verschijnen minstens tien jaar beschikbaar, of langer als de ondersteuningsperiode langer loopt.

Voor software geldt een praktische regel. Brengt u steeds nieuwe, ingrijpend gewijzigde versies uit, dan mag u kwetsbaarheden alleen in de nieuwste versie oplossen. Voorwaarde is dat gebruikers van oudere versies kosteloos kunnen overstappen, zonder extra kosten voor hun hardware of omgeving.

De meldplicht: binnen 24 uur een eerste waarschuwing

Sinds 11 september 2026 meldt u als fabrikant twee soorten gebeurtenissen: een actief misbruikte kwetsbaarheid in uw product, en een ernstig incident dat de beveiliging van uw product raakt. Een kwetsbaarheid is actief misbruikt als er betrouwbaar bewijs is dat een kwaadwillende haar heeft gebruikt, zonder toestemming van de eigenaar van het systeem.

De melding gaat in stappen. Binnen 24 uur stuurt u een vroegtijdige waarschuwing, met de lidstaten waar het product beschikbaar is. Binnen 72 uur volgt de eigenlijke melding, met de aard van het probleem en de genomen maatregelen. Het eindverslag volgt uiterlijk 14 dagen nadat een oplossing beschikbaar is, of bij een incident binnen een maand na de melding.

Is uw hoofdvestiging in Nederland, dan meldt u bij het NCSC, via MijnNCSC of het meldformulier. Het NCSC stuurt de melding door naar ENISA en de CSIRT’s van andere lidstaten. Ook informeert u zelf de getroffen gebruikers, met wat zij kunnen doen. Zie de uitleg van het NCSC.

Twee verduidelijkingen uit de richtsnoeren van de Commissie helpen. De meldplicht geldt ook voor producten die u vóór december 2027 verkocht, en blijft gelden na afloop van de ondersteuning. En een kwetsbaarheid in een gebruikte bibliotheek die in uw product niet te misbruiken is, hoeft u niet verplicht te melden. De opbouw lijkt op de NIS2 meldplicht uit de Cyberbeveiligingswet, maar het gaat om een aparte plicht.

Het dossier: van risicobeoordeling tot CE-markering

Om te laten zien dat u voldoet, bouwt u een dossier op. Dat bestaat uit vijf lagen die op elkaar rusten.

De technische documentatie beschrijft onder meer het beoogde doel, het ontwerp, de risicobeoordeling, de onderbouwing van de ondersteuningsperiode, de toegepaste normen en de testverslagen. Ook uw processen voor kwetsbaarheden horen erin, met de SBOM en uw meldbeleid. U stelt de documentatie op voordat het product op de markt komt en houdt haar actueel.

Daarna volgt de conformiteitsbeoordeling. Voor producten in de standaardcategorie mag u die zelf uitvoeren, via interne controle. Voor belangrijke en kritieke producten is vaak een aangemelde instantie nodig: een onafhankelijke partij die daarvoor is aangewezen. Welke categorie voor uw product geldt, staat in de vier productcategorieën.

Als laatste stelt u de EU-conformiteitsverklaring op en brengt u de CE-markering aan. Documentatie en verklaring bewaart u minstens tien jaar, of langer als de ondersteuningsperiode langer duurt. Micro- en kleine ondernemingen mogen de technische documentatie in vereenvoudigde vorm aanleveren.

Veelgemaakte fouten

Bij de voorbereiding liggen een paar valkuilen voor de hand. Ze zijn allemaal te voorkomen.

• De SBOM als eenmalige export. Een lijst van vorig jaar zegt niets over de versie die nu draait. Koppel hem aan uw buildproces.
• Componenten van derden vergeten. Uw product is zo veilig als de onderdelen erin. Vraag leveranciers naar hun ondersteuningstermijnen en hoe zij kwetsbaarheden melden.
• Geen eigenaar voor meldingen. Een securityadres dat niemand leest, is geen meldbeleid. Wijs een eigenaar aan en een vervanger.
• Het dossier achteraf schrijven. Documentatie die pas aan het eind ontstaat, beschrijft vaak wat er had moeten gebeuren. Leg keuzes vast op het moment dat u ze maakt.

Veelgestelde vragen over de CRA-eisen

Is een SBOM verplicht onder de CRA?

Ja. Als fabrikant stelt u een softwarestuklijst op in een gangbaar, machineleesbaar formaat, met ten minste de directe afhankelijkheden. Openbaar maken hoeft niet. Op verzoek van de markttoezichthouder moet u hem wel kunnen laten zien.

Moeten beveiligingsupdates gratis zijn?

Ja. Beveiligingsupdates biedt u kosteloos aan zolang het product wordt ondersteund. Alleen voor maatwerk kunt u met een zakelijke klant iets anders afspreken. De plicht geldt voor beveiligingsupdates, niet voor nieuwe functies.

Moet ik een kwetsbaarheid in een gebruikte bibliotheek melden?

Alleen verplicht als die kwetsbaarheid in uw product actief wordt misbruikt. Is ze in uw product niet te misbruiken, dan verhelpt u haar via uw normale proces. Ook meldt u haar aan de maker van de component. Vrijwillig melden bij het NCSC mag altijd.

Mag ik een kwetsbaarheid pas openbaar maken als de update er is?

Ja, dat is juist de bedoeling. Na een beveiligingsupdate deelt u informatie over de verholpen kwetsbaarheid. In gemotiveerde gevallen mag u die publicatie uitstellen tot gebruikers de update hebben kunnen installeren.

Moet ik mijn product opnieuw ontwerpen?

Niet per se. Komt een product dat vóór december 2027 is ontworpen daarna op de markt, dan kunt u met de risicobeoordeling aantonen dat de bestaande maatregelen volstaan. Volgens de richtsnoeren van de Commissie dwingt de CRA geen herontwerp af als de risico’s al goed zijn afgedekt.