Artikel 13(8) van de EU Verordening cyberweerbaarheid (Verordening (EU) 2024/2847) verplicht fabrikanten beveiligingsupdates kosteloos en zonder onnodige vertraging te leveren gedurende de gehele ondersteuningsperiode. Deze pagina behandelt de leveringsmechanismen voor updates bij embedded, standalone, SaaS- en hybride architecturen. Voor de duurmechanismen zie CRA-ondersteuningsperiode: de vijfjaarsdrempel; voor de openbaarmaking vóór aankoop zie openbaarmaking einddatum ondersteuning.
Samenvatting
- Beveiligingsupdates zijn geen functie-updates. Een wijziging die een kwetsbaarheid verhelpt, valt onder de kosten- en tijdschema-regels van Artikel 13(8); een wijziging die nieuwe mogelijkheden toevoegt, niet.
- Kosteloos op grond van Artikel 13(8). Fabrikanten mogen beveiligingsfixes niet bundelen in betaalde abonnementen, premiumabonnementen of betaalde hoofdversie-upgrades.
- Automatisch waar haalbaar op grond van Bijlage I Deel II. Punt 7) vereist veilige distributiemechanismen met automatische levering waar van toepassing; punt 8) vereist verspreiding zonder vertraging.
- "Zonder onnodige vertraging" is gekoppeld aan ernst. Sectorstandaard verwachtingen zijn: dagen voor actief uitgebuite kritieke problemen, 30 dagen voor ernstige kwetsbaarheden, 90 dagen voor gemiddelde kwetsbaarheden en de eerstvolgende reguliere cyclus voor lage kwetsbaarheden.
- De architectuur bepaalt het leveringsmodel. Embedded firmware, standalone software, SaaS en hybride producten kennen elk eigen updatemechanismen die in het technisch dossier moeten worden gedocumenteerd.
- Artikel 14-melding heeft raakvlakken met de updatelevenscyclus. Wanneer een actief uitgebuite kwetsbaarheid wordt ontdekt, loopt de vroege waarschuwing van 24 uur aan ENISA gelijktijdig met het patchproces; het updatemechanisme moet worden gekoppeld aan de meldingsworkflow.
De vier ankerpunten van CRA-nalevingsplicht voor beveiligingsupdates: de kostenregel, de distributievoorkeur, de tijdschema-verwachting en het boeteplafond.
Betaling vragen voor beveiligingsupdates is een van de meest directe routes naar een bevinding van niet-naleving. Als een fix die een kwetsbaarheid verhelpt uitsluitend beschikbaar is voor klanten op een betaald ondersteuningsniveau, achter een premiumabonnement of als onderdeel van een hoofdversie-upgrade die als nieuwe release wordt geprijsd, voldoet die regeling niet aan Artikel 13(8). Basisbeveiligingspatches moeten beschikbaar zijn voor alle gebruikers van het product zoals het op de markt is gebracht, zonder extra kosten, gedurende de volledige ondersteuningsperiode. Functiereleases, professionele diensten en optionele mogelijkheden mogen nog steeds in rekening worden gebracht. De scheidslijn is of de wijziging een kwetsbaarheid verhelpt.
Wat als beveiligingsupdate telt
Artikel 13(2) van de Verordening cyberweerbaarheid verplicht fabrikanten producten te ontwerpen en te produceren die "standaard veilig" zijn en die "de vertrouwelijkheid, integriteit en beschikbaarheid van gegevens" waarborgen. Artikel 13(8) vereist vervolgens dat kwetsbaarheden die na marktplaatsing worden ontdekt, gedurende de volledige ondersteuningsperiode worden afgehandeld.
Een beveiligingsupdate in de zin van de Verordening cyberweerbaarheid is een wijziging die een kwetsbaarheid verhelpt: een zwakte in het product die kan worden misbruikt om de vertrouwelijkheid, integriteit of beschikbaarheid in gevaar te brengen. Het onderscheid met een functie-update is om twee redenen relevant: beveiligingsupdates moeten kosteloos zijn en zonder onnodige vertraging worden geleverd, terwijl functie-updates niet aan deze verplichtingen zijn onderworpen.
| Type update | Verplichting op grond van Artikel 13(8) | Mag in rekening worden gebracht? |
|---|---|---|
| Patch die een bekende CVE verhelpt | Ja (beveiligingsupdate) | Nee |
| Hardeningswijziging die het aanvalsoppervlak verkleint | Ja (beveiligingsupdate) | Nee |
| Nieuwe functie zonder beveiligingsrelevantie | Nee | Ja |
| Hoofdversie met nieuwe mogelijkheden | Nee (tenzij beveiligingsfixes inbegrepen) | Ja |
| Afhankelijkheidsupdate om een bekende kwetsbaarheid te elimineren | Ja (beveiligingsupdate) | Nee |
| Configuratiewijziging om een beveiligingslek te dichten | Ja (beveiligingsupdate) | Nee |
"Zonder onnodige vertraging" is in de verordening niet numeriek gedefinieerd, maar de algemene verwachting van markttoezichtautoriteiten en ENISA-richtsnoeren sluit aan bij de sectorpraktijk. Het onderstaande diagram toont het patchvenster per ernsttier, gemeten vanaf het moment waarop de kwetsbaarheid wordt bekendgemaakt (T0):
| Ernst | Sectorstandaard verwachting |
|---|---|
| Kritiek (actief uitgebuit) | Dagen, niet weken |
| Hoog (op afstand eenvoudig uitbuitbaar) | Binnen 30 dagen |
| Gemiddeld | Binnen 90 dagen |
| Laag | Opgenomen in de eerstvolgende reguliere updatecyclus |
Dit zijn geen CRA-verplichte tijdlijnen, maar zij vertegenwoordigen de maatstaf waaraan "zonder onnodige vertraging" zal worden getoetst in handhavingsprocedures.
Hoe CRA-beveiligingsupdates te leveren
Automatische updates
Waar technisch haalbaar en passend, geven Artikel 13(8) en Bijlage I Deel II de voorkeur aan automatische beveiligingsupdates. Het product moet updates kunnen ontvangen en toepassen zonder dat de gebruiker handmatig hoeft in te grijpen.
Vereisten voor een conform automatisch updatemechanisme:
- Veilig downloadkanaal (TLS, ondertekende pakketten)
- Integriteitsverificatie vóór installatie
- Terugrolmogelijkheid indien een update mislukt
- Correcte afhandeling van verbindingsproblemen
- Zichtbaarheid voor de gebruiker over de updatestatus
De gebruiker moet de mogelijkheid behouden om automatische updates uit te schakelen, met een duidelijke waarschuwing over de beveiligingsgevolgen daarvan. Voor kritieke beveiligingsupdates mag de fabrikant het systeem zodanig ontwerpen dat de update zonder uitstel wordt toegepast. Artikel 13(8) ondersteunt dit wanneer het risico dit rechtvaardigt.
Handmatige updates
Producten die geen automatische updates kunnen ontvangen (air-gapped industriële systemen, embedded apparaten zonder verbinding, bepaalde medische apparatuur of veiligheidskritieke apparatuur) vereisen een handmatig updatleveringsproces:
- Downloadbare updatepakketten met duidelijke versieannotaties
- Cryptografische handtekeningen en gepubliceerde publieke sleutels voor verificatie
- Installatiedocumentatie
- Kennisgeving via alle beschikbare kanalen (e-mail, webportaal, productinterface, fysieke kennisgeving indien noodzakelijk)
Embedded en SaaS: verschillende updatemodellen
Het updateleveringsmechanisme verschilt wezenlijk afhankelijk van de productarchitectuur:
| Producttype | Updatemodel | Belangrijkste CRA-overweging |
|---|---|---|
| Embedded firmware (IoT, industrieel) | Fabrikant pusht ondertekende firmware; klant past toe | Moet OTA-mogelijkheid of gedocumenteerd handmatig proces hebben; lange levensduur van apparaten kan de verwachte gebruiksperiode naar bijna vijf jaar duwen |
| Standalone software (desktop, server) | Fabrikant brengt pakket uit; klant installeert | Automatische update-agent heeft de voorkeur; versievergrendeling door zakelijke klanten creëert last van ondersteuning voor meerdere versies |
| SaaS / cloud-hosted | Fabrikant beheert de omgeving; updates zijn transparant voor de gebruiker | De klok begint nog steeds bij marktplaatsing; de ondersteuningsperiode is hoofdzakelijk relevant voor on-premises of hybride componenten; API-versiebeheer schept eigen ondersteuningsverplichtingen |
| Hybride (on-premises agent + cloud-backend) | Agent-updates worden beheerd door de fabrikant; backend-updates zijn transparant | Elk onderdeel heeft zijn eigen ondersteuningsperiodeklok; de agent is het product met digitale elementen en die klok is bepalend |
Voor bredere afhandeling van kwetsbaarheden op grond van Bijlage I Deel II buiten de updatelevering (CVD-beleid, publieke openbaarmaking, meldingen door derden), zie de handleiding kwetsbaarheidsafhandeling.
Meldingsverplichtingen voor kwetsbaarheden tijdens en na de ondersteuningsperiode
Artikel 14 legt tijdsgebonden meldingsverplichtingen op aan fabrikanten voor actief uitgebuite kwetsbaarheden en ernstige incidenten. Deze verplichtingen gelden gedurende de ondersteuningsperiode.
De voornaamste wisselwerking:
| Fase | Meldingsplicht op grond van Artikel 14 |
|---|---|
| Tijdens de ondersteuningsperiode | Artikel 14 is volledig van toepassing: vroege waarschuwing binnen 24 uur, kennisgeving binnen 72 uur, eindrapport binnen 14 dagen voor actief uitgebuite kwetsbaarheden; 24 uur / 72 uur / 1 maand voor ernstige incidenten. Via het ENISA Single Reporting Platform. |
| Na afloop van de ondersteuningsperiode | Geen meldingsplicht op grond van Artikel 14 voor kwetsbaarheden die na het EOL worden ontdekt. Indien de fabrikant kennis krijgt van een kritieke, actief uitgebuite kwetsbaarheid in een niet meer ondersteund product dat een groot geïnstalleerd bestand treft, bestaat er geen verplichte meldingsplicht. Verantwoorde openbaarmaking en gebruikersnotificatie worden sterk aanbevolen vanwege reputatie- en markttoezichtoverwegingen. |
Het einddatumtijdstip van de ondersteuningsperiode is daarmee tevens de horizon voor Artikel 14. Zodra de ondersteuningsperiode verloopt, heeft de fabrikant geen verplichting om kwetsbaarheden in die productversie te onderzoeken, te patchen of te melden. Markttoezichtautoriteiten kunnen nog steeds onderzoek instellen op grond van Artikel 58 als het product een aanzienlijk cyberbeveiligingsrisico vormt, maar de doorlopende kwetsbaarheidsbeheerverplichting op grond van Artikel 13(8) is beëindigd.
Voor de volledige tijdlijnmechanismen van Artikel 14, inclusief wat elk rapport moet bevatten en hoe de twee meldingsstromen (actief uitgebuite kwetsbaarheden en ernstige incidenten) van elkaar verschillen, zie de handleiding kwetsbaarheidsmelding.
Veelgemaakte fouten
Transitieve afhankelijkheden negeren. De meeste kwetsbaarheden in verbonden producten zijn afkomstig uit bibliotheken en componenten van derden, niet uit eigen code. De verplichting van Artikel 13(8) geldt voor het gehele product, niet alleen voor de code die de fabrikant zelf heeft geschreven. Een SBOM is hiervoor de voorwaarde. Zie de SBOM-clustergids voor het kader voor afhankelijkheidsbewaking dat transitieve kwetsbaarheidsmonitoring operationeel maakt.
Betaling vragen voor beveiligingsupdates. Het bundelen van beveiligingsfixes in een betaald ondersteuningsniveau is in strijd met Artikel 13(8). Basisbeveiligingspatches moeten kosteloos zijn.
Veelgestelde vragen
Moeten beveiligingsupdates altijd gratis zijn?
Ja. Artikel 13(8) verplicht fabrikanten beveiligingsupdates kosteloos te verstrekken. Een fabrikant mag een beveiligingsfix niet bundelen in een betaald abonnement, een premiumondersteuningsniveau of een hoofdversie-upgrade en claimen te voldoen aan Artikel 13(8). Functie-updates, nieuwe functionaliteit en betaalde professionele diensten zijn afzonderlijk en mogen normaal in rekening worden gebracht. De verplichting beperkt zich tot updates die kwetsbaarheden verhelpen: wijzigingen die een beveiligingszwakte in het product zoals het op de markt is gebracht, oplossen.
Hoe snel moet een fabrikant een beveiligingsupdate uitbrengen onder de Verordening cyberweerbaarheid?
Artikel 13(8) van de Verordening cyberweerbaarheid vereist beveiligingsupdates "zonder onnodige vertraging", maar definieert geen numerieke deadline. Markttoezichtautoriteiten en ENISA-richtsnoeren sluiten aan bij de sectorpraktijk op basis van ernst: kritieke, actief uitgebuite kwetsbaarheden moeten binnen dagen worden gepatcht, ernstige kwetsbaarheden binnen ongeveer 30 dagen, gemiddelde kwetsbaarheden binnen 90 dagen en lage kwetsbaarheden gebundeld in de eerstvolgende reguliere updatecyclus. Dit zijn geen CRA-verplichte tijdlijnen, maar zij vertegenwoordigen de maatstaf waaraan "zonder onnodige vertraging" zal worden getoetst in handhavingsprocedures. Fabrikanten dienen de werkelijke tijd tot het patchen per CVE bij te houden, zodat afwijkingen van deze basislijn zichtbaar en verdedigbaar zijn.
Zijn automatische updates verplicht op grond van de Verordening cyberweerbaarheid?
Niet in alle gevallen. Bijlage I Deel II punt 7) verplicht fabrikanten veilige distributiemechanismen met automatische levering te bieden "waar van toepassing". Voor producten met betrouwbare connectiviteit en geen operationele reden om updates uit te stellen, zijn automatische updates de verwachte standaard. Voor air-gapped industriële systemen, bepaalde medische apparaten of veiligheidskritieke apparatuur waarbij automatische patchinstallatie de bedrijfsvoering kan verstoren, is een gedocumenteerd handmatig updateproces aanvaardbaar. Het Bijlage VII-technisch dossier moet de gekozen aanpak onderbouwen. Gebruikers moeten de mogelijkheid behouden om automatische updates uit te schakelen met duidelijke waarschuwingen over de beveiligingsgevolgen, behalve wanneer het risico een niet-uittelbare kritieke fix rechtvaardigt.
Heeft een SaaS-product een ondersteuningsperiode op grond van de Verordening cyberweerbaarheid?
Dat hangt ervan af of het SaaS-product onder het toepassingsgebied van de Verordening cyberweerbaarheid valt als product met digitale elementen. Zuivere SaaS-diensten die niet zijn gebundeld met een hardwarecomponent of downloadbare software-agent vallen over het algemeen buiten het toepassingsgebied op grond van Artikel 2(1). Indien een SaaS-product een on-premises agent, een downloadbare client of een hardwaregateway omvat die op de EU-markt wordt gebracht, valt dat onderdeel wel onder het toepassingsgebied en begint de Artikel 13(8)-ondersteuningsperiodeklok bij marktplaatsing. De cloud-hosted backend, wanneer onder de controle van de fabrikant en voortdurend bijgewerkt, voldoet doorgaans aan de patchverplichting "zonder onnodige vertraging" via transparante implementatie, maar de fabrikant moet de ondersteuningsverbintenis nog steeds documenteren in de Bijlage II-informatie voor het onderdeel dat onder het toepassingsgebied valt.
Wat gebeurt er met beveiligingsupdates na afloop van de CRA-ondersteuningsperiode?
De verplichtingen op grond van Artikel 13(8) eindigen met de ondersteuningsperiode. Zodra de bekendgemaakte einddatum is verstreken, heeft de fabrikant geen CRA-verplichting meer om kwetsbaarheden in die productversie te onderzoeken, te patchen of te distribueren, en de meldingsverplichtingen op grond van Artikel 14 vervallen eveneens, omdat deze uitsluitend van toepassing zijn gedurende de ondersteuningsperiode. Markttoezichtautoriteiten kunnen nog steeds onderzoek instellen op grond van Artikel 58 als het product na het einde van de levensduur een aanzienlijk cyberbeveiligingsrisico vormt, maar de dagelijkse kwetsbaarheidsbeheerverplichting is beëindigd. Fabrikanten dienen het einde van de ondersteuning vooraf duidelijk aan gebruikers te communiceren; de Bijlage II punt k)-openbaarmaking van de einddatum is het op gebruikers gerichte instrument daarvoor. Goodwill-patches na het EOL blijven geoorloofd, maar zijn niet verplicht.