EN 18216 bis 18223: Die sechs CEN-Normen, die einen konformen digitalen Produktpass definieren

Drei Jahre lang ist jede Diskussion über den digitalen Produktpass (DPP) an derselben Frage hängen geblieben: Wie sieht ein konformes DPP-System eigentlich aus? Die ESPR (EU 2024/1781) ist die rechtliche Grundlage. CIRPASS-2 hat die Architektur skizziert. GS1 Digital Link hat uns die URL-Syntax gegeben. Was aber fehlte, waren die eigentlichen normativen technischen Normen – diejenigen, auf die eine Marke zeigen und sagen kann: „Baut danach.“

Diese Lücke ist jetzt geschlossen. Das Gemeinsame Technische Komitee 24 von CEN/CENELEC (JTC 24) hat sechs normative Europäische Normen veröffentlicht, die die technische Architektur eines digitalen Produktpasses abdecken. Zusammen legen sie fest, wie Kennungen funktionieren, wie Daten getragen werden, wie sich die API verhält, wie Daten ausgetauscht und archiviert werden und wie Systeme zusammenarbeiten.

Die sechs veröffentlichten Normen sind:

  • EN 18216 – Datenaustauschprotokolle
  • EN 18219 – Eindeutige Kennungen
  • EN 18220 – Datenträger
  • EN 18221 – Datenspeicherung und Persistenz
  • EN 18222 – APIs für Lebenszyklus und Durchsuchbarkeit von Produktpässen
  • EN 18223 – Systeminteroperabilität

Zwei weitere – EN 18239 (Zugriffsrechte und Sicherheit) und EN 18246 (Datenauthentifizierung und Integrität) – sind als prEN-Entwürfe noch in Vorbereitung und werden von 18221, 18222 und 18223 normativ in Bezug genommen. Sie werden als Nächstes erwartet. Update, Oktober 2026: Beide wurden am 17. August 2026 von CEN angenommen und sind jetzt veröffentlicht – siehe Alle acht DPP-Normen sind veröffentlicht, nur sechs sind im Amtsblatt gelistet.

Dieser Artikel geht durch, was jede der sechs veröffentlichten Normen tatsächlich verlangt, warum Marken ihre DPP-Systeme schon jetzt danach ausrichten sollten und wie die Normen mit dem Zeitplan der delegierten Rechtsakte der ESPR für Textilien zusammenspielen.

Warum diese Normen für die ESPR-Konformität zählen

Artikel 9 der ESPR verlangt digitale Produktpässe für Produkte, die in den von delegierten Rechtsakten erfassten Produktgruppen auf dem EU-Markt in Verkehr gebracht werden. Die Artikel 10 und 11 listen die wesentlichen Anforderungen auf: Pässe müssen mit einer dauerhaften eindeutigen Kennung verknüpft, maschinenlesbar, zugänglich, sicher und interoperabel sein.

Diese Artikel legen allerdings nicht fest, wie die Anforderungen auf technischer Ebene zu erfüllen sind. Genau das leisten diese CEN-Normen. Anhang ZA jeder Norm ordnet ihre Abschnitte den ESPR-Anforderungen zu, die sie abdeckt, und sobald die Kommission eine Norm im Amtsblatt listet, begründet ihre Anwendung eine Konformitätsvermutung (ESPR Artikel 41) – das heißt, bei einem an EN 18216 ausgerichteten System wird vermutet, dass es die Datenaustauschanforderung der ESPR erfüllt, bei einem System mit Kennungen nach EN 18219, dass es die Anforderung an die Eindeutigkeit erfüllt, und so weiter. Update, Oktober 2026: Alle sechs wurden am 15. Juli 2026 durch den Durchführungsbeschluss (EU) 2026/1736 im Amtsblatt gelistet.

Praktisch heißt das: Wenn Sie die Ausrichtung an diesen Normen nicht nachweisen können, wird Ihre Konformitätsbewertung nach der ESPR zu einer individuellen Argumentation von Fall zu Fall. Wenn Sie es können, wird sie zum Häkchen.

EN 18216 – Datenaustauschprotokolle

Das ist die Norm für die Transportschicht. Sie legt fest, wie eine DPP-Ressource angefordert, übertragen und dargestellt wird.

Abschnitt 4 – Transport: Der DPP-Datenaustausch muss HTTPS mit mindestens TLS 1.2 (TLS 1.3 dringend empfohlen) und mindestens HTTP/2 verwenden, wobei HTTP/3 empfohlen wird. APIs sollten dem REST-Stil folgen. Ältere Protokolle (TLS 1.1, SSL) sind verboten.

