Hoe lang moet een productpaspoort beschikbaar blijven?

De bewaartermijn wordt per productgroep vastgesteld

Hoe lang een digitaal productpaspoort beschikbaar moet blijven, staat niet als één vast getal in de ESPR zelf. Artikel 10 van de ESPR (Verordening (EU) 2024/1781) bepaalt dat de periode waarin de gegevens van een productpaspoort toegankelijk moeten blijven, wordt vastgelegd in de gedelegeerde handeling voor de betreffende productgroep, en dat daarbij rekening wordt gehouden met de verwachte levensduur van het product. Er is dus geen algemene EU-brede termijn die voor alle producten hetzelfde is: een wasmachine met een lange gebruiksduur kan een andere bewaartermijn krijgen dan een smartphone of een oplader. Voor elektronica en ICT-apparatuur bestaat die gedelegeerde handeling nog niet, dus ligt de exacte termijn voor deze categorie nu nog niet vast.

Voor welk onderdeel dit geldt, en voor welk niet

Dit gaat over de toegankelijkheid van de gegevens die via de QR-code of vergelijkbare drager van het productpaspoort worden ontsloten — dus het paspoort zoals de koper, reparateur of toezichthouder het via het product zelf kan raadplegen. Het gaat niet over het EU-register van productpaspoorten uit artikel 13 van de ESPR: dat register houdt een eigen dataset bij en heeft een eigen functie, namelijk het bewaren van een basisset gegevens zodat paspoorten vindbaar en controleerbaar blijven, ook los van de fabrikant die ze oorspronkelijk heeft aangeleverd. De bewaartermijn van het paspoort zelf en de werking van dat register zijn dus twee verschillende dingen, die allebei in de ESPR staan maar met een ander doel. Ook andere bewaarplichten — zoals dossiers onder de WEEE-richtlijn, garantietermijnen, of documentatie voor CE-markering — vallen hier niet onder; die volgen uit andere regels en staan los van artikel 10.

De datum staat nog niet vast: dit is wel bekend

Er is op dit moment geen concrete termijn te noemen voor elektronica en ICT-apparatuur, simpelweg omdat de gedelegeerde handeling voor die categorie nog niet is gepubliceerd. Volgens het werkplan van de Commissie voor 2025-2030 worden gedelegeerde handelingen per deelcategorie uitgewerkt, met een verwachting dat de eerste daarvan vanaf 2027 verschijnen. Zolang zo'n handeling er niet is, bestaat er voor deze productgroep ook nog geen wettelijke verplichting om al een digitaal productpaspoort te voeren, en dus ook geen vastgestelde bewaartermijn om aan te voldoen. Zodra de handeling voor een specifieke elektronica- of ICT-categorie is gepubliceerd, staat daarin naar verwachting ook de duur waarvoor de gegevens toegankelijk moeten blijven.

Wat dit betekent voor de aanpak

Voor een importeur of fabrikant die zich hierop voorbereidt, is de eerste stap het volgen van de publicatie van de gedelegeerde handeling voor de eigen productcategorie — pas daarin staat de daadwerkelijke termijn. De tweede stap is rekening houden met het uitgangspunt uit artikel 10, namelijk dat de termijn is gekoppeld aan de verwachte levensduur van het product: voor witgoed ligt een langere bewaarperiode voor de hand dan voor kortlevende consumentenelektronica, al is dat nog geen vaststaand gegeven zolang de handeling er niet is. De derde stap is bij de keuze van een hostingpartij letten op flexibiliteit: een partij die het paspoort hoster moet in staat zijn de bewaartermijn aan te passen zodra de gedelegeerde handeling verschijnt, in plaats van vooraf een termijn vast te leggen die achteraf te kort blijkt. De vierde stap is niet vooruitlopen op een specifiek aantal jaren als vaststaand feit — een genoemde termijn van bijvoorbeeld tien jaar is op dit moment een verwachting op basis van vergelijkbare regelgeving, geen bevestigde wettelijke eis voor elektronica en ICT. Wie nu al gegevens verzamelt en structureert ten behoeve van een toekomstig paspoort, doet er goed aan dat op een manier te doen die met een nog te bepalen bewaartermijn kan meebewegen, in plaats van gegevens en opslag aan een vaste periode te binden.

Vindplaats: artikel 10 en artikel 13 ESPR

De basis hiervoor ligt in artikel 10 van de ESPR (Verordening (EU) 2024/1781), waarin de eisen aan het digitale productpaspoort staan, waaronder de bepaling dat de toegankelijkheidsduur per productgroep in een gedelegeerde handeling wordt vastgesteld met het oog op de verwachte levensduur van het product. Artikel 13 van dezelfde verordening regelt het EU-register van digitale productpaspoorten, dat een aanvullende, eigen rol heeft naast de bewaarplicht van het paspoort zelf.

Wie nu al een paspoort-strategie voor elektronica of ICT-apparatuur voorbereidt, kan het beste de publicatie van de gedelegeerde handeling voor de eigen productcategorie in de gaten houden en de eigen data-opslag zo inrichten dat een nog vast te stellen bewaartermijn zonder gedoe kan worden doorgevoerd zodra die bekend is.

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

