CEN und CENELEC veröffentlichen erste EU-Normen für den Digitalen Produktpass

EN 18216 bis EN 18223: CEN und CENELEC legen den technischen Grundstein für den Digitalen Produktpass unter ESPR und Batterieverordnung. Was die Normen konkret regeln.

von QR3 Redaktion

CEN und CENELEC veröffentlichen erste EU-Normen für den Digitalen Produktpass

Der Startschuss für harmonisierte DPP-Technik

Am 27. Mai 2026 haben CEN und CENELEC die ersten harmonisierten europäischen Normen für den Digitalen Produktpass (DPP) veröffentlicht: die Normenreihe EN 18216:2026 bis EN 18223:2026. Das ist kein Routineereignis. Bislang gab es zwar politische Rahmenbedingungen — allen voran die Ökodesign-Verordnung ESPR und die Batterieverordnung (EU) 2023/1542 — aber keine verbindliche technische Spezifikation dafür, wie ein DPP konkret aufgebaut, adressiert und abgerufen werden soll. Diese Lücke schließen die neuen Normen.

Am 25. Juni 2026 hielten CEN und CENELEC ein öffentliches Webinar ab, um die Normen zu erläutern und Fragen der Industrie zu beantworten. Die Resonanz war groß — was den Druck zeigt, unter dem Hersteller, Importeure und Softwareanbieter stehen.

Was die Normen EN 18216–18223 regeln

Eindeutige Identifikatoren und Datenträger

Der Kern der Normenreihe liegt in drei Bereichen: eindeutige Produktidentifikatoren, Datenträger (also QR-Codes, RFID, DataMatrix und ähnliches) sowie APIs für den maschinellen Datenzugriff. Die Normen sind dabei bewusst produktagnostisch gehalten. Sie gelten nicht nur für Batterien, sondern legen die technische Grundlage für alle zukünftigen DPP-Pflichten unter der ESPR — von Textilien über Elektronik bis hin zu Baumaterialien.

Konkret schreibt die Normenreihe vor, wie ein Produkt über seinen gesamten Lebenszyklus eindeutig identifiziert werden muss. Dabei greift sie auf etablierte Standards zurück: Der GS1 Digital Link ist als bevorzugtes Format für die Verknüpfung von physischem Produkt und digitalem Datensatz vorgesehen. Das bedeutet, ein auf dem Produkt aufgebrachter QR-Code muss keine statische URL sein, sondern eine strukturierte, maschinenlesbare Adresse, über die Resolver-Dienste verschiedene Datenpunkte ausliefern können — je nach Anfragenden und Kontext.

API-Schnittstellen und Interoperabilität

Ein zentrales Ziel der Normen ist Interoperabilität: Behörden, Recyclingbetriebe, Verbraucher und Zulieferer sollen denselben DPP über standardisierte Schnittstellen abrufen können, unabhängig davon, welche Plattform den Pass hostet. Die Normen definieren dafür REST-basierte API-Profile. Hersteller und DPP-Plattformanbieter müssen sicherstellen, dass ihre Systeme diese Schnittstellen korrekt implementieren.

Für Entwickler bedeutet das konkret: Die API muss bestimmte Endpunkte und Antwortformate unterstützen. Ein vereinfachtes Beispiel für einen konformen DPP-Abruf könnte so aussehen:

GET /dpp/v1/passport/{digitalLinkId}
Accept: application/json
Authorization: Bearer <token>

Die Antwort muss strukturierte Metadaten zum Produkt liefern, einschließlich Verweisen auf Dokumente, Zertifikate und — bei Batterien — dynamische Zustandsdaten.

Batterieverordnung als Vorreiter: statische und dynamische Daten

Die Batterieverordnung (EU) 2023/1542, die im August 2023 in Kraft trat, ist der erste konkrete Anwendungsfall für den DPP. Sie unterscheidet implizit zwischen zwei Datenkategorien:

Statische Daten stehen beim Inverkehrbringen fest: Chemie, Hersteller, Nennkapazität, CO₂-Fußabdruck der Produktion. Diese Werte verändern sich nicht und können einmalig hinterlegt werden.

Dynamische Daten hingegen müssen über den gesamten Lebenszyklus aktualisierbar bleiben. Dazu gehören insbesondere der State of Health (SoH) und der State of Charge (SoC) — beide Kennwerte verschieben sich mit jedem Lade- und Entladezyklus. Die Verordnung schreibt ausdrücklich vor, dass diese Datenpunkte aktualisiert werden müssen. Das stellt Hersteller und Betreiber vor eine Systemarchitektur-Aufgabe: Der DPP darf kein statisches PDF sein, sondern muss an lebende Datenquellen angebunden sein.

