EN 18216 tot en met 18223: de zes CEN-normen die bepalen wat een conform digitaal productpaspoort is

Drie jaar lang liep elke discussie over het digitale productpaspoort (DPP) tegen dezelfde vraag aan: hoe ziet een conform DPP-systeem er eigenlijk uit? De ESPR (EU 2024/1781) is de juridische grondslag. CIRPASS-2 schetste de architectuur. GS1 Digital Link leverde de URL-syntaxis. Maar de eigenlijke normatieve technische normen — die waar een merk naar kan wijzen met de opdracht "bouw het volgens deze norm" — ontbraken.

Die leemte is nu gedicht. Het gemeenschappelijk technisch comité 24 van CEN/CENELEC (JTC 24) heeft zes normatieve Europese normen gepubliceerd over de technische architectuur van een digitaal productpaspoort. Samen bepalen ze hoe identificatiecodes werken, hoe gegevens worden gedragen, hoe de API zich gedraagt, hoe gegevens worden uitgewisseld en gearchiveerd, en hoe systemen samenwerken.

De zes gepubliceerde normen zijn:

  • EN 18216 — Protocollen voor gegevensuitwisseling
  • EN 18219 — Unieke identificatiecodes
  • EN 18220 — Gegevensdragers
  • EN 18221 — Gegevensopslag en persistentie
  • EN 18222 — API’s voor de levenscyclus en doorzoekbaarheid van productpaspoorten
  • EN 18223 — Systeeminteroperabiliteit

Nog twee — EN 18239 (toegangsrechten en beveiliging) en EN 18246 (authenticatie en integriteit van gegevens) — zijn nog in voorbereiding als prEN-ontwerpen en worden normatief aangehaald door 18221, 18222 en 18223. Ze worden als volgende verwacht. Update, oktober 2026: beide zijn op 17 augustus 2026 door CEN goedgekeurd en zijn nu gepubliceerd — zie alle acht DPP-normen zijn gepubliceerd, slechts zes zijn in het Publicatieblad bekendgemaakt.

Dit artikel loopt na wat elk van de zes gepubliceerde normen werkelijk vereist, waarom merken hun DPP-systemen nu al op deze normen zouden moeten afstemmen, en hoe de normen samenhangen met de tijdlijn van de gedelegeerde handelingen onder de ESPR voor textiel.

Waarom deze normen ertoe doen voor naleving van de ESPR

Artikel 9 van de ESPR vereist digitale productpaspoorten voor producten die in de EU in de handel worden gebracht binnen de productgroepen waarop gedelegeerde handelingen van toepassing zijn. De artikelen 10 en 11 sommen de essentiële vereisten op: paspoorten moeten verbonden zijn aan een permanente unieke identificatiecode en moeten machineleesbaar, toegankelijk, veilig en interoperabel zijn.

Die artikelen bepalen echter niet hoe op technisch niveau aan de vereisten wordt voldaan. Dat doen deze CEN-normen. Bijlage ZA van elke norm koppelt de punten van de norm aan de ESPR-vereisten die zij afdekken, en zodra de Commissie de referentie van een norm in het Publicatieblad heeft bekendgemaakt, geeft naleving ervan een vermoeden van conformiteit (artikel 41 van de ESPR). Dat betekent dat een systeem dat op EN 18216 is afgestemd geacht wordt te voldoen aan het ESPR-vereiste voor gegevensuitwisseling, dat een systeem met identificatiecodes volgens EN 18219 geacht wordt te voldoen aan het uniciteitsvereiste, enzovoort. Update, oktober 2026: de referenties van alle zes zijn op 15 juli 2026 bekendgemaakt bij Uitvoeringsbesluit (EU) 2026/1736.

In de praktijk: als u niet kunt aantonen dat u op deze normen bent afgestemd, wordt uw conformiteitsbeoordeling onder de ESPR per geval een eigen betoog. Als u dat wel kunt, wordt het een vinkje.

EN 18216 — Protocollen voor gegevensuitwisseling

Dit is de norm voor de transportlaag. Ze bepaalt hoe een DPP-resource wordt opgevraagd, verzonden en weergegeven.

