EU-Kommissionen sender udkast til forordning om centralt DPP-register i høring

Baggrund: Hvorfor et centralt register for digitale produktpas?

Det digitale produktpas (DPP) er hjørnestenen i den europæiske forordning om miljøvenligt design af bæredygtige produkter (ESPR), som har været i kraft siden juli 2024. Den forpligter producenterne til at stille maskinlæsbare dataregistreringer til rådighed for et voksende antal produktkategorier — fra batterier og tekstiler til elektronik. Men hvor lever henvisningerne til disse registreringer egentlig? Det er netop det, den nye gennemførelsesforordning tager fat på.

Den 29. april 2026 offentliggjorde Europa-Kommissionen et udkast til gennemførelsesforordning om DPP-registret, som nu er sendt i offentlig høring. Dokumentet beskriver, hvordan et centraliseret register skal lagre entydige produktidentifikatorer og knytte dem til produktdata, der hostes decentralt. Dette er ikke en database over selve produktdataene — det er en fortegnelse over henvisninger.

Dette arkitektoniske valg er bevidst: EU ønsker ikke at skabe et monolitisk datasilo, men derimod et interoperabelt netværk af producentsystemer, der kan opdages gennem en fælles central knude.

Hvad udkastet rent faktisk kræver

Struktur: Centralt register, decentrale data

Udkastets kerneprincip er klart: Registret lagrer kun entydige identifikatorer (UID'er) og de tilhørende resolver-endpoints — altså de URL'er, hvor de egentlige DPP-data kan hentes. Selve produktdataene forbliver hos producenten eller en udpeget dataoperatør.

Denne model er konceptuelt tæt på linje med GS1 Digital Link, den åbne standard, der forbinder GTIN'er med strukturerede web-URI'er. En scanner eller en markedsovervågningsmyndighed kan bruge den centrale registerpost til at finde frem til den ansvarlige resolver og derfra hente de fuldstændige pasdata.

Registreringsforpligtelser for erhvervsdrivende

Udkastet fastslår, at producenter og importører er forpligtet til at registrere deres produkter i registret, inden de bringes i omsætning. Konkret skal de:

indsende den entydige produktidentifikator (UID),
angive det resolver-endpoint (URL), hvor DPP'en kan tilgås,
levere metadata om produktkategorien og den ansvarlige erhvervsdrivende.

Registreringen skal foretages via en standardiseret API, hvis tekniske specifikation stadig er under udvikling af ECLASS og andre standardiseringsorganer. Udkastet henviser til det igangværende arbejde i CEN/CENELEC JTC 24, som har til opgave at harmonisere datamodellerne.

Adgangsrettigheder og databeskyttelse

Et af de centrale stridspunkter i høringen bliver sandsynligvis spørgsmålet om, hvem der må tilgå hvilke registerdata. Udkastet skelner mellem tre klasser af aktører:

Aktør	Læseadgang	Skriveadgang	Bemærkninger
Offentligheden / forbrugere	Resolver-URL, produktkategori	Nej	Ingen kommercielt følsomme forretningsdata
Markedsovervågningsmyndigheder	Hele posten inkl. metadata	Nej	Ensartet på tværs af EU
Erhvervsdrivende (producenter, importører)	Egne poster	Ja	Autentificering via EU Login

Kommercielt følsomme oplysninger — såsom leverandørrelationer eller indkøbspriser — må udtrykkeligt ikke lagres i registret. Til det henviser udkastet til muligheden for at definere adgangsniveauer (Access Rights) i selve DPP'en, som det allerede er fastsat i den delegerede ESPR-forordning for batterier.

Tekniske konsekvenser for producenter og it-tjenesteudbydere

API-integration og masseregistrering

For virksomheder med store produktporteføljer er spørgsmålet om masseregistrering afgørende. Udkastet skitserer en REST API, hvorigennem UID'er kan indsendes i batches. Et forenklet eksempel på, hvordan et sådant registreringskald kan være struktureret:

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"
  }
}

