Moet ik vastleggen hoe lang een apparaat software-updates krijgt?

Software-ondersteuning is nog geen vaste verplichting

Een verplichte termijn voor software-updates staat nog niet vast. De ESPR-kaderverordening (Verordening (EU) 2024/1781) biedt wél de wettelijke basis om dit per productcategorie verplicht te stellen, maar de daadwerkelijke eis — hoe lang een fabrikant updates moet blijven leveren, en of die termijn in het digitale productpaspoort moet staan — wordt pas vastgelegd in een gedelegeerde handeling voor de specifieke productgroep. Voor elektronica en ICT-apparatuur is die handeling er nog niet. Tot die er is, bestaat er geen algemene, afdwingbare plicht om een update-termijn vast te leggen in het paspoort, ook al is software-obsolescentie inhoudelijk precies het soort duurzaamheidsthema waar de ESPR op is gericht.

Relevant voor producten met software, niet voor alles

Dit onderwerp speelt bij apparaten waarvan de functionaliteit afhankelijk is van software: witgoed met slimme functies, ICT-apparatuur, en bredere elektronica met firmware of besturingssoftware. Voor puur mechanische producten zonder software is de vraag simpelweg niet aan de orde. Ook binnen de elektronicasector geldt: de ESPR werkt met gedelegeerde handelingen per deelcategorie, dus een eis die voor smartphones gaat gelden, geldt niet automatisch voor een wasmachine of een router. De kaderverordening zelf (artikelen 5 tot en met 7) somt het type vereisten op dat gesteld kán worden — waaronder duurzaamheid, betrouwbaarheid en geschiktheid voor reparatie en upgrade — maar vertaalt dat nog niet naar een concreet aantal jaren voor een concreet product. Wie nu op zoek is naar een harde termijn voor een specifiek apparaat, zal die dus nergens in de huidige tekst van de ESPR vinden.

Nog geen datum: gedelegeerde handelingen per categorie

Er is geen vaste datum waarop dit voor elektronica en ICT gaat gelden. Volgens het ESPR-werkplan 2025-2030 worden gedelegeerde handelingen per deelcategorie uitgewerkt, met een verwachting dat de eerste daarvan vanaf 2027 verschijnen. Dat is een indicatie uit het werkplan, geen toezegging en geen wet. Tot een gedelegeerde handeling voor een specifieke productgroep is gepubliceerd, gelden voor die groep de algemene bepalingen van de ESPR (artikelen 5 tot en met 7 voor de inhoudelijke eisen, artikel 10 voor wat in het digitale productpaspoort moet komen) zonder dat daar al een concrete update-termijn uit voortvloeit. Zodra een gedelegeerde handeling voor elektronica of ICT wordt gepubliceerd, staat hier de datum en de inhoud van die eis.

Wat dit betekent: volgorde van aanpak

Wie zich hierop wil voorbereiden, kijkt eerst naar de eigen productcategorie in het ESPR-werkplan en volgt van daaruit de publicatie van de bijbehorende gedelegeerde handeling — dat is het moment waarop duidelijk wordt of, en voor hoe lang, een update-termijn verplicht wordt en of die in het digitale productpaspoort moet worden opgenomen. Tot die publicatie is er geen wettelijke plicht om deze informatie in een paspoort te zetten, maar niets houdt een fabrikant tegen om intern nu al bij te houden hoe lang software-ondersteuning per productlijn wordt toegezegd — dat is dan een eigen, vrijwillige toezegging, geen ESPR-verplichting. Voor wie een digitaal productpaspoort laat samenstellen, betekent dit concreet: de huidige paspoortstructuur hoeft dit veld nog niet te bevatten, maar zodra de gedelegeerde handeling voor de betreffende deelcategorie dat wel voorschrijft, wordt dat veld aan het paspoort toegevoegd en gevuld met de gegevens die de fabrikant of importeur op dat moment aanlevert. Wie nu al gegevens over software-ondersteuning bijhoudt — welke modellen, welke termijnen, welke updatebeleidslijnen — heeft daarmee een voorsprong op het moment dat de eis concreet wordt, omdat die gegevens dan al beschikbaar zijn om in het paspoort te verwerken.

De basis: artikelen 5 tot en met 7 en artikel 10