Die neuen CEN/CENELEC-Normen adressieren genau diese Anforderung, indem sie API-Profile definieren, die sowohl lesende als auch schreibende Zugriffe — mit entsprechender Autorisierung — ermöglichen.

Neue Werkzeuge: Testumgebung und Open-Source-Validierung

Parallel zur Normveröffentlichung hat sich in der Praxis einiges getan.

BatteryPass-Ready Testumgebung

Am 24. Juni 2026 startete das Konsortium BatteryPass-Ready eine öffentliche Testumgebung für den Digitalen Batteriepass. Hersteller und Softwareanbieter können dort ihre Implementierungen gegen reale Testdaten prüfen, bevor die gesetzlichen Fristen greifen. Die Umgebung wird vom Fraunhofer IPK mitbetrieben und steht ohne Registrierungsschranke zur Verfügung.

Digital Passport Assessment Workbench (DP-AWB)

Im Juli 2026 veröffentlichten Forscher die Digital Passport Assessment Workbench (DP-AWB) als Open-Source-Tool. Das Werkzeug berechnet deterministische Bewertungsergebnisse direkt aus SHACL-Modellspezifikationen und ermöglicht es, DPP-Datenstrukturen formal zu validieren. Das ist relevant für alle, die sicherstellen müssen, dass ihre Datensätze nicht nur inhaltlich korrekt, sondern auch strukturell normkonform sind.

SHACL (Shapes Constraint Language) ist ein W3C-Standard zur Validierung von RDF-Graphen. Im DPP-Kontext bedeutet das: Wer seine Produktdaten als Linked Data modelliert, kann mit der DP-AWB automatisiert prüfen, ob alle Pflichtfelder vorhanden und korrekt typisiert sind — ohne manuelle Checklisten.

Die offene Frage: Die EU-weite DPP-Registry

Normen und Werkzeuge lösen ein Problem nicht: Wie findet man einen DPP, wenn man nur ein physisches Produkt vor sich hat? Die Europäische Kommission arbeitet an einer zentralen Registry, über die alle DPPs registriert und auffindbar gemacht werden sollen. Doch der Teufel steckt im Detail.

Orgalim — der europäische Industrieverband für Technologieunternehmen — hat dazu klare Anforderungen formuliert: Die Registry muss hochvolumige, automatisierte Registrierungsprozesse unterstützen. Wer sich vor Augen hält, dass allein in der EU jährlich Milliarden von Produkten in Verkehr gebracht werden, versteht das Problem. Eine Registry, die manuelle Einträge erfordert oder bei Lastspitzen ausfällt, ist für industrielle Anwendungsfälle unbrauchbar.

Orgalim fordert außerdem, dass die Registry gegen Betriebsausfälle abgesichert sein muss — Hochverfügbarkeit ist keine Option, sondern Voraussetzung. Denn wenn ein Zollbeamter oder ein Recyclingunternehmen einen DPP nicht abrufen kann, weil die Registry offline ist, bricht die gesamte Compliance-Kette zusammen.

Die Kommission hat bislang keinen verbindlichen Zeitplan für den Go-Live der Registry veröffentlicht. Das ist eine der größten offenen Flanken im DPP-Ökosystem.

Was Unternehmen jetzt tun sollten

Die Veröffentlichung der Normen EN 18216–18223 ist ein Wendepunkt: Die technischen Anforderungen sind jetzt definiert, auch wenn die Registry noch fehlt. Unternehmen, die unter die Batterieverordnung fallen oder sich auf künftige ESPR-Delegierte Rechtsakte vorbereiten, sollten drei Schritte priorisieren:

  1. Normen beschaffen und lesen. EN 18216–18223 sind über die nationalen Normungsgremien (DIN in Deutschland) erhältlich. Die Lektüre der API-Spezifikationen ist Pflicht für alle, die eigene DPP-Systeme entwickeln oder beschaffen.

  2. Datenarchitektur überprüfen. Können Ihre Systeme dynamische Datenpunkte (SoH, SoC, Reparaturhistorie) über eine API ausliefern? Falls nicht, ist jetzt der richtige Zeitpunkt für eine Architekturentscheidung — nicht sechs Monate vor der gesetzlichen Deadline.

  3. Testumgebungen nutzen. Die BatteryPass-Ready-Umgebung und die DP-AWB sind kostenlos verfügbar. Wer seine Implementierung frühzeitig testet, vermeidet teure Nachbesserungen unter Zeitdruck.

Die Normen sind veröffentlicht. Die Uhr läuft.

Quellen