Punt 4 — Transport: voor de uitwisseling van DPP-gegevens moet HTTPS met minimaal TLS 1.2 worden gebruikt (TLS 1.3 wordt sterk aanbevolen) en minimaal HTTP/2, waarbij HTTP/3 wordt aanbevolen. API’s horen de RESTful-stijl te volgen. Oudere protocollen (TLS 1.1, SSL) zijn verboden.

Punt 5 — Formaten en content negotiation: JSON (volgens ISO/IEC 21778) moet worden ondersteund als basis voor syntactische interoperabiliteit. XML, JSON-LD en HTML mogen daarnaast worden aangeboden, en het geleverde formaat wordt gekozen via HTTP content negotiation (volgens RFC 9110, het standaardpatroon met de Accept-header).

Op dat laatste vereiste zakken de meeste huidige DPP-implementaties. Dezelfde URL moet ofwel weergegeven HTML teruggeven (voor een consument die een QR-code scant) ofwel machineleesbare JSON / JSON-LD (voor de tool van een recycler, een koppeling met een marktplaats of een verificateur), afhankelijk van de Accept-header die de client meestuurt. Eén resource, meerdere representaties.

Als er HTML wordt teruggegeven, moet die voldoen aan EN 301549 (de Europese toegankelijkheidsnorm). Een DPP-pagina die alleen HTML levert, voldoet niet aan EN 18216, ook al is al het andere eraan correct.

EN 18219 — Unieke identificatiecodes

Dit is de norm voor het identificatieschema, en de meest voorschrijvende van de zes.

Punt 4.1 — wereldwijde uniciteit: geen hertoewijzing, onderscheidend van elke andere identificatiecode, en geen naast elkaar bestaande andere ID voor hetzelfde productexemplaar.

Punt 4.2 — persistentie: de identificatiecode moet de insolventie of liquidatie van de marktdeelnemer overleven. Een opmerking voegt eraan toe dat het EU-register voor DPP’s zorgt voor een minimaal niveau van bewaring van identificatiecodes; het paspoort zelf beschikbaar houden is een afzonderlijke plicht onder de ESPR, waaraan wordt voldaan via een reservekopie bij een aanbieder van digitale-productpaspoortdiensten (artikel 10, lid 4, van de ESPR).

Punt 4.3 — syntaxis: tekenset volgens ISO/IEC 646; de URI-vorm moet RFC 3986 volgen; de identificatiecode moet een URL zijn of naar een URL om te zetten zijn.

Punt 4.4 — detailniveau: elke identificatiecode moet uniek zijn op het kleinste detailniveau dat zij bedient (model, partij of serienummer op artikelniveau). Het detailniveau moet gelijk blijven zodra het product op de markt is. Als het detailniveau verandert — bijvoorbeeld wanneer een merk overstapt van DPP’s op partijniveau naar DPP’s op artikelniveau — moet er een nieuwe identificatiecode worden uitgegeven die met de oude wordt verbonden voor de traceerbaarheid.

Punt 4.6 — openheid: de openbare DPP-informatie moet bereikbaar zijn zonder registratie, het downloaden van een app of inloggegevens. Lock-in bij een leverancier is niet toegestaan.

ID-schema 1 — webgeschikte ID met gestructureerd pad (de GS1-route): in de praktijk de dominante route. De identificatiecode moet voldoen aan GS1 Digital Link URI Syntax v1.6.0:2022, GS1 Application Identifiers toepassen volgens ISO/IEC 15418, resolutie via een gestructureerd pad volgens ISO/IEC 18975 volgen, en een geregistreerde Issuing Agency Code volgens ISO/IEC 15459-2 gebruiken (een echte GS1 Global Company Prefix, geen tijdelijke vulwaarde).

Een conforme GS1 Digital Link-URL ziet er zo uit: /01/{GTIN}/22/{CPV}/10/{batch}/21/{serial}. De padsegmenten coderen het detailniveau automatisch: /01/{GTIN} alleen is modelniveau, met /10/{batch} erbij wordt het partijniveau, en met /21/{serial} erbij wordt het artikelniveau.

Punt 6 — identificatiecodes voor marktdeelnemers en faciliteiten: deze moeten een van de schema’s ISO/IEC 6523 (LEI, GS1 GCP, PEPPOL), ISO/IEC 15418/15459, DID of DOI gebruiken. Fabrikantnamen als vrije tekst in een DPP-header zijn niet conform.

