De EU Cyber Resilience Act maakt planning van de ondersteuningsperiode een beslissing op productlanceringsmoment, geen nagedachte. Een fabrikant moet bepalen hoe lang gebruikers redelijkerwijs mogen verwachten dat kwetsbaarheden worden afgehandeld, de einddatum van ondersteuning bij aankoop publiceren en beveiligingsupdates beschikbaar houden gedurende de vereiste periode. Deze gids behandelt de duurmechaniek: wanneer de klok start, hoe de uitzondering voor korter verwacht gebruik werkt, hoe portfolio's met meerdere versies stapelen en wat upstream-leverancierscontracten moeten dekken. Zie voor de leveringscadans CRA-beveiligingsupdates; voor de gebruikersgerichte einddatum zie bekendmaking einde ondersteuning.
Samenvatting
- Vijf jaar is de ondergrens. De CRA vereist kwetsbaarheidsafhandeling gedurende ten minste vijf jaar, tenzij het product naar verwachting korter wordt gebruikt.
- De uitzondering voor korter verwacht gebruik is smal. Zij moet vóór marktplaatsing worden beoordeeld, in de technische documentatie worden vastgelegd en vóór aankoop aan gebruikers worden meegedeeld.
- De klok start bij marktplaatsing, niet bij aankoop door de klant. Voorraad die vóór verkoop in een magazijn ligt, heeft al een deel van het ondersteuningsvenster verbruikt.
- Portfolio's met meerdere versies kunnen overlappende vensters stapelen. Een beperkte softwareroute staat herstel alleen voor de nieuwste versie toe, maar alleen als gebruikers van eerdere versies gratis en zonder omgevingskosten kunnen overstappen.
- Upstream-leveranciersrisico is risico van de fabrikant. Het einde van ondersteuning bij een componentleverancier is geen verweer; leveringscontracten moeten de volledige ondersteuningsperiode dekken.
De vier signalen voor ondersteuningsplanning: minimumduur, updatekosten, documentatiebewaring en boeteblootstelling.
Wat de CRA vereist voor de ondersteuningsperiode
Een ondersteuningsperiode is het venster waarin de fabrikant het kwetsbaarheidsafhandelingsproces voor het product actief moet houden. Zij dekt het product en de componenten, start vanaf plaatsing op de EU-markt en moet lang genoeg zijn om aan te sluiten bij wat gebruikers redelijkerwijs van het gebruik mogen verwachten. De fabrikant moet dit bepalen op basis van praktisch bewijs: producttype, beoogd doel, vergelijkbare producten, relevante Unievoorschriften over levensduur, beschikbaarheid van de operationele omgeving, ondersteuning van kerncomponenten van derden en ADCO- of Commissie-richtsnoeren. Het praktische gevolg is eenvoudig: ondersteuning moet vóór lancering worden vastgesteld en gedurende het verklaarde ondersteuningsvenster actief blijven.
De verplichting heeft drie onderdelen:
| Onderdeel | Operationele regel | Te bewaren bewijs |
|---|---|---|
| DuurHoe lang ondersteuning duurt | Gebruik ten minste vijf jaar, tenzij de verwachte gebruiksperiode korter is. | Onderbouwing van de ondersteuningsperiode in de technische documentatie en een duidelijke einddatum bij aankoop. |
| AfhandelingWat actief moet blijven | Houd de kwetsbaarheidslevenscyclus draaiend: bevindingen documenteren, zonder vertraging herstellen, opgeloste problemen openbaar maken, CVD uitvoeren en updates veilig verspreiden. | Kwetsbaarheidsregistraties, hersteltijdstempels, CVD-beleid, bewijs van updateverspreiding en gebruikersadviezen. |
| BeveiligingsupdatesKosten en beschikbaarheid | Verspreid beschikbare beveiligingsupdates zonder vertraging en kosteloos, behalve bij de smalle uitzondering voor maatwerk-bedrijfsproducten. | Releasegegevens die tonen wanneer fixes beschikbaar werden gemaakt en dat basisbeveiligingsfixes niet achter betaalde niveaus zaten. |
Wanneer de vijfjaarsklok begint te lopen
De ondersteuningsklok start wanneer het product de EU-markt op gaat, niet wanneer de eindklant het koopt. In EU-productrecht is dat de eerste beschikbaarstelling van het product op de Uniemarkt voor distributie of gebruik. Voor ondersteuningsplanning is de datum van marktplaatsing de datum die telt.
Klok begint: de datum waarop het product voor het eerst beschikbaar wordt gesteld aan een distributeur, detailhandelaar, importeur of gebruiker voor distributie of gebruik op de EU-markt.
Klok begint niet bij: aankoop door de klant, activering door de klant, verzending van een specifieke eenheid, of de datum waarop een klant het product installeert.
Praktisch voorbeeld:
- Januari 2028. Product v1.0 op de EU-markt geplaatst. De vijfjarige ondersteuningsperiode begint. De fabrikant is beveiligingsupdates verschuldigd tot ten minste januari 2033.
- Juni 2029. Een klant koopt v1.0 bij een detailhandelaar. De klant heeft nog circa 3,5 jaar ondersteuning over, niet vijf jaar vanaf aankoop.
- Januari 2033. De ondersteuningsperiode eindigt. De basisverplichting voor kwetsbaarheidsafhandeling voor v1.0 eindigt. Verdere gebruikersmeldingen of contact met toezichthouders hangen af van de feiten.
Beste praktijk: houd marktplaatsingsdatums bij per productversie, niet per individuele eenheid. Eén plaatsingsdatumrecord per SKU is meestal de praktische bewijsbasis om einddatums van ondersteuning te berekenen.
De uitzondering voor korter verwacht gebruik
De ondergrens van vijf jaar kan alleen worden ingekort wanneer het product werkelijk naar verwachting minder dan vijf jaar wordt gebruikt. Die uitzondering is smaller dan zij lijkt en komt uit het ondersteuningsperiode-artikel:
- De "verwachte gebruiksperiode van het product" wordt beoordeeld vanuit redelijke gebruikersverwachtingen, op basis van de aard van het product, hoe vergelijkbare producten meestal worden gebruikt en wat de fabrikant communiceert.
- De kortere periode moet in de technische documentatie worden vastgelegd en bij aankoop aan gebruikers worden meegedeeld, met ten minste de maand en het jaar van de einddatum.
- Een fabrikant kan de uitzondering niet inroepen nadat een kwetsbaarheid is ontdekt. De beoordeling moet vóór marktplaatsing worden gemaakt en in het technisch dossier worden vastgelegd.
- Voor de meeste softwareproducten, IoT-apparaten en verbonden hardware is vijf jaar het praktische minimum. De uitzondering past bij producten met een objectief korte gebruiksduur, zoals hardware voor eenmalig of beperkt cyclisch gebruik, en niet bij producten waar de fabrikant simpelweg een kortere verplichting wil.
Ondersteuning van meerdere versies
De meeste fabrikanten hebben tegelijk meerdere productversies op de markt. Hardwareproducten en zelfstandig onderhouden softwareversies kunnen overlappende ondersteuningsvensters creëren. Softwareproducten hebben daarnaast een beperkte nieuwste-versie-route voor latere wezenlijk gewijzigde versies, maar alleen als gebruikers van eerdere versies gratis en zonder extra hardware- of softwareomgevingskosten naar de nieuwste versie kunnen overstappen.
Gefaseerde ondersteuningsperioden creëren overlappende verplichtingen:
| Versie | Marktplaatsing | Ondersteuning eindigt (5 jaar) |
|---|---|---|
| v1.0 | jan 2028 | jan 2033 |
| v1.1 | jul 2028 | jul 2033 |
| v2.0 | jan 2029 | jan 2034 |
Van januari 2029 tot januari 2033, vier jaar lang, kan de fabrikant beveiligingsupdates verschuldigd zijn aan alle drie versies tegelijk, tenzij een geschikte nieuwste-versie-softwareroute geldt. Elke versie heeft haar eigen CVE-blootstelling, eigen afhankelijkheidsboom en mogelijk eigen klantenbestand. Patches terugporten over hoofdversies is technisch complex en duur.
Strategieën om de last van meerdere versies te beperken:
- Gedeelde codebase. Handhaaf waar mogelijk één beveiligingsgepatche kern waarop alle versies voortbouwen. Beveiligingsfixes die eenmaal worden toegepast, werken door naar alle versies.
- Krachtige migratie-incentives. Kortere intervallen tussen klanten op oude versies verkleinen de actieve ondersteuningsmatrix. Upgradeprijzen, gratis migratiehulpmiddelen en ondersteuningskrediet versnellen versieconsolidatie.
- Expliciet EOL-schema per versie. Publiceer de einddatum van ondersteuning voor elke versie bij marktplaatsing. Klanten die weten dat v1.0 in januari 2033 eindigt, kunnen zonder nooddruk plannen voor migratie.
- Nieuwste-versieroute voor geschikte software. Wie deze route gebruikt, documenteert hoe gebruikers van eerdere versies de nieuwste versie gratis en zonder kosten voor omgevingsaanpassing ontvangen.
Verplichtingen ten aanzien van leveranciers en upstream-contracten
De fabrikant draagt de verplichting voor de ondersteuningsperiode ook wanneer een kwetsbaarheid uit een upstream-component komt. Als het product niet kan worden gepatcht omdat een componentleverancier ondersteuning heeft beëindigd, heeft de fabrikant toch een herstelroute nodig. Het upstream-contractgat is geen verweer onder de ondersteuningsperiode-regel.
Wat dit in de praktijk betekent:
- Als een product een besturingssysteem, middleware of chipsetfirmware van derden bevat, moet de fabrikant een leveringsovereenkomst sluiten die de volledige ondersteuningsperiode dekt. Een upstream-leverancier die drie jaar beveiligingspatches levert, dwingt de fabrikant om na jaar drie de patches zelf te onderhouden of het product na het upstream-EOL niet langer op de EU-markt te plaatsen.
- Op SBOM gebaseerde afhankelijkheidsbewaking (zie de SBOM-clustergids) is het operationele mechanisme: de fabrikant kan upstream-kwetsbaarheden niet bewaken zonder te weten wat er in het product zit.
- Leverancierscontracten moeten specificeren: de duur van de upstream-patchverplichting, meldingsverplichtingen voor nieuw ontdekte kwetsbaarheden, toegang tot broncode of patchgereedschap als de upstream-leverancier het component stopzet, en vrijwaringsbepalingen voor kwetsbaarheden die hun oorsprong vinden in upstream-componenten.
Importeurs en distributeurs die een product onder hun eigen naam of merk op de markt brengen, of een al op de markt geplaatst product wezenlijk wijzigen, worden behandeld als fabrikanten en nemen de fabrikantverplichtingen over, inclusief upstream-contractrisico. Zie de gids voor importeursverplichtingen voor de beslissingsboom voor rolescalatie.
Einde-levensplanning en verantwoorde producttransities
Wanneer de ondersteuningsperiode eindigt, eindigt de basisverplichting voor kwetsbaarheidsafhandeling voor die productversie, maar een aantal verantwoordelijkheden blijft bestaan.
Wat blijft bij einde ondersteuning:
- De einddatum van ondersteuning die bij aankoop is bekendgemaakt, blijft de gebruikersgerichte toezegging.
- De technische documentatie en EU-conformiteitsverklaring moeten ten minste 10 jaar vanaf marktplaatsing of gedurende de ondersteuningsperiode worden bewaard, afhankelijk van wat langer is.
- Informatie en instructies voor gebruikers moeten beschikbaar blijven voor gebruikers en markttoezichtautoriteiten op dezelfde basis van 10 jaar of ondersteuningsperiode, ongeacht het leveringskanaal; waar zij online zijn verstrekt, moeten zij ook online beschikbaar blijven voor die periode.
- Waar technisch haalbaar dient de fabrikant gebruikers een melding te tonen zodra het product het einde van zijn ondersteuningsperiode heeft bereikt.
- Kwetsbaarheden in niet-ondersteunde producten vragen nog steeds zorgvuldige behandeling. De CRA geeft geen algemene safe-harbour-zin voor elke meldingsvraag bij einde ondersteuning, en markttoezichtautoriteiten kunnen nog steeds optreden waar een product een aanzienlijk cyberbeveiligingsrisico vormt. Boeteblootstelling wordt behandeld in de gids voor sancties en handhaving.
Communicatieverplichtingen bij einde ondersteuning:
De CRA stelt geen wettelijke opzegtermijn voor einde ondersteuning. De bekendmaking van de einddatum van ondersteuning bij aankoop betekent dat gebruikers die het product kochten nadat die bekendmaking beschikbaar was, al op de hoogte waren. Voor producten waar de oorspronkelijke bekendmaking ontbrak of onduidelijk was, is voorafgaande kennisgeving een operationele risicobeheersing en geen CRA-genummerde deadline.
Na EOL: de fabrikant moet een beveiligingscontact voor verantwoorde kwetsbaarheidsmelding behouden, productdocumentatie toegankelijk houden en meewerken aan elk onderzoek van een markttoezichtautoriteit.
Veelgemaakte fouten
-
Marktplaatsingsdatums niet bijhouden. Zonder een plaatsingsdatumrecord per versie kan de fabrikant niet berekenen wanneer ondersteuningsverplichtingen beginnen of eindigen, kan hij de gebruikersgerichte einddatum van ondersteuning niet produceren, en kan hij conformiteit niet aantonen aan markttoezichtautoriteiten.
-
Niet plannen voor upstream-EOL. Als een chipset-, OS- of middlewareleverancier ondersteuning beëindigt voordat de ondersteuningsperiode van de fabrikant afloopt, moet de fabrikant een plan hebben. Reactieve ontdekking van upstream-EOL zonder leveringsovereenkomst is een veelvoorkomende en kostbare fout.
-
Beveiligingspatches koppelen aan functie-releases. Beveiligingsfixes bundelen in grote versie-upgrades dwingt klanten nieuwe functies en een nieuw aanvalsoppervlak te accepteren om een beveiligingsfix te ontvangen. Beveiligingsfixes moeten als beveiligingsfixes worden geleverd, zonder betaalde niveaus of grote functie-upgrades af te dwingen.
Veelgestelde vragen
Wanneer begint de ondersteuningsperiode van vijf jaar?
Zij start wanneer het product op de EU-markt wordt geplaatst, niet wanneer een klant het koopt of activeert. Marktplaatsing is de eerste beschikbaarstelling van het product op de Uniemarkt, dus tijd in magazijn of bij een distributeur kan een deel van het ondersteuningsvenster verbruiken. Een product dat in januari 2028 op de markt is geplaatst, heeft normaal kwetsbaarheidsafhandeling nodig tot ten minste januari 2033, ook als een individuele klant het later koopt.
Kan de ondersteuningsperiode korter zijn dan vijf jaar?
Ja, maar alleen wanneer het product naar verwachting minder dan vijf jaar wordt gebruikt. De ondersteuningsperiode moet redelijke gebruikersverwachtingen, productaard en beoogd doel, relevante Uniewetgeving, vergelijkbare producten, beschikbaarheid van de operationele omgeving, ondersteuning van kerncomponenten van derden en ADCO- of Commissie-richtsnoeren weerspiegelen. De gebruikte informatie hoort in de technische documentatie, en de einddatum moet bij aankoop duidelijk zijn.
Geldt melden na afloop van de ondersteuningsperiode?
Behandel afloop van ondersteuning niet als algemene safe harbour voor meldingen. De ondersteuningsperioderegel definieert het venster voor kwetsbaarheidsafhandeling, terwijl de meldplicht afzonderlijk vereist dat actief misbruikte kwetsbaarheden en ernstige incidenten waarvan de fabrikant kennis krijgt, worden gemeld. Documenteer bij een niet-ondersteund product de juridische beoordeling voordat u besluit niet te melden, en overweeg toch gebruikersbericht wanneer het risico materieel is.
Wat als een upstream-componentleverancier vroeg stopt met ondersteuning?
De fabrikant blijft eigenaar van de verplichting voor de ondersteuningsperiode. De ondersteuningsperiode-regel dekt kwetsbaarheden in het product en de componenten, en de regel over due diligence bij componenten vraagt zorgvuldigheid bij integratie van componenten van derden. Als een chipset-, besturingssysteem-, middleware- of bibliotheekleverancier vroeg stopt, heeft de fabrikant een andere route nodig: patches onderhouden, het component vervangen of de getroffen configuratie niet langer op de EU-markt plaatsen.