Artikel 69(2) van de Cyber Resilience Act, Verordening (EU) 2024/2847, zegt dat producten met digitale elementen die vóór 11 december 2027 in de handel zijn gebracht "alleen onder de eisen van deze verordening vallen indien zij vanaf die datum substantieel worden gewijzigd". De meldplicht van artikel 14 geldt hoe dan ook voor ze, sinds 11 september 2026. Al het andere, de essentiële eisen van bijlage I, de conformiteitsbeoordeling, het technisch dossier, de CE-markering, wacht op de eerste substantiële wijziging. Voor een softwarebedrijf met een product dat al op de markt is, is "wat is een substantiële wijziging" dus de vraag die beslist of, en wanneer, de verordening dat product überhaupt bereikt. En voor een product dat na die datum in de handel wordt gebracht, beslist zij of een release een nieuwe conformiteitsbeoordeling nodig heeft.

De verordening definieert de term in artikel 3(30) en licht hem toe in overweging 39, en de richtsnoeren van de Commissie van 27 juli 2026, C(2026) 5252, deel 4.3, punten 103 tot 113, passen hem toe op software-updates, met elf uitgewerkte voorbeelden. De delen 4.4.2 en 5 zeggen wat eruit volgt. Dit artikel is die punten, gelezen voor een team dat elke week uitlevert.

De toets is de risicobeoordeling, niet de omvang van de wijziging

Punt 104 herhaalt overweging 39: een product is substantieel gewijzigd "wanneer een wijziging het niveau van het cyberbeveiligingsrisico verandert, en wanneer dat veranderde of extra risico niet door de fabrikant in zijn risicobeoordeling en bijgevolg in zijn uitvoering van de essentiële eisen in aanmerking is genomen". De fabrikant "moet daarom per geval beoordelen of een software-update nieuwe of grotere cyberbeveiligingsrisico's introduceert, en of die risico's al in zijn risicobeoordeling waren behandeld".

Daaruit volgen twee dingen, en de richtsnoeren trekken beide conclusies. Ten eerste is een verandering van het beoogde doel van het product er waarschijnlijk een: punt 105 zegt dat waar nieuwe functies "leiden tot een verandering van het beoogde doel van het product als geheel, het waarschijnlijk is dat de fabrikant die veranderingen niet in zijn risicobeoordeling in aanmerking heeft genomen", en voorbeeld 40 is een monitoringdashboard dat de mogelijkheid krijgt de machines aan te sturen die het bekijkt. Ten tweede is omvang niet de toets. Punt 107: "de beoordeling van een substantiële wijziging mag daarom niet gebaseerd zijn op de schaal of complexiteit van de wijziging, maar op haar mogelijke nadelige effect op het cyberbeveiligingsrisicoprofiel". Voorbeeld 44 is het voorbeeld dat elk productteam moet lezen: een functie 'onthoud mij' die authenticatietokens lokaal opslaat "introduceert nieuwe risico's van tokendiefstal, ongeoorloofde toegang en sessiekaping die niet in de risicobeoordeling in aanmerking waren genomen", en de toepassing "is substantieel gewijzigd". Voorbeeld 45 is een diagnosefunctie die gedetailleerde logboeken exporteert, ogenschijnlijk klein, die gevoelige operationele gegevens onversleuteld opslaat: substantieel gewijzigd.

De andere kant is punt 106. Waar de fabrikant "de ontwikkeling van die functies heeft voorzien, de bijbehorende risico's al heeft beschreven en beoordeeld, en passende beperkende maatregelen heeft uitgevoerd", "mag de update daarom niet" als substantiële wijziging worden beschouwd. Voorbeeld 42 is een berichtenapp waarvan de oorspronkelijke risicobeoordeling de latere invoering van groepschat dekte, "met inbegrip van bijvoorbeeld de grotere complexiteit van berichtroutering"; wanneer groepschat wordt uitgeleverd met de voorziene beheer- en moderatiecontroles, is niets substantieel gewijzigd. Voorbeeld 43 is een monitoringsysteem dat wordt geleverd met aanwezige maar uitgeschakelde en beoordeelde regelkringen; die inschakelen is geen substantiële wijziging.

Dat is het hele mechanisme. Een risicobeoordeling die de roadmap benoemt, absorbeert de roadmap. Een risicobeoordeling die eenmaal is geschreven, voor het product zoals het was, maakt van elke betekenisvolle functie een substantiële wijziging.

Beveiligingsupdates: doorgaans niet, met twee uitzonderingen