Selve UID'en skal overholde et anerkendt identifikationssystem — udkastet nævner udtrykkeligt GS1 GTIN'er såvel som ISO/IEC 15459-kompatible koder. Proprietære systemer er tilladt, men skal være globalt entydige og permanent opløselige.

For virksomheder, der allerede arbejder med værktøjer som qr3.app Bulk Import, ændrer det underliggende princip sig ikke væsentligt: en struktureret CSV- eller JSON-levering af UID'er og resolver-URL'er kan mappes til registrets API. Den reelle udfordring ligger i governance — hvem i organisationen er ansvarlig for at vedligeholde posterne, når resolver-URL'er ændrer sig, eller produkter trækkes tilbage fra markedet?

Lifecycle-håndtering: Tilbagekaldelser og arkivering

Udkastet behandler også produktets livscyklus efter markedsføring. Producenterne er forpligtet til at opdatere registerposter, når:

resolver-endpointet ændrer sig,
produktet tilbagekaldes (posten skal da markeres som "recalled", men ikke slettes),
virksomheden opløses eller overdrages.

Arkiveringsforpligtelsen er fastsat til mindst 10 år efter det sidste tidspunkt, produktet blev bragt i omsætning — et krav, der udgør en særlig udfordring for SMV'er uden egen it-infrastruktur.

Tidsplan og næste skridt

Den offentlige høring om udkastet forventes at løbe til udgangen af juni 2026. Bemærkninger kan indsendes via EU's "Have Your Say"-portal. Kommissionen har signaleret, at den agter at vedtage den endelige gennemførelsesforordning inden udgangen af 2026 for at flugte med de første produktspecifikke delegerede ESPR-forordninger — mest markant for tekstiler (planlagt til 2027).

For batteriforordningen, der har været bindende siden februar 2024, gælder en særlig ordning: batteripas-systemet kører i første omgang gennem en separat mekanisme, men er på mellemlang sigt tænkt integreret i det centrale register.

Hvad virksomheder bør gøre nu

Selv om forordningen endnu ikke er endelig, er der forberedende skridt, du kan tage allerede i dag:

Definér din UID-strategi: Beslut, om du vil basere dig på GS1 GTIN'er eller et alternativt system. GS1 Digital Link har den fordel, at identifikatoren samtidig fungerer som en opløselig web-URI.
Opbyg din resolver-infrastruktur: Resolver-endpointet skal være permanent tilgængeligt og versioneret. Brug stabile base-URL'er — ikke dynamiske korte URL'er.
Definér processer for datavedligeholdelse: Hvem i din organisation er ansvarlig for registeropdateringer, når produkter ændres eller tilbagekaldes?
Følg høringen: Den endelige forordning kan afvige fra udkastet — særligt med hensyn til API-specifikationer og adgangsrettigheder.

Vurdering: Hvad registret gør — og hvad det ikke gør

Det centrale DPP-register er hverken et kvalitetscertifikat eller en overensstemmelsesvurdering. Det er en fortegnelsestjeneste — sammenlignelig med en DNS for produktidentifikatorer. Korrektheden af DPP-dataene forbliver de erhvervsdrivendes ansvar og verificeres af markedsovervågningsmyndighederne.

Kritikere fra industrien — herunder BusinessEurope — har allerede bemærket, at den todelte struktur med et centralt register og decentral datalagring øger compliance-omkostningerne uden at forbedre databeskyttelsen meningsfuldt. Fortalere, herunder miljøorganisationer som European Environmental Bureau, argumenterer til gengæld for, at kun et centralt indgangspunkt kan sikre myndighedernes håndhævelse.

Høringsfasen vil afsløre, om Kommissionen holder fast i den hybride arkitektur eller foretager justeringer. For virksomheder, der begynder deres tekniske forberedelser nu, er den vigtigste konklusion denne: de grundlæggende principper — entydige identifikatorer, stabile resolvere, struktureret metadata — vil forblive gyldige uanset den endelige lovtekst.