EN 18220 — Gegevensdragers

Deze norm bepaalt via welk fysiek of visueel middel de DPP-identificatiecode een scanner of lezer bereikt. In de praktijk: QR-codes, Data Matrix-codes, RFID-tags en NFC-tags.

EN 18220 vereist dat de gegevensdrager de unieke productidentificatiecode (volgens EN 18219) codeert die toegang geeft tot het DPP, leesbaar is voor algemeen verkrijgbare smartphonecamera’s en standaard industriële lezers, en voldoet aan duurzaamheidseisen die passen bij de levenscyclus van het product.

Voor de meeste consumentgerichte categorieën — textiel, schoeisel, meubelen — is een QR-code met de GS1 Digital Link-URL de feitelijke gegevensdrager. EN 18220 bevestigt dat dit aanvaardbaar is, maar stelt eisen aan duurzaamheid en contrast. Merken die papieren hangtags gebruiken, moeten ervoor zorgen dat de gegevensdrager ten minste blijft bestaan tot het product is verkocht; merken die ingenaaide labels gebruiken, moeten ervoor zorgen dat die gedurende de verwachte levensduur van het product scanbaar blijven.

EN 18221 — Gegevensopslag, archivering en persistentie

Hier zit bij de meeste bestaande DPP-implementaties de grootste leemte.

Punt 4.2 — archivering vanaf de eerste wijziging: elke wijziging van een DPP moet worden gearchiveerd vanaf het moment van de wijziging, en de versiegeschiedenis moet gedurende de volledige levensduur van het DPP worden bewaard. Het DPP is geen enkel wijzigbaar record; het is een object met versies en een volledige geschiedenis.

Punten 4.3 en 4.5 — aanbieder van een back-up van het DPP: wanneer een product in de handel wordt gebracht, kan worden vereist dat er via een dienstverlener een reservekopie beschikbaar wordt gesteld — de formulering van de norm is voorwaardelijk, en of het van toepassing is, volgt uit de eigen regels voor het product. Waar het van toepassing is, bevat de back-up de actuele versie en alle vereiste historische versies, en wordt de algemene toegang tot het paspoort bij de back-up opengesteld zodra de marktdeelnemer niet meer actief is op de markt. Dat is wat de identificatiecode de vereiste persistentie geeft (EN 18219 §4.2.2, dat vereist dat de identificatiecode insolventie, liquidatie of bedrijfsbeëindiging overleeft).

De duur staat in deze norm niet als getal. EN 18221 definieert de levensduur van het digitale productpaspoort als de periode waarin het paspoort volgens de regelgeving beschikbaar moet zijn, en elke eis over de duur verwijst daarnaar terug — de jaren komen dus uit de gedelegeerde handeling onder de ESPR voor de categorie, niet uit de norm. Wel stelt de norm een eis aan het toegangspatroon: de versie zoals die op een bepaald moment was, moet kunnen worden opgevraagd door geauthenticeerde en gemachtigde actoren, zodat het archief doorzoekbaar is in plaats van een log waarin alleen wordt geschreven.

Een DPP-systeem dat alleen de laatste stand van elk paspoort opslaat, is niet conform. Merken moeten vanaf dag één ontwerpen voor opslag met versies — tabellen voor versiegeschiedenis en versiebewuste leesendpoints toevoegen is veel eenvoudiger in een nieuw systeem dan achteraf in een systeem dat al twee jaar live is.

EN 18222 — API’s voor de levenscyclus en doorzoekbaarheid van productpaspoorten

Dit is de API-norm. Ze bepaalt de minimale interface die elk DPP-systeem moet aanbieden.

EN 18222 schrijft drie leesmethoden voor die elk conform DPP-systeem als gestandaardiseerde endpoints moet aanbieden:

  • ReadDPPById — haalt een DPP op aan de hand van zijn unieke identificatiecode (de volledige Digital Link-URI of de canonieke ID).
  • ReadDPPByProductId — haalt het actuele DPP op voor een productidentificatiecode (doorgaans de GTIN) en geeft het meest recente paspoort terug.
  • ReadDPPIdsByProductIds — opzoeken in bulk: geeft bij een lijst van productidentificatiecodes de bijbehorende DPP-ID’s terug. Zo verwerken marktplaatsen, douaneautoriteiten en recyclers catalogi efficiënt.