De mogelijkheid om eisen te stellen aan software-ondersteuning volgt uit de artikelen 5 tot en met 7 van de ESPR (Verordening (EU) 2024/1781), die het kader vormen voor ecologisch ontwerp: prestatie-eisen zoals duurzaamheid, betrouwbaarheid en geschiktheid voor upgrade, en informatie-eisen daarover. Deze artikelen benoemen de categorieën van eisen die via gedelegeerde handelingen per productgroep verder ingevuld kunnen worden, maar leggen zelf geen concrete update-termijn vast. Artikel 10 van dezelfde verordening regelt wat in het digitale productpaspoort moet worden opgenomen; ook hier geldt dat de precieze gegevensvelden per productcategorie worden bepaald, aan de hand van de eisen die voor die categorie zijn vastgesteld. Zolang er voor elektronica en ICT geen gedelegeerde handeling is gepubliceerd die software-ondersteuning specifiek benoemt, blijft dit onderwerp binnen de kaderverordening een mogelijkheid, geen concrete verplichting.

Wie nu al met deze vraag bezig is, kan het beste de publicatie van de gedelegeerde handeling voor de eigen productcategorie in de gaten houden en in de tussentijd de eigen gegevens over software-ondersteuning op orde brengen, zodat die klaarstaan zodra het paspoort daarom vraagt.

Waar dit op gebaseerd is

De verordening zelf staat op EUR-Lex. Wij verwijzen per bewering; u hoeft ons niet te geloven.

Wat u concreet moet doen

Wat er van u wordt verwacht

Software-ondersteuning kan een ecologisch-ontwerpvereiste worden

De ESPR maakt het mogelijk om in gedelegeerde handelingen vereisten op te nemen over de duurzaamheid van een product, en daarbinnen ook over software: hoe lang een apparaat functionele en beveiligingsupdates krijgt, en wat er gebeurt met de functionaliteit van het apparaat zodra die ondersteuning stopt. Artikel 5 tot en met 7 van de ESPR (Verordening (EU) 2024/1781) noemt dit als onderdeel van de prestatie- en informatievereisten die per productgroep kunnen worden vastgesteld. Voor elektronica en ICT-apparatuur is dit een van de onderwerpen die relevant worden geacht, gezien de rol van software bij de levensduur van een apparaat — een wasmachine of laptop die technisch nog werkt, maar geen updates meer krijgt, wordt in de praktijk vaak toch vervangen. Voor een bedrijf van 10 tot 100 medewerkers betekent dit dat de afdeling die verantwoordelijk is voor productinformatie (vaak dezelfde die nu al garantietermijnen en gebruikershandleidingen samenstelt) een nieuw gegeven moet gaan bijhouden: de periode waarin updates worden geleverd, per productmodel of per softwareversie.

De informatie moet terug te vinden zijn in het productpaspoort

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) beschrijft welke informatie in het digitaal productpaspoort moet worden opgenomen zodra een gedelegeerde handeling dat voor een productgroep vastlegt. Zodra software-ondersteuningsduur als vereiste geldt voor elektronica, komt die informatie dus niet alleen in een handleiding of op een website terecht, maar ook in het paspoort zelf — gestructureerd, en gekoppeld aan de QR-datadrager op het product. Voor een middelgroot bedrijf betekent dit dat de update-periode niet los kan worden vastgesteld door de software-afdeling en los worden gecommuniceerd door marketing: die informatie moet uiteindelijk in dezelfde dataset staan als bijvoorbeeld het energieverbruik en de repareerbaarheidsscore. Wat er precies in het paspoort moet, verschilt per productgroep; op welke gegevens komen er in het productpaspoort van elektronica? staat een overzicht van de categorieën gegevens die daarin terugkomen.

De opgegeven periode moet kloppen met de werkelijkheid

Een ondersteuningsduur vastleggen is één stap; die ook waarmaken is een andere. Als een fabrikant een periode van updates toezegt in het paspoort, ligt de verwachting dat die periode ook daadwerkelijk wordt gehaald — en dat wijzigingen (een eerder gestopte update-cyclus, een overname waarbij een softwareteam wordt afgebouwd) worden verwerkt. Dit raakt aan de vraag hoe vaak paspoortgegevens actueel moeten blijven; zie hoe actueel moeten de gegevens zijn? voor wat daarover bekend is. Voor een bedrijf van deze omvang betekent dit vaak dat de toezegging over update-duur niet alleen door de productmanager wordt gedaan, maar wordt afgestemd met de partij die de software daadwerkelijk onderhoudt — intern team of externe leverancier.