Beschikbaarheid gedurende de levensduur van het product

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) regelt de eisen aan het digitale productpaspoort, waaronder de gedachte dat de informatie beschikbaar blijft zolang daar een redelijke aanleiding voor is — denk aan de periode dat een product nog in gebruik, in de handel of relevant voor reparatie en recycling is. Voor een deelcategorie als elektronica en ICT-apparatuur wordt de precieze duur pas vastgelegd in de gedelegeerde handeling voor die productgroep. Tot die handeling is gepubliceerd, is er geen vast aantal jaren te noemen. Voor een bedrijf van 10 tot 100 medewerkers betekent dit praktisch dat de keuze voor een hostingpartij of eigen systeem niet lichtzinnig gemaakt kan worden: de gegevens moeten net zo lang bereikbaar blijven als straks in de toepasselijke gedelegeerde handeling wordt vastgelegd, en dat kan een periode zijn die veel langer is dan een gangbaar IT-contract of hostingabonnement.

Toegankelijkheid, niet alleen opslag

Beschikbaar blijven is meer dan een bestand ergens laten staan. De informatie moet ook daadwerkelijk oproepbaar zijn via de identificatiedrager op het product, meestal een QR-code. Dat raakt aan de vraag hoe komt de QR-code voor het productpaspoort op mijn elektronica, want een paspoort dat wel bestaat maar niet meer opgeroepen kan worden omdat de koppeling met de drager is verbroken, voldoet feitelijk niet aan het doel van artikel 10. Voor een middelgroot bedrijf betekent dit dat de technische keten — van QR-code tot server — als één geheel moet blijven werken, niet als los van elkaar staande onderdelen die ieder voor zich "goed genoeg" zijn.

Registratie in het Europese register

Artikel 13 van de ESPR verplicht tot opname van het paspoort in een centraal register. Die registratie staat niet op zichzelf: als het paspoort verandert van locatie, van hostingpartij, of stopt te bestaan, is de vraag wat daarmee in het register gebeurt. Meer over wat daar precies in moet staan en hoe dat samenhangt met de levensduur van het paspoort, is te lezen op de pagina over wat het register van digitale productpaspoorten is en wat daarin moet. Voor bedrijven met meerdere productlijnen is dit een terugkerend aandachtspunt: elke wijziging aan een paspoort kan gevolgen hebben voor wat in het register staat.

Voortbestaan onafhankelijk van de bedrijfssituatie

De verplichting om het paspoort beschikbaar te houden is niet gekoppeld aan het voortbestaan van het bedrijf dat het paspoort heeft laten opstellen. Dat roept in de praktijk de vraag op wat er gebeurt bij een fusie, overname, faillissement of simpelweg stoppen met een bepaalde productlijn. Voor een onderneming die op termijn wil verkopen, herstructureren of afbouwen, is dit een reëel scenario om vooraf te doordenken — zie ook wat er gebeurt met het productpaspoort als een bedrijf stopt. De verplichting verdwijnt niet automatisch mee met de onderneming die ooit het paspoort liet maken.

Waar het misgaat in de praktijk

Een hostingcontract wordt afgesloten voor een periode die aansluit bij het gangbare IT-budgetritme — bijvoorbeeld een paar jaar — zonder dat is nagedacht over verlenging. Als de looptijd van het paspoort straks in de gedelegeerde handeling langer blijkt te zijn dan het contract, ontstaat een gat waarin de QR-code naar een dode pagina verwijst.

Een bedrijf verhuist naar een nieuw ERP-systeem en neemt de koppeling met het productpaspoort niet mee in het migratieplan. De onderliggende productdata veranderen van locatie, maar de identificatiedrager op het product blijft naar het oude adres verwijzen. Wie zich hierop wil voorbereiden, kan de vraag of het paspoort te koppelen is aan het eigen systeem beter vroeg beantwoorden, zie koppelen aan het eigen ERP- of voorraadsysteem.

Een productlijn wordt na een paar jaar uitgefaseerd en de website of dataserver die de paspoorten hostte, wordt afgebouwd omdat er "toch geen omzet meer op zit". De producten die al bij consumenten of bedrijven in gebruik zijn, blijven echter een werkende QR-code nodig hebben, ongeacht of het product nog verkocht wordt.

Bij een overname wordt de productcatalogus overgenomen, maar niemand regelt wie verantwoordelijk wordt voor de bestaande paspoorten en de bijbehorende hosting. De nieuwe eigenaar ontdekt pas later dat er nog een verplichting doorloopt op producten die al jaren geleden zijn verkocht.

Een fabrikant laat de QR-code drukken op een sticker die niet bestand is tegen de gebruiksomstandigheden van het apparaat. Na verloop van tijd is de code onleesbaar, waardoor de achterliggende data — hoe lang ook beschikbaar gehouden — niet meer oproepbaar is. Meer hierover staat bij wat te doen als de QR-code beschadigd of onleesbaar raakt.

Wat u kunt vastleggen

Een overzicht per productlijn van welke hostingpartij welke paspoortdata beheert, met contractduur en verlengingsafspraken.
Een intern document waarin is vastgelegd wie verantwoordelijk is voor het paspoort bij een reorganisatie, verkoop van een productlijn of bedrijfsoverdracht.
Een technische beschrijving van de koppeling tussen QR-code, database en eventueel ERP-systeem, zodat bij personeelswisseling deze kennis niet verdwijnt.
Een migratieprotocol voor het geval van systeemwissel, zodat de identificatiedrager op het product altijd naar een werkende locatie blijft verwijzen.
Een aantekening bij elk product over welke unieke identificatiecode gebruikt is, relevant bij het bijhouden van welke paspoorten waar horen — zie ook de toelichting over hoe elk product een unieke identificatiecode krijgt.
Een kopie van de registergegevens zoals opgenomen bij aanmelding, zodat wijzigingen later herleidbaar zijn.

Voor de meeste van deze punten zijn sjablonen beschikbaar die als uitgangspunt kunnen dienen bij het opzetten van een eigen dossier, aan te passen aan de eigen bedrijfsvoering en productportfolio.

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.