De norm definieert ook levenscyclusmethoden voor het aanmaken, bijwerken, archiveren en registreren van DPP’s in het EU-register. Die moeten geauthenticeerd en met toegangscontrole beveiligd zijn (met EN 18239 zodra die is gepubliceerd).

De meeste DPP-systemen bieden vandaag alleen een generieke CRUD-interface op hun eigen gegevensmodel. EN 18222 vereist dat de drie leesmethoden bestaan als gestandaardiseerde endpoints — zodat een tool die tegen één DPP-systeem volgens EN 18222 is gebouwd, een ander systeem zonder codewijzigingen kan bevragen. Dat is de technische basis voor koppelingen met marktplaatsen en recyclers op EU-schaal.

EN 18223 — Systeeminteroperabiliteit

Dit is de schemanorm. Ze bepaalt de canonieke structuur van een DPP-header — de metadata rond de productspecifieke inhoud — zodat verschillende DPP-systemen elkaars paspoorten kunnen uitwisselen en interpreteren.

Volgens punt 4.1.2.1 moet de DPP-header het volgende bevatten:

  • granularity — model, partij of artikel — uitdrukkelijk opgegeven
  • dppSchemaVersion — versie van het gebruikte schema
  • dppStatus — actief, ingetrokken, vervangen, gearchiveerd
  • lastUpdated — tijdstempel van de laatste wijziging
  • economicOperatorId — correct opgemaakt volgens ISO/IEC 6523 (LEI of GS1 GCP), geen vrije tekst
  • facilityId — dezelfde eis aan de opmaak
  • dictionaryReference — per gegevenselement een verwijzing naar het gecontroleerde vocabulaire dat dat element definieert
  • contentSpecificationIds — verwijzingen naar de inhoudsspecificaties van de productcategorie (in textiel-DPP’s het schema van de gedelegeerde handeling onder de ESPR)

EN 18223 maakt interoperabiliteit werkelijkheid. Twee DPP-systemen die op dezelfde inhoudsspecificatie zijn afgestemd en allebei headers volgens EN 18223 produceren, kunnen gegevens uitwisselen zonder integratiewerk op maat. Een recycler kan één tool bouwen die textiel-DPP’s van elk merk verwerkt.

Wat nog ontbreekt: EN 18239 en EN 18246

Twee normen uit de reeks worden nog afgerond (update, oktober 2026: beide zijn nu gepubliceerd, maar nog niet in het Publicatieblad bekendgemaakt):

  • EN 18239 — Toegangsrechten en beveiliging. Bepaalt hoe authenticatie, autorisatie en rolgebaseerde toegang werken voor DPP-gegevens. Verschillende belanghebbenden (consument, reparatiewerkplaats, recycler, douaneautoriteit, toezichthoudende autoriteit) hebben verschillende niveaus van toegang tot hetzelfde DPP nodig.
  • EN 18246 — Authenticatie en integriteit van gegevens. Bepaalt hoe een DPP cryptografisch kan worden geverifieerd als authentiek en ongewijzigd. Maakt waarschijnlijk gebruik van verifiable credentials of vergelijkbaar W3C-werk.

Beide worden normatief aangehaald door EN 18221, EN 18222 en EN 18223 — de bestaande zes normen hebben dus afhankelijkheden die nog niet volledig zijn gepubliceerd. Merken die nu DPP-infrastructuur bouwen, zouden moeten ontwerpen met inplugbare lagen voor authenticatie en integriteit, klaar om EN 18239 en EN 18246 in te passen zodra die zijn afgerond.

Hoe dit aansluit op de tijdlijn van de gedelegeerde handelingen onder de ESPR

De kaderverordening ESPR (EU 2024/1781) is op 18 juli 2024 in werking getreden. Het werkplan van de Commissie voor de ESPR (gepubliceerd in april 2025) bevestigt de doorlopende reeks gedelegeerde handelingen die de vereisten per productgroep vastleggen. Voor textiel wordt de gedelegeerde handeling indicatief verwacht in 2027, met vereisten die ten minste 18 maanden na de inwerkingtreding ervan van toepassing worden — dus niet vóór medio 2028.