Abschnitt 5 – Formate und Content Negotiation: JSON (nach ISO/IEC 21778) muss als Basis der syntaktischen Interoperabilität unterstützt werden. XML, JSON-LD und HTML dürfen zusätzlich angeboten werden, und das ausgelieferte Format wird über HTTP-Content-Negotiation ausgewählt (nach RFC 9110, das übliche Muster mit dem Accept-Header).

An dieser letzten Anforderung scheitern die meisten heutigen DPP-Implementierungen. Dieselbe URL muss je nach dem vom Client gesendeten Accept-Header entweder gerendertes HTML liefern (für Verbraucher, die einen QR-Code scannen) oder maschinenlesbares JSON / JSON-LD (für das Werkzeug eines Recyclers, eine Marktplatzintegration oder eine Prüfstelle). Eine Ressource, mehrere Darstellungen.

Wird HTML zurückgegeben, muss es EN 301549 (der EU-Norm für Barrierefreiheit) entsprechen. Eine DPP-Seite, die nur HTML liefert, ist nach EN 18216 nicht normkonform, selbst wenn alles andere daran stimmt.

EN 18219 – Eindeutige Kennungen

Das ist die Norm für das Kennungsschema und die präskriptivste der sechs.

Abschnitt 4.1 – globale Eindeutigkeit: keine Neuvergabe, unterscheidbar von jeder anderen Kennung, keine gleichzeitige Existenz einer weiteren ID für dieselbe Produktinstanz.

Abschnitt 4.2 – Persistenz: Die Kennung muss die Insolvenz oder Liquidation des Wirtschaftsteilnehmers überdauern. Eine Anmerkung ergänzt, dass das EU-DPP-Register ein Mindestmaß an Erhaltung der Kennungen sicherstellt; den Pass selbst verfügbar zu halten ist eine eigene Pflicht nach der ESPR, die über eine Sicherungskopie bei einem Digitalproduktpass-Dienstleister erfüllt wird (ESPR Artikel 10 Absatz 4).

Abschnitt 4.3 – Syntax: Zeichensatz nach ISO/IEC 646; die URI-Form muss RFC 3986 folgen; die Kennung muss eine URL sein oder sich in eine URL umwandeln lassen.

Abschnitt 4.4 – Granularität: Jede Kennung muss auf der feinsten Granularität eindeutig sein, die sie bedient (Modell, Charge oder Seriennummer auf Artikelebene). Die Granularität muss gleich bleiben, sobald das Produkt auf dem Markt ist. Ändert sich die Granularität – etwa wenn eine Marke von DPPs auf Chargenebene zu DPPs auf Artikelebene wechselt –, muss eine neue Kennung vergeben und zur Rückverfolgbarkeit mit der alten verknüpft werden.

Abschnitt 4.6 – Offenheit: Die öffentlichen DPP-Informationen müssen ohne Registrierung, App-Download oder Zugangsdaten erreichbar sein. Ein Vendor-Lock-in ist nicht zulässig.

ID-Schema 1 – Web-enabled structured path ID (der GS1-Weg): In der Praxis der vorherrschende Weg. Er verlangt, dass die Kennung der GS1 Digital Link URI Syntax v1.6.0:2022 entspricht, GS1 Application Identifiers nach ISO/IEC 15418 verwendet, der Structured-Path-Auflösung nach ISO/IEC 18975 folgt und einen registrierten Issuing Agency Code nach ISO/IEC 15459-2 nutzt (ein echtes GS1 Global Company Prefix, keinen Platzhalter).

Eine konforme GS1-Digital-Link-URL sieht so aus: /01/{GTIN}/22/{CPV}/10/{batch}/21/{serial}. Die Pfadsegmente codieren die Granularität automatisch: /01/{GTIN} allein ist Modellebene, mit /10/{batch} wird es Chargenebene, mit /21/{serial} Artikelebene.

Abschnitt 6 – Kennungen für Wirtschaftsteilnehmer und Einrichtungen: Diese müssen eines der Schemata ISO/IEC 6523 (LEI, GS1 GCP, PEPPOL), ISO/IEC 15418/15459, DID oder DOI verwenden. Herstellernamen als Freitext im DPP-Header sind nicht konform.

EN 18220 – Datenträger

