De Cyber Resilience Act uitgelegd.

De CRA geldt voor producten met digitale elementen: software of hardware waarvan het beoogde of redelijkerwijs voorzienbare gebruik een directe of indirecte gegevensverbinding met een apparaat of netwerk omvat (Art. 2(1), Art. 3(1)). Ook gegevensverwerking op afstand valt eronder, als de fabrikant die voor het product heeft ontworpen en het product zonder die verwerking een van zijn functies niet kan uitvoeren (Art. 3(2)).

Het product moet in het kader van een commerciële activiteit op de EU-markt beschikbaar worden gesteld, tegen betaling of gratis (Art. 3(22)). Het gaat dus niet alleen om verkopen.

Software die op afstand draait en die jij alleen via een browser opent, is volgens de Commissierichtsnoeren van 2026 niet op die grond alleen een product. Websites zijn zelf ook geen producten. Clouddiensten die buiten de verantwoordelijkheid van een productfabrikant zijn ontworpen en ontwikkeld, vallen buiten de CRA (overweging 12); daarvoor geldt de NIS2-richtlijn. Cloudfuncties die een fabrikant bouwt om zijn eigen product te laten werken, vallen er wel onder. Software die je downloadt of installeert, inclusief browserextensies, is een product.

Sectoren met eigen regels zijn uitgezonderd: medische hulpmiddelen en in-vitrodiagnostica, motorvoertuigen, burgerluchtvaart en uitrusting voor zeeschepen (Art. 2(2) tot en met (4)). Producten die uitsluitend voor nationale veiligheid of defensie zijn ontwikkeld, vallen er ook buiten (Art. 2(7)). Producten die een overheidsinstantie uitsluitend voor eigen gebruik ontwikkelt of aanpast, worden niet op de markt aangeboden (overweging 16).

• Binnen de reikwijdte: software die je op je eigen apparaten installeert of draait, hardware met een netwerkverbinding, en cloudfuncties die een fabrikant bouwt om zijn eigen product te laten werken.
• Meestal buiten de reikwijdte: webapplicaties die je alleen via een browser gebruikt, en websites die de werking van een product niet ondersteunen.
• Buiten de reikwijdte per sector: medische hulpmiddelen, in-vitrodiagnostica, motorvoertuigen, burgerluchtvaart en uitrusting voor zeeschepen.
• Producten die vóór 11 december 2027 op de markt zijn gebracht, vallen pas onder de CRA na een substantiële wijziging (Art. 69(2)). De meldplicht van Art. 14 geldt wel voor alle producten binnen de reikwijdte (Art. 69(3)).

Fabrikanten dragen het grootste deel van de verplichtingen (Art. 13). Ze moeten producten ontwerpen volgens Bijlage I, een cyberbeveiligingsrisicobeoordeling uitvoeren en documenteren, en die tijdens de ondersteuningsperiode actueel houden.

Importeurs en distributeurs controleren voor ze een product leveren of de CE-markering, de EU-conformiteitsverklaring en de gebruikersinformatie aanwezig zijn (Art. 19, Art. 20). Wie onder eigen naam of merk levert, of een product substantieel wijzigt, wordt als fabrikant behandeld (Art. 21 en 22).

Standaard beoordeelt een fabrikant de conformiteit zelf (interne controle, Art. 32(1)). Voor belangrijke producten (Bijlage III) en kritieke producten (Bijlage IV) gelden strengere routes. Klasse I, bijvoorbeeld besturingssystemen, wachtwoordmanagers, vpn-producten en routers, mag alleen zelf beoordeeld worden als geharmoniseerde normen, gemeenschappelijke specificaties of certificering volledig zijn toegepast. Klasse II, bijvoorbeeld hypervisors, firewalls en inbraakdetectiesystemen, en kritieke producten vragen om beoordeling of certificering door een derde (Art. 32(2) tot en met (4)).

Bij overtreding van Art. 13 of Art. 14 zijn boetes mogelijk tot 15 miljoen euro of 2,5 % van de wereldwijde jaaromzet, het hoogste bedrag telt (Art. 64(2)). De lidstaten stellen de sanctieregels vast en handhaven ze.

