EU-Commissie raadpleegt over ontwerpverordening voor centraal DPP-register

Achtergrond: waarom een centraal register voor Digitale Productpaspoorten?

Het Digitaal Productpaspoort (DPP) is de hoeksteen van de Europese Ecodesignverordening voor duurzame producten (ESPR), die sinds juli 2024 van kracht is. Zij verplicht fabrikanten om machineleesbare datarecords aan te leveren voor een groeiend aantal productcategorieën — van batterijen en textiel tot elektronica. Maar waar staan de verwijzingen naar die records eigenlijk? Precies dat is waar de nieuwe uitvoeringsverordening op ingaat.

Op 29 april 2026 publiceerde de Europese Commissie een ontwerp-uitvoeringsverordening over het DPP-register, die nu openstaat voor publieke raadpleging. Het document beschrijft hoe een gecentraliseerd register unieke productidentificatoren opslaat en ze koppelt aan productgegevens die op decentrale wijze worden gehost. Dit is geen database van de productgegevens zelf — het is een register van verwijzingen.

Deze architecturale keuze is weloverwogen: de EU wil geen monolithisch datasilo creëren, maar veeleer een interoperabel netwerk van fabrikantsystemen dat via een gedeeld centraal knooppunt vindbaar is.

Wat het ontwerp daadwerkelijk vereist

Structuur: centraal register, decentrale gegevens

