De EU Cyberweerbaarheidsverordening (Verordening (EU) 2024/2847) verplicht fabrikanten kwetsbaarheden tijdens de ondersteuningsperiode af te handelen en beschikbare beveiligingsupdates zonder vertraging en kosteloos te verspreiden. Deze pagina behandelt de leveringsmechanismen voor updates bij embedded, standalone, SaaS- en hybride architecturen. Voor de duurmechanismen zie basis van de ondersteuningsperiode; voor openbaarmaking vóór aankoop zie openbaarmaking einddatum ondersteuning.
Samenvatting
- Beveiligingsupdates zijn geen functie-updates. Een wijziging die een kwetsbaarheid verhelpt volgt de beveiligingsupdateplichten; een nieuwe functionaliteit niet.
- Beveiligingsfixes horen niet achter betaalde niveaus. Beschikbare beveiligingsupdates moeten zonder vertraging en kosteloos worden verspreid, vergezeld van adviesberichten aan gebruikers over wat de update verhelpt en welke actie zij moeten ondernemen, behalve bij een afwijkende afspraak voor maatwerkproducten voor zakelijke gebruikers.
- Automatisch waar van toepassing. Automatische beveiligingsupdates zijn het standaardontwerp waar dat zinvol is, met veilige distributiemechanismen en duidelijke gebruikerscontrole.
- Patchdoelen moeten de ernst volgen. Praktische doelen zijn dagen voor actief uitgebuite kritieke kwetsbaarheden, 30 dagen voor hoog, 90 dagen voor gemiddeld en de volgende reguliere cyclus voor laag.
- De architectuur bepaalt het leveringsmodel. Embedded firmware, standalone software, SaaS en hybride producten hebben elk eigen updatemechanismen die in de technische documentatie moeten staan.
- Melding en updatecyclus grijpen in elkaar. Bij een actief uitgebuite kwetsbaarheid loopt de 24-uurs vroege waarschuwing aan het coördinerend CSIRT en ENISA parallel aan het patchproces; het updatemechanisme moet de meldingsworkflow voeden.
De vier ankerpunten van CRA-naleving voor beveiligingsupdates: kostenregel, distributievoorkeur, beschikbaarheid van updates en boetemodel.
Voor boetecategorieën, zie de gids voor sancties en handhaving.
Wat als beveiligingsupdate telt
De updateplicht begint bij de cyberbeveiligingsrisicobeoordeling van het product en de toepasselijke beveiligingseigenschappen. Veilige standaardconfiguratie, vertrouwelijkheid, integriteit en beschikbaarheid bepalen of een wijziging beveiligingsrelevant is. De fabrikant moet kwetsbaarheden vervolgens effectief behandelen gedurende de ondersteuningsperiode.
Een beveiligingsupdate is een wijziging die een kwetsbaarheid verhelpt: een zwakte in het product die kan worden misbruikt om vertrouwelijkheid, integriteit of beschikbaarheid te schaden. Het onderscheid met een functie-update is belangrijk om twee redenen: beschikbare beveiligingsupdates moeten kosteloos zijn en zonder vertraging worden verspreid; functie-updates dragen die verplichtingen niet.
| Updatetype | Beveiligingsupdateverplichting | Mag dit worden berekend? |
|---|---|---|
| Patch voor een bekende CVE | Ja (beveiligingsupdate) | Nee |
| Hardening die de aanvalsvlak verkleint | Ja (beveiligingsupdate) | Nee |
| Nieuwe functie zonder beveiligingsrelevantie | Nee | Ja |
| Hoofdversie met nieuwe mogelijkheden | Nee (tenzij deze beveiligingsfixes bevat) | Ja |
| Dependency-update die een bekende kwetsbaarheid verwijdert | Ja (beveiligingsupdate) | Nee |
| Configuratiewijziging die een beveiligingsgat sluit | Ja (beveiligingsupdate) | Nee |
Zonder vertraging is niet numeriek gedefinieerd in de verordening. Fabrikanten moeten toch ernstgebaseerde operationele doelen vastleggen, zodat patchbesluiten consistent, gedocumenteerd en uitlegbaar zijn. Het diagram toont een praktisch patchvenster per ernstniveau, gemeten vanaf het moment waarop de fabrikant kennis krijgt van de kwetsbaarheid:
| Ernst | Praktisch operationeel doel |
|---|---|
| Kritiek (actief uitgebuit) | Dagen, geen weken |
| Hoog (eenvoudig op afstand misbruikbaar) | Binnen 30 dagen |
| Gemiddeld | Binnen 90 dagen |
| Laag | In de volgende reguliere cyclus |
Dit zijn geen door de CRA opgelegde termijnen. Het zijn interne doelen waarmee de fabrikant kan aantonen dat vertraging beheerst, risicogebaseerd en gedocumenteerd was.
Hoe CRA-beveiligingsupdates te leveren
Automatische updates
Waar technisch haalbaar en passend zijn automatische beveiligingsupdates het voorkeursontwerp. Een conform automatisch model moet beveiligingsupdates standaard inschakelen, een duidelijk opt-outmechanisme bieden, beschikbare updates melden, tijdelijke uitstelopties bieden waar passend en updates veilig verspreiden.
Een robuust automatisch updatemechanisme biedt:
- Veilig downloadkanaal (TLS, ondertekende pakketten)
- Integriteitscontrole vóór installatie
- Terugrolmogelijkheid als een update mislukt
- Goede afhandeling van connectiviteitsproblemen
- Zichtbaarheid van de updatestatus voor de gebruiker
De gebruiker moet automatische updates kunnen uitschakelen, met een duidelijke waarschuwing over de beveiligingsgevolgen. Bij kritieke updates moet de fabrikant elke niet-uitstelbare ontwerpkeuze documenteren in de risicobeoordeling en technische documentatie.
Handmatige updates
Producten die geen automatische updates kunnen ontvangen (air-gapped industriële systemen, embedded apparaten zonder connectiviteit, bepaalde medische of veiligheidskritieke apparatuur) hebben een handmatig proces nodig:
- Downloadbare pakketten met duidelijke versienummers
- Cryptografische handtekeningen en gepubliceerde publieke sleutels voor verificatie
- Installatiedocumentatie
- Melding via alle beschikbare kanalen (e-mail, webportaal, productinterface, fysieke melding indien nodig)
Embedded en SaaS: verschillende updatemodellen
Het leveringsmechanisme verschilt sterk per productarchitectuur:
| Producttype | Updatemodel | Belangrijke CRA-overweging |
|---|---|---|
| Embedded firmware (IoT, industrieel) | Fabrikant levert ondertekende firmware; klant past die toe | OTA of gedocumenteerd handmatig proces nodig; lange levensduur kan support boven vijf jaar vereisen |
| Standalone software (desktop, server) | Fabrikant publiceert pakket; klant installeert | Automatische updateagent verdient voorkeur; versiepinning door zakelijke klanten creëert multiversiesupport |
| SaaS / cloud-hosted | Fabrikant controleert de omgeving; updates zijn transparant | Eerst bevestigen of de dienst binnen het toepassingsgebied valt als product met digitale elementen of remote dataverwerkingsoplossing |
| Hybride (on-premises agent + cloudbackend) | Agentupdates zijn fabrikantgestuurd; backendupdates zijn transparant | Elk component heeft een eigen ondersteuningsperiode; de agent is het product met digitale elementen dat de klok bepaalt |
Voor bredere kwetsbaarheidsafhandeling buiten updatelevering (CVD-beleid, publieke openbaarmaking, melding aan derden), zie de gids voor kwetsbaarheidsafhandeling.
Meldingsverplichtingen tijdens updatelevering
CRA-melding legt tijdgebonden verplichtingen op voor actief uitgebuite kwetsbaarheden en ernstige incidenten die de productbeveiliging raken. Het updateproces moet de feiten verzamelen die voor die meldingen nodig zijn, omdat het eindrapport details over de beveiligingsupdate of andere beschikbaar gestelde corrigerende maatregelen moet bevatten.
De interactie is operationeel:
| Trigger | Plicht in de updateworkflow |
|---|---|
| Actief uitgebuite kwetsbaarheid | Leg kennisnametijd, getroffen producten, exploitfeiten, mitigatiestatus en updatedetails vast voor de 24-uurs-, 72-uurs- en eindrapportage. |
| Ernstig incident | Leg impact, vermoedelijke onrechtmatige of kwaadaardige oorzaak, eerste beoordeling, mitigatiemaatregelen en gebruikersgerichte correcties vast. |
| Gebruikersmelding | Bereid duidelijke instructies voor risicobeperking en correctie voor getroffen gebruikers en, waar passend, alle gebruikers voor. |
Behandel melding niet als een aparte latere taak. Informatie uit support, PSIRT, telemetrie, klantenservice of deployment moet snel naar de meldingsverantwoordelijke gaan wanneer een meldingsdrempel mogelijk is bereikt.
Voor de volledige termijnmechaniek, inclusief wat elke melding moet bevatten en hoe de twee meldstromen verschillen, zie de gids voor kwetsbaarheidsmelding.
Beschikbaarheid van beveiligingsupdates na publicatie
Een patch eenmaal beschikbaar maken is niet genoeg. Elke beveiligingsupdate die tijdens de ondersteuningsperiode aan gebruikers beschikbaar is gesteld, moet na uitgifte ten minste 10 jaar beschikbaar blijven, of voor de rest van de ondersteuningsperiode als die langer is. Dat verandert releasebeheer: oude pakketten, adviezen, handtekeningen, hashes en installatie-instructies hebben duurzame hosting en versietraceerbaarheid nodig.
De publieke gebruikersinformatie moet ook aangeven welk type technische beveiligingsondersteuning de fabrikant biedt en wat de einddatum van de ondersteuningsperiode is. Voor het pre-aankoopmodel, zie bekendmaking einde ondersteuning.
Veelgemaakte fouten
Transitive afhankelijkheden negeren. De meeste kwetsbaarheden in verbonden producten komen uit bibliotheken en componenten van derden, niet uit eigen code. De kwetsbaarheidsafhandelingsplicht dekt het hele product, inclusief componenten. Een SBOM is de voorwaarde. Zie de SBOM-clustergids voor het dependency-trackingkader.
Betalen voor beveiligingsupdates. Beveiligingsfixes bundelen in een betaald supportniveau botst met het basale CRA-updatemodel, tenzij de uitzondering voor zakelijke maatwerkproducten geldt. Basisbeveiligingspatches moeten kosteloos zijn.
Veelgestelde vragen
Moeten beveiligingsupdates altijd gratis zijn?
Ja, beschikbare beveiligingsupdates moeten kosteloos zijn, tenzij de smalle uitzondering voor zakelijke maatwerkproducten geldt. Een fabrikant kan een kwetsbaarheidsfix niet in een betaald abonnement, premiumsupportniveau of betaalde hoofdversie-upgrade bundelen en dat als normale CRA-compliance behandelen. Functie-updates, nieuwe functionaliteit en professionele diensten kunnen afzonderlijk worden berekend. De grens is of de wijziging een geïdentificeerd beveiligingsprobleem in het product verhelpt.
Hoe snel moet een fabrikant een beveiligingsupdate onder de CRA uitbrengen?
De CRA stelt geen vaste patchtermijn. Fabrikanten hebben daarom gedocumenteerde doelen per ernstniveau nodig. Kritieke actief uitgebuite kwetsbaarheden moeten in dagen worden behandeld, hoge ernst rond 30 dagen, gemiddelde ernst rond 90 dagen en lage ernst in de volgende reguliere cyclus, tenzij de risicobeoordeling een ander doel rechtvaardigt. Houd de werkelijke tijd tot patchen per kwetsbaarheid bij, zodat vertraging zichtbaar, risicogebaseerd en uitlegbaar blijft.
Vereist de CRA automatische updates?
Niet in alle gevallen. Automatische beveiligingsupdates zijn vereist waar van toepassing, en het product moet ook beschikbare updates melden en tijdelijk uitstel toestaan. Voor betrouwbaar verbonden consumentenproducten is dit meestal het verwachte ontwerp. Voor air-gapped industriële systemen, bepaalde medische apparaten of veiligheidskritieke apparatuur kan een gedocumenteerd handmatig proces gerechtvaardigd zijn. De technische documentatie moet de gekozen aanpak uitleggen en de gebruikersinformatie moet uitleggen hoe automatische installatie kan worden uitgeschakeld.
Heeft een SaaS-product een CRA-ondersteuningsperiode?
Dat hangt ervan af of de dienst binnen het toepassingsgebied valt als product met digitale elementen of remote dataverwerkingsoplossing. Zuivere zelfstandige SaaS die niet is verbonden met hardware, downloadbare software of fabrikantverantwoordelijke remote verwerking valt doorgaans buiten dit updatemodel. Bevat het aanbod een on-premises agent, downloadbare client, hardwaregateway of gedekte remote verwerking, breng dan de ondersteuningsperiode en het updatemechanisme voor het betreffende component in kaart. De gebruikersinformatie heeft nog steeds het supporttype en de einddatum nodig.
Wat gebeurt er met beveiligingsupdates na afloop van de CRA-ondersteuningsperiode?
De gewone kwetsbaarheidsafhandelingsplicht is gekoppeld aan de ondersteuningsperiode, maar al uitgegeven updates moeten beschikbaar blijven. Elke beveiligingsupdate die tijdens de ondersteuningsperiode beschikbaar is gesteld, moet na uitgifte ten minste 10 jaar beschikbaar blijven of voor de rest van de ondersteuningsperiode als die langer is. Fabrikanten moeten het einde van support vooraf duidelijk communiceren en gebruikersinstructies beschikbaar houden voor de vereiste periode. Zeg niet dat meldingen na einde support kunnen worden genegeerd zonder juridische check per geval.