De hier beschreven CEN-normen zijn horizontaal — ze bepalen het systeem, niet de textielspecifieke gegevensvelden. Het gegevensschema voor textiel komt uit de gedelegeerde handeling onder de ESPR plus het sectorwerk van CIRPASS-2, en wordt in de EN 18223-header ingeplugd als de verwijzing contentSpecificationIds.

Die scheiding is belangrijk voor de planning. Een merk kan vandaag bouwen volgens EN 18216 / 18219 / 18220 / 18221 / 18222 / 18223 — de systeemlaag is nu volledig gespecificeerd voor de zes gepubliceerde normen. De laag met textielvelden komt er bovenop zodra de gedelegeerde handeling verschijnt, zonder dat het systeem opnieuw hoeft te worden ontworpen.

Wat merken nu moeten doen

Voor merken die al proef-DPP’s draaien (met QR-codes en Digital Link-URL’s) zijn dit de praktische stappen op korte termijn:

  1. Toets uw resolver aan EN 18216 §5. Geeft dezelfde URL JSON of JSON-LD terug bij een aanroep met Accept: application/json? Zo niet, voeg dan content negotiation toe. Dit is meestal de kleinste aanpassing op de lijst.
  2. Neem granularity, dppSchemaVersion, dppStatus en lastUpdated op in de DPP-header. Volgens EN 18223 §4.1.2.1 zijn deze verplicht.
  3. Vervang elk fabrikantveld in vrije tekst door een correct opgemaakte economicOperatorId. Volgens EN 18219 §6 moet dit een LEI, GS1 GCP of gelijkwaardig zijn. Vrije tekst haalt de conformiteitsbeoordeling niet.
  4. Plan het archiefontwerp voor EN 18221. Als uw DPP-tabel alleen de laatste stand opslaat, voeg dan een tabel met versies en versiebewuste leesendpoints toe. Dat is veel eenvoudiger toe te voegen voordat u honderdduizenden DPP’s in productie hebt.
  5. Plan de drie verplichte leesmethoden van EN 18222. Als uw huidige API een generieke CRUD op een datasourcemodel is, zet er dan dunne REST-aliassen voor die ReadDPPById, ReadDPPByProductId en ReadDPPIdsByProductIds als gestandaardiseerde endpoints aanbieden.

Waar u de normen kunt verkrijgen

CEN verkoopt normen niet rechtstreeks. Ze worden verspreid via de nationale normalisatie-instellingen. Gangbare aankooproutes voor de reeks EN 18216–18223:

  • SIS (sis.se) — de Zweedse nationale instelling. Aankoop per norm of een SIS-abonnement. Handig als u de volledige reeks in het Zweeds (SS EN) en het Engels wilt.
  • en-standard.eu — particuliere webwinkel, directe pdf-download.
  • DIN (Duitsland) / BSI (VK) — dezelfde EN-normen, soms sneller in een Engelse versie.

De gebruikelijke prijs is € 50-200 per norm. De volledige set van zes normen kost € 300-1.000, afhankelijk van de route. De status van de bredere reeks kunt u volgen op standards.cencenelec.eu.

Kortom

De publicatie van EN 18216, 18219, 18220, 18221, 18222 en 18223 neemt de grootste technische onduidelijkheid weg die de afgelopen drie jaar boven het DPP-werk hing. Merken hoeven niet langer te raden hoe een conform DPP-systeem eruitziet — de specificaties zijn nu normatief, te koop en geven — zodra hun referenties in het Publicatieblad zijn bekendgemaakt — een vermoeden van conformiteit onder artikel 41 van de ESPR.

De periode tussen nu en de handhaving van de ESPR voor textiel (niet vóór medio 2028) is het juiste moment om bestaande pilots aan de normen te toetsen, de leemtes te dichten in content negotiation, header-attributen, archiefontwerp en gestandaardiseerde leesmethoden, en te ontwerpen met inplugbare aansluitpunten voor EN 18239 en EN 18246 zodra die zijn afgerond.

Merken die nu volgens deze normen bouwen, hebben bij de handhaving een vermoeden van conformiteit. Merken die dat niet doen, moeten bij elke conformiteitsbeoordeling een eigen betoog voeren.