Waar het misgaat in de praktijk

Een eerste situatie: een fabrikant noemt een update-periode in marketingmateriaal ("vijf jaar beveiligingsupdates"), maar deze toezegging staat nergens vast in een intern document met een startdatum en einddatum. Zodra die informatie in het paspoort moet, is er geen eenduidige bron om uit te putten.

Een tweede situatie: de software van een apparaat wordt geleverd door een toeleverancier (een chipfabrikant, een platformleverancier), en de importeur die het productpaspoort samenstelt weet niet hoe lang die toeleverancier ondersteuning garandeert. De verantwoordelijkheid voor de juistheid van paspoortgegevens ligt bij de partij die het paspoort laat opstellen, ook als de onderliggende informatie van een derde komt.

Een derde situatie: een apparaat wordt in meerdere uitvoeringen verkocht (verschillende chipsets, verschillende softwareversies per marktregio), maar de update-periode wordt voor het hele modelnummer als één cijfer opgegeven. Bij een latere controle blijkt dat sommige uitvoeringen korter worden ondersteund dan andere.

Een vierde situatie: een reeds verkocht apparaat krijgt door een strategiewijziging eerder dan gepland geen updates meer, zonder dat deze wijziging wordt terugkoppeld naar wie het paspoort beheert. De paspoortgegevens blijven de oorspronkelijke, te optimistische periode tonen.

Een vijfde situatie: een bedrijf gaat ervan uit dat "software-ondersteuning" alleen beveiligingsupdates betreft, terwijl functionele updates (nieuwe features, compatibiliteit met nieuwe accessoires) apart worden behandeld — en de communicatie hierover naar de klant wordt inconsistent, zonder dat helder is welke van de twee in het paspoort thuishoort.

Wat u kunt vastleggen

Een intern document per productmodel met de toegezegde periode van functionele updates en van beveiligingsupdates, elk met een duidelijke startdatum (bijvoorbeeld marktintroductie) en, indien bekend, einddatum.
Afspraken met softwareleveranciers of toeleveranciers over de minimale ondersteuningsduur die zij garanderen, inclusief wat er gebeurt bij een overname, faillissement of stopzetting van een platform.
Een overzicht van welke functionaliteit van het apparaat afhankelijk is van software-updates, en wat er gebeurt met die functionaliteit zodra de ondersteuning stopt (bijvoorbeeld: het apparaat blijft basisfuncties uitvoeren, maar verliest verbinding met een app).
Een proces om wijzigingen in de update-planning (vervroegd stoppen, verlengen) door te geven aan de afdeling die het productpaspoort beheert, zodat de gegevens niet achterlopen op de werkelijkheid.
Onderscheid per uitvoering of variant van een productmodel, als de software-ondersteuning per chipset of marktregio verschilt.
Vastlegging van de bron van de informatie: is de opgegeven periode een eigen toezegging, of een doorgegeven garantie van een toeleverancier? Dit is relevant zodra iemand vraagt waar een gegeven in het paspoort op is gebaseerd — zie ook ik heb een fout ontdekt in het productpaspoort, wat nu? voor hoe met onjuiste of verouderde gegevens kan worden omgegaan.

Zodra de gedelegeerde handeling voor elektronica en ICT is gepubliceerd, wordt hier concreet welke gegevens exact verplicht worden en in welke vorm. Tot die tijd is het opbouwen van een eigen, controleerbaar dossier over update-periodes een manier om niet achteraf te moeten reconstrueren wat er ooit is toegezegd.

Dit is geen juridisch advies. Deze pagina geeft algemene informatie over de regelgeving waar dit platform over gaat. Wij kennen uw situatie niet. Bij twijfel over uw eigen geval raadpleegt u een jurist of de bevoegde toezichthouder.

Geschreven met AI op basis van de bronnen hierboven, gecontroleerd door een mens op 2026-08-22. Klopt er iets niet? Laat het weten — correcties krijgen voorrang.