• Veilig ontworpen en veilig standaard ingesteld (Bijlage I, deel I): geen bekende uitbuitbare kwetsbaarheden bij het beschikbaar stellen, veilige standaardconfiguratie, bescherming tegen onbevoegde toegang, bescherming van gegevens en de mogelijkheid tot beveiligingsupdates.
• Kwetsbaarhedenbeheer (Bijlage I, deel II): een beleid voor gecoördineerde bekendmaking van kwetsbaarheden, een contactadres voor meldingen, kwetsbaarheden zonder uitstel verhelpen, een SBOM (software bill of materials) die minimaal de afhankelijkheden op het hoogste niveau omvat, en beveiligingsupdates kosteloos aanbieden, tenzij anders overeengekomen voor maatwerkproducten (punt 8).
• Ondersteuningsperiode (Art. 13(8)): afgestemd op de verwachte gebruiksduur en minimaal vijf jaar, tenzij het product naar verwachting korter wordt gebruikt. De einddatum, minstens maand en jaar, staat bij aankoop duidelijk vermeld (Art. 13(19)). Elke beveiligingsupdate blijft minstens 10 jaar beschikbaar, of tot het einde van de ondersteuningsperiode als dat later is (Art. 13(9)).
• Conformiteit: conformiteitsbeoordeling, technische documentatie, EU-conformiteitsverklaring, CE-markering (Art. 13, 28 en 30) en gebruikersinformatie volgens Bijlage II.
• Meldplicht (Art. 14), sinds 11 september 2026: een vroegtijdige waarschuwing binnen 24 uur nadat de fabrikant het weet, een melding binnen 72 uur, en een eindverslag uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is (kwetsbaarheden) of binnen een maand na de incidentmelding (ernstige incidenten). De melding gaat via het centrale meldplatform tegelijk naar de als coördinator aangewezen CSIRT en naar ENISA. Daarnaast informeert de fabrikant de getroffen gebruikers (Art. 14(8)).

Vanaf 11 december 2027 gelden de verplichtingen uit het vorige onderdeel voor producten binnen de reikwijdte die dan op de markt komen. Ze gelden meestal niet voor SaaS die je alleen via een browser gebruikt, en niet voor producten die eerder op de markt kwamen, tenzij die substantieel zijn gewijzigd. Gebruik de punten hieronder in aanbestedingen, vragenlijsten en contracten.

De meldplicht geldt al sinds 11 september 2026. Je mag nu al verwachten dat leveranciers actief uitgebuite kwetsbaarheden en ernstige incidenten binnen de termijnen van Art. 14 melden, ook voor producten die eerder op de markt kwamen. De CRA belet je niet om in je eigen inkoop extra cyberbeveiligingseisen te stellen (Art. 5(1), overweging 13).

• CE-markering: draagt het product die, en waar staat ze? Bij software staat ze op de EU-conformiteitsverklaring of op de website die bij de software hoort (Art. 30(1)).
• EU-conformiteitsverklaring: waar kun je die lezen? Een vereenvoudigde verklaring moet het exacte internetadres van de volledige verklaring bevatten (Art. 13(20)).
• Ondersteuningsperiode: wat is de einddatum, minstens maand en jaar, voor de versie die je koopt? Die moet bij aankoop duidelijk vermeld zijn (Art. 13(19)). Het minimum is vijf jaar, tenzij het product naar verwachting korter wordt gebruikt (Art. 13(8)).
• Beveiligingsupdates: zijn die kosteloos tijdens de ondersteuningsperiode (tenzij anders overeengekomen voor maatwerkproducten) en hoe worden ze geleverd? (Bijlage I, deel II, punt 7 en 8).
• Contact voor kwetsbaarheden: wie is het centrale contactpunt en waar staat het beleid voor gecoördineerde bekendmaking van kwetsbaarheden? (Art. 13(17), Bijlage II).
• SBOM: de leverancier moet er een bijhouden die minimaal de afhankelijkheden op het hoogste niveau omvat en geeft die op gemotiveerd verzoek aan toezichthouders. Delen met klanten is optioneel (Bijlage II, punt 9). Vraag er dus expliciet om of leg het vast in het contract.
• Incidenten: informeert de leverancier je over actief uitgebuite kwetsbaarheden en ernstige incidenten, en in welke vorm? (Art. 14(8)).
• Conformiteitsroute: welke beoordelingsroute is gebruikt bij producten uit Bijlage III of IV? (Art. 32).