Diese Norm legt die physischen oder visuellen Mittel fest, über die die DPP-Kennung einen Scanner oder ein Lesegerät erreicht. In der Praxis: QR-Codes, Data-Matrix-Codes, RFID-Tags, NFC-Tags.

EN 18220 verlangt, dass der Datenträger die eindeutige Produktkennung (nach EN 18219) codiert, die Zugang zum DPP gibt, mit weit verbreiteten Smartphone-Kameras und üblichen Industrielesegeräten lesbar ist und Anforderungen an die Haltbarkeit erfüllt, die dem Lebenszyklus des Produkts angemessen sind.

Für die meisten verbrauchernahen Kategorien – Textilien, Schuhe, Möbel – ist ein QR-Code, der die GS1-Digital-Link-URL codiert, der De-facto-Datenträger. EN 18220 bestätigt, dass das zulässig ist, setzt aber Anforderungen an Haltbarkeit und Kontrast. Marken mit Hängeetiketten aus Papier müssen sicherstellen, dass der Datenträger mindestens bis zum Verkauf des Produkts überdauert; Marken mit eingenähten Etiketten müssen die Scanbarkeit über die erwartete Lebensdauer des Produkts sicherstellen.

EN 18221 – Datenspeicherung, Archivierung und Persistenz

Hier haben die meisten bestehenden DPP-Implementierungen die größte Lücke.

Abschnitt 4.2 – Archivierung ab der ersten Änderung: Jede Änderung an einem DPP muss ab dem Zeitpunkt der Änderung archiviert werden, und die Versionshistorie muss über die gesamte Lebensdauer des DPP aufbewahrt werden. Der DPP ist kein einzelner veränderlicher Datensatz; er ist ein versioniertes Objekt mit vollständiger Historie.

Abschnitte 4.3 und 4.5 – Backup beim DPP-Dienstleister: Wenn ein Produkt in Verkehr gebracht wird, kann verlangt werden, dass eine Sicherungskopie über einen Dienstleister zur Verfügung gestellt wird – die Norm formuliert das bedingt, und ob es gilt, ergibt sich aus den eigenen Regeln des Produkts. Wo es gilt, enthält die Sicherungskopie die aktuelle Version und alle erforderlichen historischen Versionen, und der allgemeine Zugang zum Pass über die Sicherungskopie öffnet sich, sobald der Wirtschaftsteilnehmer nicht mehr auf dem Markt aktiv ist. Das verleiht der Kennung ihre geforderte Persistenz (EN 18219 §4.2.2, wonach die Kennung Insolvenz, Liquidation oder Geschäftsaufgabe überdauern muss).

Die Dauer ist in dieser Norm keine Zahl. EN 18221 definiert die Lebensdauer des digitalen Produktpasses als den Zeitraum, in dem der Pass nach den Vorschriften verfügbar sein muss, und jede Anforderung an die Dauer verweist darauf zurück – die Jahre kommen also aus dem delegierten Rechtsakt der ESPR für die jeweilige Kategorie, nicht aus der Norm. Sie stellt allerdings eine Anforderung an das Zugriffsmuster: Die Version, wie sie zu einem bestimmten Zeitpunkt bestand, muss für authentifizierte und berechtigte Akteure abrufbar sein, sodass das Archiv abfragbar ist und kein reines Schreibprotokoll.

Ein DPP-System, das nur den jeweils letzten Stand jedes Passes speichert, ist nicht konform. Marken müssen von Anfang an für versionierte Speicherung planen – Tabellen für die Versionshistorie und versionsbewusste Lese-Endpunkte lassen sich in einem neuen System viel leichter ergänzen als in einem, das seit zwei Jahren live ist.

EN 18222 – APIs für Lebenszyklus und Durchsuchbarkeit von Produktpässen

Das ist die API-Norm. Sie legt die Mindestschnittstelle fest, die jedes DPP-System bereitstellen muss.

EN 18222 schreibt drei Lesemethoden vor, die jedes konforme DPP-System als standardisierte Endpunkte bereitstellen muss:

  • ReadDPPById – einen DPP über seine eindeutige Kennung abrufen (die vollständige Digital-Link-URI oder die kanonische ID).
  • ReadDPPByProductId – den aktuellen DPP für eine Produktkennung abrufen (typischerweise die GTIN), wobei der neueste Pass zurückgegeben wird.
  • ReadDPPIdsByProductIds – Massenabfrage: Zu einer Liste von Produktkennungen werden die zugehörigen DPP-IDs zurückgegeben. So verarbeiten Marktplätze, Zollbehörden und Recycler Kataloge effizient.

