Het normenkader staat — nu begint de uitvoering
Met de vaststelling van de ESPR-verordening (EU) 2024/1781 is het Digital Product Passport (DPP) bindend EU-recht. Wat lange tijd als een toekomstproject gold, heeft sinds het voorjaar van 2026 een beslissende nieuwe dimensie gekregen: de technische normen waarop de uitvoeringsverordeningen zullen steunen, liggen nu voor.
Begin juni 2026 presenteerde de DPP4EU-conferentie in Brussel het normenpakket dat onder CEN/CENELEC JTC 24 is ontwikkeld. De normenreeks EN 18216 tot en met EN 18223 definieert de technische kerninfrastructuur: gegevensdragers, unieke identificatoren, API's en het raamwerk voor interoperabiliteit. Tegelijkertijd werden open-sourcetestomgevingen gepresenteerd waarmee implementaties op conformiteit kunnen worden gecontroleerd. Het Fraunhofer IPK, dat bij de ontwikkeling van de normen betrokken was, merkte op: „The standards are here — now is the time to bring them to life."
Deze zin beschrijft de situatie treffend. De regelgevende architectuur staat vast; wat ontbreekt, zijn sectorspecifieke uitvoeringsverordeningen, een stabiele registrywerking en een breed gedragen implementatiepraktijk in de industrie.
Wat de normen EN 18216–18223 concreet regelen
Identificatoren en gegevensdragers
De normenreeks bepaalt dat iedere DPP over een unieke productidentificator moet beschikken die machineleesbaar en permanent resolveerbaar is. EN 18220 regelt de toegestane gegevensdragers — waaronder QR-codes, DataMatrix en RAIN-RFID. Belangrijk is dat de norm technologieneutraal is geformuleerd: hij schrijft geen specifieke drager voor, maar definieert minimumeisen voor leesbaarheid en persistentie.
De GS1 Digital Link is in deze context geen verplichting, maar feitelijk wel de dominante kandidaat voor de identifierstrategie — omdat deze bestaande GTIN-infrastructuur verbindt met web-URI-resolutie. Het CIRPASS-2-consortium adviseerde in zijn standpunt over het ontwerp expliciet om norm EN 18219 als referentie in de uitvoeringsverordening op te nemen, om interoperabiliteit met GS1 Digital Link en andere bestaande identificatiesystemen te waarborgen.
Registryarchitectuur: decentraal met een centrale index
Een veelvoorkomend misverstand betreft de geplande EU-DPP-registry. Deze zal geen productgegevens opslaan, maar uitsluitend unieke identificatoren en resolver-URL's — dus verwijzingen naar decentraal gehoste passportgegevens. De verantwoordelijkheid voor de gegevensopslag blijft bij de fabrikant of een aangewezen dienstverlener.
CIRPASS-2 bekritiseert in dit model vooral drie punten: de governancestructuur van de registry (wie beheert deze en onder welke voorwaarden?), de kwestie van datasoevereiniteit bij grensoverschrijdende toeleveringsketens en de nog onopgeloste interoperabiliteit met nationale systemen. Deze kritiek is terecht — de uitvoeringsverordening voor de registry bevindt zich op het moment van redactie nog in de ontwerpfase.
Het JRC-staalontwerp als blauwdruk voor andere sectoren
Waarom ijzer en staal richtinggevend zijn
Het Joint Research Centre van de Europese Commissie heeft een ontwerp voor het DPP van halffabricaten van ijzer en staal ingediend. Dit ontwerp is om meerdere redenen relevant buiten de staalindustrie: voor het eerst wordt systematisch het onderscheid geformaliseerd tussen gegevens op productniveau en gegevens op batchniveau — een onderscheid dat fundamenteel is voor databasearchitectuur en identifierstrategie.
Product- versus batchniveau: een structurele koerswijziging
Het JRC-ontwerp wijst gegevenspunten expliciet aan een van twee niveaus toe:
Batchniveau (lotnummer):
- Gerecycled materiaalgehalte
- Legeringssamenstelling
- Productspecifieke CO₂-voetafdruk (PCF)
Productniveau (serienummer):
- Afmetingen
- Certificeringen
- Conformiteitsverklaringen
De productspecifieke CO₂-voetafdruk wordt volgens het ontwerp vastgesteld op basis van berekeningsregels die compatibel zijn met de ISO-14067-standaard. Dat is belangrijk omdat hiermee een methodologische minimumeis wordt gedefinieerd — niet alleen een gegevensverplichting.
De batterijverordening (EU) 2023/1542 — tot nu toe de enige bindende sectorale regeling met eigen DPP-verplichtingen — kent dit onderscheid al impliciet. Het ontwerp voor de staalsector formaliseert het echter voor het eerst expliciet, wat als voorbeeld kan dienen voor alle volgende sectorale regelingen.
Voor bedrijven die vandaag hun DPP-databasearchitectuur plannen, heeft dit directe gevolgen: een vlak gegevensmodel waarin alle kenmerken op productniveau worden vastgelegd, zal niet aan de wettelijke eisen voldoen. Wie al met bulkimportworkflows werkt, moet nagaan of de importstructuur onderscheid maakt tussen lot- en serienummergegevens.
Verwante ontwikkelingen: REACH-microplastics en RFID-codering
ECHA-richtsnoeren voor synthetische polymeerdeeltjes
Parallel aan de DPP-ontwikkelingen heeft de ECHA in mei 2026 richtsnoeren gepubliceerd voor de REACH-meldingsplicht voor synthetische polymeermicrodeeltjes. De eerste meldingsdeadline voor fabrikanten en industriële downstreamgebruikers van polymeerpellets, -vlokken en -poeders is in mei 2026 van kracht geworden.
Deze stap is strikt genomen geen DPP-kwestie, maar illustreert de bredere regelgevende richting: de EU bouwt systematisch meldingsplichten op voor stofeigenschappen die op middellange termijn zullen doorwerken in DPP-gegevensvereisten. Bedrijven die vandaag REACH-gegevens verzamelen, leggen daarmee een basis voor latere DPP-kenmerken.
RAIN-RFID en GS1 Digital Link: coderingsstandaarden in de praktijk
Aan de implementatiekant heeft TEKLYNX zijn CODESOFT-software bijgewerkt en ondersteunt deze nu GS1-„++"-coderingsschema's (EPC++ en ISO BD). Daarmee kunnen web-URL's rechtstreeks in RAIN-RFID-taggeheugens worden geschreven — een vereiste die voortvloeit uit de combinatie van EN 18220 en de GS1 Digital Link-standaard.
Dit is een concreet voorbeeld van hoe de abstracte normeisen hun weg vinden naar productiesoftware. Voor bedrijven die RFID-gebaseerde processen in toeleveringsketens exploiteren, betekent dit: de identifierstrategie moet al bij het tag-encoderen beginnen, niet pas bij het instellen van de resolver.
Wat bedrijven nu moeten doen
De regelgevende situatie kan in drie actiegebieden worden opgedeeld:
1. Naleving van de normen controleren: De normen EN 18216–18223 zijn gepubliceerd. Wie vandaag DPP-systemen opbouwt, moet ervoor zorgen dat de gekozen gegevensdragers, identificatoren en API's compatibel zijn met deze normen. De open-sourcetestomgevingen die op de DPP4EU-conferentie zijn gepresenteerd, bieden daarvoor een eerste testmogelijkheid.
2. Het gegevensmodel naar niveaus structureren: Het JRC-staalontwerp laat zien welke richting het opgaat. Bedrijven moeten hun gegevensmodel zo opbouwen dat batch- en productgegevens netjes gescheiden en afzonderlijk adresseerbaar zijn. Dit betreft zowel de interne gegevensopslag als de API-interfaces naar het DPP-systeem.
3. De ontwikkeling van de registry volgen: De uitvoeringsverordening voor de centrale DPP-registry is nog niet definitief. De kritiekpunten van CIRPASS-2 — met name over governance en datasoevereiniteit — zijn inhoudelijk steekhoudend en kunnen het definitieve ontwerp nog beïnvloeden. Bedrijven moeten de registry niet als voltooide infrastructuur inplannen, maar als variabele in hun systeemarchitectuur behandelen.
De normen zijn er. De eerste sectorspecifieke ontwerpen liggen voor. Wat nu telt, is het opbouwen van implementatiecompetentie — voordat de deadlines van de uitvoeringsverordeningen het tempo bepalen.