Het kernprincipe van het ontwerp is helder: het register slaat uitsluitend unieke identificatoren (UID's) en de bijbehorende resolver-endpoints op — dat wil zeggen de URL's waar de daadwerkelijke DPP-gegevens kunnen worden opgehaald. De productgegevens zelf blijven bij de fabrikant of een aangewezen data-exploitant.

Dit model sluit conceptueel nauw aan bij GS1 Digital Link, de open standaard die GTIN's verbindt met gestructureerde web-URI's. Een scanner of een markttoezichtautoriteit kan de centrale registervermelding gebruiken om de verantwoordelijke resolver te lokaliseren en daar de volledige paspoortgegevens op te halen.

Registratieverplichtingen voor marktdeelnemers

Het ontwerp bepaalt dat fabrikanten en importeurs verplicht zijn hun producten in het register te registreren voordat zij ze op de markt brengen. Concreet moeten zij:

de unieke productidentificator (UID) indienen,
het resolver-endpoint (URL) opgeven waar het DPP toegankelijk is,
metadata over de productcategorie en de verantwoordelijke marktdeelnemer aanleveren.

De registratie verloopt via een gestandaardiseerde API, waarvan de technische specificatie nog wordt ontwikkeld door ECLASS en andere normalisatie-instellingen. Het ontwerp verwijst naar de lopende werkzaamheden van CEN/CENELEC JTC 24, dat als taak heeft de datamodellen te harmoniseren.

Toegangsrechten en gegevensbescherming

Een van de centrale twistpunten in de raadpleging wordt waarschijnlijk de vraag wie welke registergegevens mag inzien. Het ontwerp onderscheidt drie soorten actoren:

Actor	Leestoegang	Schrijftoegang	Opmerkingen
Publiek / consumenten	Resolver-URL, productcategorie	Nee	Geen commercieel gevoelige handelsgegevens
Markttoezichtautoriteiten	Volledige vermelding inclusief metadata	Nee	Uniform binnen de hele EU
Marktdeelnemers (fabrikanten, importeurs)	Eigen vermeldingen	Ja	Authenticatie via EU Login

Commercieel gevoelige informatie — zoals leveranciersrelaties of inkoopprijzen — mag uitdrukkelijk niet in het register worden opgeslagen. Daarvoor wijst het ontwerp op de mogelijkheid om toegangsniveaus (Access Rights) binnen het DPP zelf te definiëren, zoals reeds is voorzien in de ESPR-gedelegeerde verordening voor batterijen.

Technische implicaties voor fabrikanten en IT-dienstverleners

API-integratie en bulkregistratie

Voor bedrijven met omvangrijke productportefeuilles is de kwestie van bulkregistratie cruciaal. Het ontwerp schetst een REST-API waarmee UID's in batches kunnen worden ingediend. Een vereenvoudigd voorbeeld van hoe zo'n registratie-aanroep gestructureerd zou kunnen zijn:

POST /registry/v1/products
Content-Type: application/json
Authorization: Bearer <EU-Login-Token>

{
  "uid": "https://id.gs1.org/01/04012345678901/21/ABC123",
  "resolverEndpoint": "https://dpp.example.com/resolver",
  "productCategory": "ESPR:TextileUpperGarment",
  "economicOperator": {
    "eori": "DE123456789",
    "name": "Muster GmbH"
  }
}

De UID zelf moet voldoen aan een erkend identificatiesysteem — het ontwerp noemt uitdrukkelijk GS1 GTIN's evenals codes die voldoen aan ISO/IEC 15459. Eigen systemen zijn toegestaan, maar moeten wereldwijd uniek en permanent resolvbaar zijn.

Voor bedrijven die al werken met tools zoals qr3.app Bulk Import verandert het onderliggende principe niet wezenlijk: een gestructureerde CSV- of JSON-aanlevering van UID's en resolver-URL's kan worden afgebeeld op de register-API. De echte uitdaging schuilt in governance — wie binnen de organisatie is verantwoordelijk voor het onderhoud van vermeldingen wanneer resolver-URL's wijzigen of producten van de markt worden gehaald?

Levenscyclusbeheer: terugroepacties en archivering

Het ontwerp gaat ook in op de productlevenscyclus na het op de markt brengen. Fabrikanten zijn verplicht registervermeldingen bij te werken wanneer:

het resolver-endpoint wijzigt,
het product wordt teruggeroepen (de vermelding moet dan worden gemarkeerd als "recalled", maar niet worden verwijderd),
het bedrijf wordt ontbonden of overgedragen.

De archiveringsverplichting bedraagt ten minste 10 jaar nadat het product voor het laatst op de markt is gebracht — een eis die met name voor het mkb zonder eigen IT-infrastructuur een bijzondere uitdaging vormt.

Tijdlijn en volgende stappen

De publieke raadpleging over het ontwerp loopt naar verwachting tot eind juni 2026. Reacties kunnen worden ingediend via het EU Have Your Say-portaal. De Commissie heeft te kennen gegeven de definitieve uitvoeringsverordening nog vóór eind 2026 te willen vaststellen, om aansluiting te vinden bij de eerste productspecifieke ESPR-gedelegeerde verordeningen — met name voor textiel (gepland voor 2027).

Voor de Batterijenverordening, die sinds februari 2024 bindend is, geldt een bijzondere regeling: het systeem van het batterijpaspoort werkt aanvankelijk via een afzonderlijk mechanisme, maar zal op de middellange termijn in het centrale register worden geïntegreerd.

Wat bedrijven nu zouden moeten doen

Hoewel de verordening nog niet definitief is, zijn er voorbereidende stappen die u vandaag al kunt zetten:

Bepaal uw UID-strategie: Beslis of u vertrouwt op GS1 GTIN's of op een alternatief systeem. GS1 Digital Link heeft het voordeel dat de identificator tegelijkertijd fungeert als een resolvbare web-URI.
Bouw uw resolver-infrastructuur: Het resolver-endpoint moet permanent toegankelijk en geversioneerd zijn. Gebruik stabiele basis-URL's — geen dynamische korte URL's.
Leg processen voor gegevensonderhoud vast: Wie in uw organisatie is verantwoordelijk voor registerupdates wanneer producten wijzigen of worden teruggeroepen?
Volg de raadpleging op de voet: De definitieve verordening kan afwijken van het ontwerp — met name wat betreft API-specificaties en toegangsrechten.

Beoordeling: wat het register wel — en niet — doet

Het centrale DPP-register is geen kwaliteitscertificaat of conformiteitsbeoordeling. Het is een directoryservice — vergelijkbaar met een DNS voor productidentificatoren. De juistheid van de DPP-gegevens blijft de verantwoordelijkheid van de marktdeelnemers en wordt geverifieerd door markttoezichtautoriteiten.

Critici uit het bedrijfsleven — waaronder BusinessEurope — hebben er al op gewezen dat de duale structuur van een centraal register en decentrale gegevensopslag de nalevingskosten verhoogt zonder de gegevensbescherming wezenlijk te verbeteren. Voorstanders, waaronder milieuorganisaties zoals het European Environmental Bureau, betogen op hun beurt dat alleen een centraal toegangspunt de handhaafbaarheid door autoriteiten kan waarborgen.

De raadplegingsfase zal uitwijzen of de Commissie vasthoudt aan de hybride architectuur of aanpassingen doorvoert. Voor bedrijven die nu met hun technische voorbereidingen beginnen, is de belangrijkste conclusie deze: de grondbeginselen — unieke identificatoren, stabiele resolvers, gestructureerde metadata — blijven geldig, ongeacht de uiteindelijke regelgevingstekst.