Die Norm legt außerdem Lebenszyklusmethoden zum Erstellen, Aktualisieren, Archivieren und Registrieren von DPPs im EU-Register fest. Diese müssen authentifiziert und zugriffsgeschützt sein (über EN 18239, sobald sie veröffentlicht ist).

Die meisten DPP-Systeme bieten heute nur eine generische CRUD-Schnittstelle über ihr eigenes Datenmodell. EN 18222 verlangt, dass es die drei Lesemethoden als standardisierte Endpunkte gibt – ein Werkzeug, das gegen ein EN-18222-konformes DPP-System gebaut ist, kann also ohne Codeänderungen ein anderes abfragen. Das ist die technische Grundlage für die Integration von Marktplätzen und Recyclern im EU-Maßstab.

EN 18223 – Systeminteroperabilität

Das ist die Schemanorm. Sie legt die kanonische Struktur eines DPP-Headers fest – der Metadaten, die den produktspezifischen Inhalt umschließen –, damit verschiedene DPP-Systeme die Pässe der jeweils anderen austauschen und interpretieren können.

Nach Abschnitt 4.1.2.1 muss der DPP-Header Folgendes enthalten:

  • granularity – Modell, Charge oder Artikel – ausdrücklich angegeben
  • dppSchemaVersion – Version des verwendeten Schemas
  • dppStatus – aktiv, zurückgezogen, ersetzt, archiviert
  • lastUpdated – Zeitstempel der letzten Änderung
  • economicOperatorId – korrekt formatiert nach ISO/IEC 6523 (LEI oder GS1 GCP), kein Freitext
  • facilityId – gleiche Formatierungsanforderung
  • dictionaryReference – je Datenelement ein Verweis auf das kontrollierte Vokabular, das dieses Element definiert
  • contentSpecificationIds – Verweise auf die Inhaltsspezifikationen der Produktkategorie (bei Textil-DPPs das Schema des delegierten Rechtsakts der ESPR)

EN 18223 macht Interoperabilität real. Zwei DPP-Systeme, die an derselben Inhaltsspezifikation ausgerichtet sind und beide EN-18223-konforme Header erzeugen, können Daten ohne individuelle Integrationsarbeit austauschen. Ein Recycler kann ein einziges Werkzeug bauen, das Textil-DPPs jeder Marke verarbeitet.

Was noch fehlt: EN 18239 und EN 18246

Zwei weitere Normen der Familie werden noch fertiggestellt (Update, Oktober 2026: Beide sind jetzt veröffentlicht, aber noch nicht im Amtsblatt gelistet):

  • EN 18239 – Zugriffsrechte und Sicherheit. Legt fest, wie Authentifizierung, Autorisierung und rollenbasierter Zugriff für DPP-Daten funktionieren. Verschiedene Beteiligte (Verbraucher, Reparaturbetrieb, Recycler, Zollbehörde, Überwachungsbehörde) brauchen unterschiedliche Zugriffsstufen auf denselben DPP.
  • EN 18246 – Datenauthentifizierung und Integrität. Legt fest, wie ein DPP kryptografisch als authentisch und unverändert verifiziert werden kann. Verwendet wahrscheinlich Verifiable Credentials oder ähnliche Arbeiten des W3C.

Beide werden von EN 18221, EN 18222 und EN 18223 normativ in Bezug genommen – die bestehenden sechs Normen haben also Abhängigkeiten, die noch nicht vollständig veröffentlicht sind. Marken, die jetzt eine DPP-Infrastruktur aufbauen, sollten mit austauschbaren Schichten für Authentifizierung und Integrität planen, in die EN 18239 und EN 18246 nach ihrer Fertigstellung eingesetzt werden können.

Wie das zum Zeitplan der delegierten Rechtsakte der ESPR passt

Die ESPR-Rahmenverordnung (EU 2024/1781) ist am 18. Juli 2024 in Kraft getreten. Der Arbeitsplan der Kommission für die ESPR (veröffentlicht im April 2025) bestätigt die fortlaufenden delegierten Rechtsakte, die die produktgruppenspezifischen Anforderungen festlegen. Für Textilien wird der delegierte Rechtsakt vorläufig für 2027 erwartet, wobei die Anforderungen frühestens 18 Monate nach seinem Inkrafttreten gelten – also nicht vor Mitte 2028.