Punt 108, opnieuw uit overweging 39: "beveiligingsupdates worden doorgaans niet als substantiële wijzigingen beschouwd, aangezien hun voornaamste doel is het niveau van het cyberbeveiligingsrisico te verlagen". Dat geldt "zelfs wanneer die update aanzienlijke technische wijzigingen kan meebrengen", en het dekt functies die "uitsluitend worden gewijzigd of beperkt om vastgestelde kwetsbaarheden te beperken". Voorbeeld 46 is een correctie van een invoervalidatiefout of een sessietokencontrole. Voorbeeld 47 is verharding: firewallregels aanscherpen, poorten uitschakelen, standaardwachtwoordbeleid wijzigen, multifactorauthenticatie verplicht maken waar zij al bestond. Voorbeeld 48 is het vervangen van een verouderd algoritme door een sterker dat het ontwerp al ondersteunde.

Punt 109 geeft de uitzonderingen: een beveiligingsupdate die het beoogde doel verder verandert dan voorzien, of "de grenzen of afhankelijkheidsstructuur van het product wezenlijk verandert op een wijze die niet in de risicobeoordeling was voorzien, bijvoorbeeld door gegevensstromen wezenlijk te wijzigen of nieuwe van buitenaf bereikbare interfaces toe te voegen". Voorbeeld 49 vervangt lokale bestandsversleuteling door een door de fabrikant beheerde versleutelingsdienst op afstand: het product doet nu iets anders, dus is het ondanks het beveiligingsmotief substantieel gewijzigd. Voorbeeld 50 vervangt een intern beheerde sleutellevenscyclus door een sleutelbeheerdienst van een derde, en voegt "nieuwe externe interfaces en een afhankelijkheid van diensten van derden toe die niet in de risicobeoordeling in aanmerking waren genomen": substantieel gewijzigd.

De vier vragen aan elke release

Punt 110 somt op wat een fabrikant "in overweging kan nemen", en het is kort genoeg voor een pull-requestsjabloon. Introduceert de update:

a. nieuwe dreigingsvectoren, zoals extra interfaces, communicatiekanalen, uitvoeringsomgevingen of externe afhankelijkheden waarlangs dreigingen zich kunnen verwezenlijken; b. maakt zij nieuwe aanvalsscenario's mogelijk, met inbegrip van bijvoorbeeld nieuwe manieren waarop ongeoorloofde toegang tot, manipulatie van, verstoring van of misbruik van het product met digitale elementen, of van de gegevens die het verwerkt, zich aannemelijk zou kunnen voordoen; c. verandert zij de waarschijnlijkheid van eerder vastgestelde aanvalsscenario's, bijvoorbeeld door de inspanning of deskundigheid die nodig is om ze uit te buiten te verlagen, de blootstelling aan niet-vertrouwde actoren te vergroten of bestaande waarborgen te verzwakken; d. verandert zij de mogelijke impact van eerder vastgestelde aanvalsscenario's, met inbegrip van bijvoorbeeld de omvang van de getroffen gegevens of functies, de ernst van de operationele, veiligheids- of economische gevolgen, of het vermogen een incident te detecteren, in te dammen of ervan te herstellen.

Punt 111: vier keer nee, "mits de aannames en beperkende maatregelen waarop de risicobeoordeling steunt geldig en doeltreffend blijven", betekent dat "het daarom waarschijnlijk is dat de update niet" als substantiële wijziging kwalificeert. Punt 112: elk ja betekent dat "de fabrikant de cyberbeveiligingsrisico's opnieuw moet beoordelen" en "moet bepalen of nog aan de essentiële eisen wordt voldaan". Punt 113 voegt de plicht toe die niet van het antwoord afhangt: "ongeacht of software-updates als substantiële wijzigingen kwalificeren, zijn fabrikanten verplicht de risicobeoordeling en de technische documentatie nauwkeurig, volledig en voortdurend actueel te houden, overeenkomstig de artikelen 13(7) en 31(2)".

Wat de eerste substantiële wijziging in gang zet

Deel 4.4.2 gaat over de oorspronkelijke fabrikant, wat het gebruikelijke softwaregeval is. Punt 122: de fabrikant "blijft de fabrikant", maar "het substantieel gewijzigde product met digitale elementen moet als opnieuw in de handel gebracht worden beschouwd". Punt 123 beperkt het werk: in lijn met deel 2.1 van de Blauwe Gids "mag de fabrikant bestaande documentatie en tests hergebruiken voor aspecten van het product met digitale elementen die niet door de substantiële wijziging worden geraakt", moet de conformiteitsbeoordeling "zich richten op de substantieel gewijzigde delen", en moet een aangemelde instantie, waar die betrokken is, "haar beoordeling richten op de substantieel gewijzigde delen".

