1. Cyberveiligheid op de Europese agenda
De Cyber Resilience Act (CRA) vormt het meest recente initiatief van de Europese Unie op het gebied van cyberveiligheid. Deze verordening komt er in het verlengde van eerdere wetgeving, zoals de NIS 2-richtlijn en de DORA-verordening voor de financiële sector.
De CRA wil de toenemende cyberdreiging tegengaan en verplicht fabrikanten van hard- en softwareproducten om gedurende de volledige levenscyclus van hun producten aandacht te besteden aan cybersecurity. De CRA beoogt een hoger niveau van cyberveiligheid voor alle producten met digitale elementen — van smartwatches tot slimme industriële apparaten.
Wat de CRA bijzonder maakt, is haar brede toepassingsgebied en de expliciete toepassing op software — inclusief open source componenten. De CRA legt leg uitgebreide verplichtingen op aan fabrikanten, inclusief softwareontwikkelaars. Ook kleinere bedrijven of ontwikkelaars die open source software gebruiken, worden geconfronteerd met nieuwe regels en risico’s. In deze bijdrage lichten we de belangrijkste uitdagingen toe.
2. Een breed en horizontaal toepassingsgebied dat reikt tot de kleinste softwareontwikkelaar
De CRA is van toepassing op “producten met digitale elementen”, waaronder ook softwareproducten die zelfstandig op de markt worden gebracht.
Opvallend is dat de CRA geen onderscheid maakt naar sector of bedrijfsomvang. Dit betekent dat niet alleen grote techbedrijven, maar ook kleinschalige ontwikkelaars van bijvoorbeeld apps of ERP-systemen onder de CRA vallen. De CRA is enkel van toepassing op software producten, zodat software die als een dienst (zoals pure SaaS) wordt geleverd zonder link met een fysiek product buiten schot blijft. Ook software die enkel voor intern gebruik werd ontwikkeld (zoals een eigen CRM-toepassing) is uitgesloten.
De CRA is enkel van toepassing op producten die worden gecommercialiseerd. Hieraan is ook voldaan bij producten die gratis worden aangeboden, indien de verwerking van persoonsgegevens wordt opgelegd voor andere reden dan de beveiliging, compatibiliteit of interoperabiliteit van de software. Uitzonderingen gelden enkel voor producten die al onder andere sectorale regelgeving vallen, zoals medische diagnostische software, luchtvaartsoftware en maritieme navigatiesoftware.
Ook kleine softwareontwikkelaars vallen onder de verplichtingen, wat in de praktijk voor veel kleinere bedrijven zonder compliance-afdeling een aanzienlijke juridische én financiële uitdaging betekent.
3. Open source software: gedeeltelijk buiten schot, maar niet vrijgesteld
Het gebruik van open source software is de voorbije jaren niet meer weg te denken bij softwareontwikkeling. Opensourcesoftware is software waarbij de broncode (doorgaans gratis) vrij voor gebruik en aanpassing beschikbaar wordt gesteld.
Open source software valt slechts onder de CRA wanneer het aanbieden als een commerciële activiteit wordt beschouwd. Dit is het geval wanneer de aanbieder commerciële bedoelingen heeft (bv. wanneer er een vergoeding wordt aangerekend voor de ondersteuning van opensource software of wanneer uit het verwerken van persoonsgegevens via de opensourcesoftware een financieel voordeel wordt gehaald). De CRA is in elk geval niet van toepassing op het zuiver gratis aanbieden van opensource software (ongeacht de commercieel bedoelingen van de gebruikers).
De CRA introduceert bovendien een nieuwe entiteit: de “open source software steward”. Deze steward, meestal een stichting of vereniging die de ontwikkeling van open source software structureel ondersteunt, wordt onderworpen aan een lichter regime. Zij moeten onder andere een cyberbeveiligingsbeleid opstellen en kwetsbaarheden melden aan de bevoegde autoriteiten.
De concrete invulling van dit stewardschap blijft onduidelijk. Ook het toezicht en de interpretatie van het begrip kan per lidstaat verschillen, wat leidt tot risico op fragmentatie binnen de EU. De verplichtingen voor stewards zijn minder zwaar, maar niet vrijblijvend: hoewel geen geldboetes kunnen worden opgelegd, zijn corrigerende maatregelen wel mogelijk.
4. Zorgvuldigheidsplicht voor externe componenten
Fabrikanten die softwarecomponenten van derden integreren, moeten nagaan of die componenten voldoen aan bepaalde beveiligingsvereisten. Deze onderzoeks-en zorgvuldigheidsplicht omvat onder meer:
- het nagaan of een component CE-gemarkeerd is;
- het controleren op regelmatige beveiligingsupdates;
- het toetsen op gekende kwetsbaarheden (bv. in publieke databanken);
- het uitvoeren van extra veiligheidstesten indien nodig.
Deze due diligence geldt ook voor open source componenten. In de praktijk is dit moeilijk. Veel fabrikanten integreren open source zonder controle van de broncode op eventuele beveiligingsrisico’s. Het is vaak onduidelijk wie de ontwikkelaar is binnen een open source project. Toch blijft de verantwoordelijkheid bij de fabrikant. De verantwoordelijkheid kan niet worden doorgeschoven naar de ontwikkelaar van de open source component.
Fabrikanten kunnen in hun overeenkomst met softwareleveranciers eventueel een vrijwaringsclausule opnemen met betrekking tot geëxploiteerde kwetsbaarheden, doch een dergelijke contractuele vrijwaring is doorgaans onmogelijk bij open source software. Samenwerking met stewards zal dus belangrijk zijn.
5. Verplichte onderhoudsperiode van vijf jaar
Fabrikanten zijn verplicht om beveiligingsupdates te voorzien gedurende een onderhoudsperiode van minstens vijf jaar, tenzij de verwachte levensduur van het product korter is. Deze updates moeten ook betrekking hebben op open source componenten binnen het product.
Dit betekent dat ontwikkelaars hun producten moeten ontwerpen met het oog op langdurig onderhoud. Businessmodellen zullen moeten worden aangepast: software mag niet meer “as is” worden geleverd. Langlopende ondersteuning moet vooraf gepland worden en zal financiële impact hebben. Hoewel beveiligingsupdates kosteloos moeten zijn voor de gebruiker, zullen fabrikanten deze kosten elders moeten recupereren zoals via een verhoging van licentieprijzen.
6. Geharmoniseerde normen en attestatie
De CRA voorziet in de ontwikkeling van geharmoniseerde Europese normen voor cyberveiligheid van software. Deze normen worden opgesteld door normalisatie-instanties (denk aan CEN-CENELEC) en moeten fabrikanten helpen om te voldoen aan de juridische vereisten. Voor open source software kunnen vrijwillige beveiligingsattestaties worden ingevoerd.
Hoewel het gebruik van deze normen vrijwillig is, ontstaat er wel een vermoeden van conformiteit bij naleving. Ontwikkelaars zullen dus geneigd zijn om zich aan deze normen te conformeren.
De inhoud van de normen is nog niet bekend. De uitdaging ligt erin om bestaande best practices — vooral uit open source gemeenschappen zoals Linux en Eclipse — niet te negeren. Er is bovendien nood aan voortdurende actualisatie van normen om nieuwe dreigingen het hoofd te bieden.
7. Conclusie
De CRA zet een belangrijke stap richting een veiliger digitaal Europa, maar vraagt veel van softwareontwikkelaars. Zeker in de context van open source software en kleinschalige bedrijven is de praktische toepasbaarheid van sommige verplichtingen nog onzeker.
Softwareontwikkelaars — groot én klein — worden geconfronteerd met hogere nalevingskosten, nieuwe aansprakelijkheidsrisico’s en verplicht onderhoud. Open source projecten worden slechts gedeeltelijk ontzien, maar ook daar ontstaan nieuwe verantwoordelijkheden. De CRA verplicht ontwikkelaars tot meer samenwerking, documentatie en risicoanalyse.
Hoewel de CRA voorziet in nuance en uitzonderingen, blijft de kernboodschap duidelijk: cybersecurity is voortaan geen vrijblijvende optie meer, maar een wettelijke verplichting. De impact van de CRA op de Europese software-industrie zal voelbaar zijn. Wie actief is in softwareontwikkeling doet er goed aan zich tijdig voor te bereiden op deze nieuwe verplichtingen die vanaf 2026 van toepassing zullen zijn.
Als advocatenkantoor gespecialiseerd in technologie- en ICT-recht volgen wij deze ontwikkelingen op de voet. Wij begeleiden softwareontwikkelaars, distributeurs én open source-stewards bij het naleven van hun juridische verplichtingen onder de CRA.