Vrije en opensourcesoftware valt alleen onder de CRA als ze wordt geleverd in het kader van een commerciële activiteit. Software waar de makers geen geld mee verdienen, valt er niet onder (overweging 18). Financiële steun van fabrikanten of regelmatige releases maken software op zichzelf niet commercieel. Code alleen hosten op een open repository of pakketbeheerder is geen beschikbaar stellen op de markt (overweging 20).

Een commerciële activiteit is ruimer dan een prijs. Overweging 15 noemt: een vergoeding voor technische ondersteuning die meer is dan kostendekking, de bedoeling om te gelde te maken (bijvoorbeeld een platform waarmee andere diensten worden verdiend), persoonsgegevens verplicht stellen voor andere doeleinden dan beveiliging, compatibiliteit of interoperabiliteit, en donaties aannemen die de kosten overstijgen. Donaties zonder winstoogmerk zijn geen commerciële activiteit.

Een steward van opensourcesoftware is een rechtspersoon, geen fabrikant, die systematisch en duurzaam ondersteuning biedt voor de ontwikkeling van opensourceproducten die voor commerciële activiteiten zijn bedoeld (Art. 3(14)). Bepaalde stichtingen en organisaties die open source in een zakelijke context publiceren, kunnen steward zijn (overweging 19). Voor stewards geldt een lichter regime (Art. 24).

Stewards mogen geen CE-markering aanbrengen (overweging 19) en vallen niet onder de bestuurlijke boetes van Art. 64(3) tot en met (9) (Art. 64(10)(b)). Hun verplichtingen gelden volgens ENISA vanaf 11 december 2027. Dezelfde organisatie kan voor het ene project steward zijn en voor het andere fabrikant, volgens de richtsnoeren van de Commissie. Fabrikanten die opensourcecomponenten gebruiken, moeten daar zorgvuldigheid bij betrachten (Art. 13(5)).

• Een gedocumenteerd cyberbeveiligingsbeleid dat veilige ontwikkeling en omgaan met kwetsbaarheden bevordert.
• Op verzoek samenwerken met markttoezichtautoriteiten.
• Kwetsbaarheden melden volgens Art. 14, voor zover de steward bij de ontwikkeling betrokken is.

De CRA en NIS2 (Richtlijn (EU) 2022/2555) gaan over verschillende dingen. De CRA stelt eisen aan producten en hun fabrikanten. NIS2 gaat over de diensten en het risicobeheer van essentiële en belangrijke entiteiten.

De CRA stelt dat bestaande Uniewetgeving over cyberbeveiliging, waaronder NIS2, niet rechtstreeks verplichte beveiligingseisen voor producten met digitale elementen bevat (overweging 3). De CRA wil aanbieders van digitale infrastructuur helpen te voldoen aan de eisen voor de toeleveringsketen onder NIS2, doordat de producten die zij gebruiken veilig zijn ontwikkeld en tijdig beveiligingsupdates krijgen (overweging 24). Maatregelen voor de toeleveringsketen onder NIS2 kunnen strengere eisen aan producten stellen dan de CRA (overweging 13).

De twee raken elkaar bij het melden: de CRA gebruikt de uit NIS2 bekende, als coördinator aangewezen CSIRT's als ontvanger van meldingen (Art. 14). Of jouw eigen organisatie onder NIS2 valt, is een aparte vraag die deze pagina niet beantwoordt.

Op dit moment is deze pagina alleen informatie. De CRA verandert niets aan de soevereiniteitsscore of de aanbevelingen.

Als proef tonen we nu bij de leveranciers in de categorie CMS de CRA-signalen die we openbaar vonden, als informatie naast de bestaande gegevens en zonder dat ze meetellen in de score: een security.txt, een pagina om kwetsbaarheden te melden, een beleid voor ondersteunde versies en, bij open source, de organisatie achter het project. Elke link is gecontroleerd op de site van de leverancier of het project zelf. Vanaf 11 december 2027 tonen we ook de EU-conformiteitsverklaring (CE-markering), zodra een product die heeft.

Een CRA-signaal zegt niets over waar een leverancier is gevestigd of wie de eigenaar is. Digitale soevereiniteit en productbeveiliging zijn aparte vragen.