Voor software die al vóór 11 december 2027 op de markt was, is punt 124 de zin om te bewaren. Een substantiële wijziging door de oorspronkelijke fabrikant "verplicht de fabrikant op zichzelf niet het gehele vóór die datum in de handel gebrachte product met digitale elementen volledig in overeenstemming met de CRA te brengen, tenzij de wijziging de cyberbeveiliging van het product met digitale elementen als geheel negatief beïnvloedt. Waar de wijziging de cyberbeveiliging van het product met digitale elementen als geheel niet beïnvloedt, moeten de verplichtingen van de oorspronkelijke fabrikant ten aanzien van de wijziging beperkt blijven tot de substantieel gewijzigde delen." De eerste functie 'onthoud mij' na december 2027 plaatst dus het inlogpad, niet het hele bestaande product, onder bijlage I; een herschrijving die de grenzen van het product verandert, plaatst het er helemaal onder.

Deel 5 voegt de ondersteuningsperiode toe. Punt 128: "elke substantieel gewijzigde versie van een softwareproduct met digitale elementen die in de handel wordt gebracht, moet een verklaarde ondersteuningsperiode hebben die aan artikel 13(8) voldoet", ten minste vijf jaar tenzij de verwachte gebruiksduur aantoonbaar korter is, en waar de wijziging de factoren achter de oorspronkelijke verwachte gebruiksduur niet verandert, "blijft de oorspronkelijke ondersteuningsperiode onaangetast". Punt 131, voor producten die met korte tussenpozen worden uitgeleverd: de fabrikant moet voor elke substantieel gewijzigde versie een ondersteuningsperiode verklaren, en mag zich op artikel 13(10) beroepen om het verhelpen van kwetsbaarheden in eerdere versies te staken "zodra gebruikers gratis en zonder extra kosten naar een latere versie kunnen upgraden", wat punt 130 zo leest dat "verplichte aankopen van nieuwe hardware, vervanging van infrastructuur of fundamentele wijzigingen van de bedrijfsomgeving" zijn uitgesloten, maar normale upgrade-inspanning niet. Het artikel over de ondersteuningsperiode behandelt de rest van artikel 13(8).

Wat dit betekent voor een team dat wekelijks uitlevert

Drie praktijken volgen uit de punten, geen ervan nieuwe techniek.

Schrijf de roadmap in de risicobeoordeling. Punt 106 en de voorbeelden 42 en 43 belonen een risicobeoordeling die de functies benoemt die u van plan bent uit te leveren en ze beoordeelt voordat ze bestaan. Dat is goedkoper dan een nieuwe conformiteitsbeoordeling per functie, en het is het verschil tussen voorbeeld 42 en voorbeeld 44. De risicobeoordeling van artikel 13 is de plaats ervoor.

Beantwoord punt 110 in elke release. Vier vragen, vier antwoorden, elk één zin, in het releaseverslag. Waar alle vier nee zijn, zegt het verslag waarom de bestaande beoordeling nog steeds standhoudt. Waar er een ja is, wacht de release op de herbeoordeling die punt 112 vereist, en worden de risicobeoordeling en het technisch dossier bijgewerkt onder punt 113, wat hoe dan ook verschuldigd is.

Beslis de vraag over bestaande producten eenmaal. Leg voor elk product dat vóór 11 december 2027 op de markt is de versie op die datum vast, zodat de eerste substantiële wijziging daarna herkenbaar is, en leg bij elke latere release vast of het er een was en, onder punt 124, of zij de beveiliging van het product als geheel of alleen een deel raakte.

StandardOS houdt het technisch CRA-dossier en de risicobeoordeling bij als levende registraties in plaats van documenten, zodat een release kan worden gekoppeld aan de vier antwoorden en de beoordeling waarop zij steunt. Of het product überhaupt onder het toepassingsgebied valt komt eerst.

Bronnen

  • Verordening (EU) 2024/2847, artikel 3(30), artikel 13(7), (8) en (10), artikel 31(2), artikelen 21 en 22, artikel 69(2), overwegingen 39 tot 42 en 60.
  • Europese Commissie, richtsnoeren van de Commissie over de toepassing van Verordening (EU) 2024/2847, C(2026) 5252 final van 27 juli 2026, bijlage, deel 4.3 (punten 103 tot 113, voorbeelden 40 tot 50), deel 4.4 (punten 114 tot 124), deel 5 (punten 125 tot 131).
  • Europese Commissie, de Blauwe Gids voor de uitvoering van de productvoorschriften van de EU, deel 2.1, zoals de richtsnoeren hem aanhalen.

Dit is geen juridisch advies. De elf voorbeelden beslaan twee pagina's en staan dichter bij de werkelijkheid van een productteam dan wat ook in de richtsnoeren; lees ze met uw laatste tien releases ernaast.