Die hier beschriebenen CEN-Normen sind horizontal – sie definieren das System, nicht die textilspezifischen Datenfelder. Das Datenschema für Textilien kommt aus dem delegierten Rechtsakt der ESPR zusammen mit der Sektorarbeit von CIRPASS-2 und wird über den Verweis contentSpecificationIds in den EN-18223-Header eingehängt.

Diese Trennung ist für die Planung wichtig. Eine Marke kann heute nach EN 18216 / 18219 / 18220 / 18221 / 18222 / 18223 bauen – die Systemschicht ist für die sechs veröffentlichten Normen jetzt vollständig spezifiziert. Die Schicht der Textilfelder kommt obendrauf, wenn der delegierte Rechtsakt erscheint, ohne dass das System neu entworfen werden muss.

Was Marken jetzt tun sollten

Für Marken, die bereits Pilot-DPPs betreiben (mit QR-Codes und Digital-Link-URLs), sind die praktischen nächsten Schritte:

  1. Prüfen Sie Ihren Resolver gegen EN 18216 §5. Liefert dieselbe URL JSON oder JSON-LD, wenn sie mit Accept: application/json aufgerufen wird? Wenn nicht, ergänzen Sie Content Negotiation. Das ist meist die kleinste Korrektur auf der Liste.
  2. Heben Sie granularity, dppSchemaVersion, dppStatus und lastUpdated in den DPP-Header. Nach EN 18223 §4.1.2.1 sind diese verpflichtend.
  3. Ersetzen Sie jedes Freitextfeld für den Hersteller durch eine korrekt formatierte economicOperatorId. Nach EN 18219 §6 muss dies ein LEI oder ein GS1 GCP oder Gleichwertiges sein. Freitext fällt in der Konformitätsbewertung durch.
  4. Planen Sie das Archivdesign nach EN 18221. Wenn Ihre DPP-Tabelle nur den letzten Stand speichert, ergänzen Sie eine Versionstabelle und versionsbewusste Lese-Endpunkte. Das ist viel einfacher, bevor Sie Hunderttausende DPPs in Produktion haben.
  5. Planen Sie die drei verpflichtenden Lesemethoden nach EN 18222. Wenn Ihre aktuelle API eine generische CRUD-Schnittstelle über einem Datenquellenmodell ist, stellen Sie schlanke REST-Aliase davor, die ReadDPPById, ReadDPPByProductId und ReadDPPIdsByProductIds als standardisierte Endpunkte bereitstellen.

Wo Sie die Normen erhalten

CEN verkauft Normen nicht direkt. Sie werden über die nationalen Normungsorganisationen vertrieben. Übliche Bezugswege für die Reihe EN 18216–18223:

  • SIS (sis.se) – die schwedische nationale Normungsorganisation. Kauf einzelner Normen oder ein SIS-Abonnement. Nützlich, wenn Sie die gesamte Reihe auf Schwedisch (SS EN) und Englisch haben möchten.
  • en-standard.eu – privater Shop, sofortiger PDF-Download.
  • DIN (Deutschland) / BSI (Vereinigtes Königreich) – dieselben EN-Normen, englische Fassungen manchmal schneller.

Üblich sind 50–200 € pro Norm. Der vollständige Satz aus sechs Normen kostet je nach Bezugsweg 300–1.000 €. Den Stand der gesamten Reihe können Sie unter standards.cencenelec.eu verfolgen.

Fazit

Die Veröffentlichung von EN 18216, 18219, 18220, 18221, 18222 und 18223 beseitigt die größte technische Unklarheit, die in den letzten drei Jahren über der DPP-Arbeit lag. Marken müssen nicht mehr raten, wie ein konformes DPP-System aussieht – die Spezifikationen sind jetzt normativ, käuflich erhältlich und begründen – sobald sie im Amtsblatt gelistet sind – eine Konformitätsvermutung nach Artikel 41 der ESPR.

Das Zeitfenster zwischen jetzt und der Durchsetzung der ESPR für Textilien (nicht vor Mitte 2028) ist der richtige Zeitpunkt, bestehende Piloten gegen die Normen zu prüfen, Lücken bei Content Negotiation, Header-Attributen, Archivdesign und standardisierten Lesemethoden zu schließen und mit austauschbaren Anschlusspunkten für EN 18239 und EN 18246 zu planen, sobald diese fertiggestellt sind.

Marken, die jetzt nach diesen Normen bauen, haben zum Zeitpunkt der Durchsetzung die Konformitätsvermutung. Marken, die es nicht tun, müssen in jeder Konformitätsbewertung eine eigene Argumentation vorbringen.