Der Normrahmen steht — jetzt beginnt die Umsetzung
Mit der Verabschiedung der ESPR-Verordnung (EU) 2024/1781 ist der Digital Product Passport (DPP) verbindliches EU-Recht. Was lange als Zukunftsprojekt galt, hat seit dem Frühjahr 2026 eine entscheidende neue Qualität gewonnen: Die technischen Normen, auf die sich die Durchführungsverordnungen stützen werden, liegen jetzt vor.
Anfang Juni 2026 präsentierte die DPP4EU-Konferenz in Brüssel das Normpaket, das unter CEN/CENELEC JTC 24 erarbeitet wurde. Die Normenreihe EN 18216 bis EN 18223 definiert die technische Kerninfrastruktur: Datenträger, eindeutige Identifikatoren, APIs und das Rahmenwerk für Interoperabilität. Parallel wurden Open-Source-Testumgebungen vorgestellt, mit denen Implementierungen auf Konformität geprüft werden können. Das Fraunhofer IPK, das an der Normentwicklung beteiligt war, kommentierte: „The standards are here — now is the time to bring them to life."
Dieser Satz beschreibt die Lage präzise. Die regulatorische Architektur ist gesetzt; was fehlt, sind sektorspezifische Durchführungsverordnungen, ein stabiler Registry-Betrieb und eine flächendeckende Implementierungspraxis in der Industrie.
Was die Normen EN 18216–18223 konkret regeln
Identifikatoren und Datenträger
Die Normenreihe legt fest, dass jeder DPP über einen eindeutigen Produktidentifikator verfügen muss, der maschinenlesbar und dauerhaft auflösbar ist. EN 18220 regelt die zulässigen Datenträger — darunter QR-Codes, DataMatrix und RAIN-RFID. Entscheidend ist, dass die Norm technologieneutral formuliert ist: Sie schreibt keinen bestimmten Träger vor, definiert aber Mindestanforderungen an Lesbarkeit und Persistenz.
Der GS1 Digital Link ist in diesem Kontext keine Pflicht, aber de facto der dominante Kandidat für die Identifier-Strategie — weil er bestehende GTIN-Infrastruktur mit Web-URI-Auflösung verbindet. Das CIRPASS-2-Konsortium hat in seiner Stellungnahme zum Entwurf explizit empfohlen, die Norm EN 18219 als Referenz in die Durchführungsverordnung aufzunehmen, um die Interoperabilität mit GS1 Digital Link und anderen bestehenden Identifikationssystemen sicherzustellen.
Registry-Architektur: dezentral mit zentralem Index
Ein häufiges Missverständnis betrifft die geplante EU-DPP-Registry. Sie wird keine Produktdaten speichern, sondern ausschließlich eindeutige Identifikatoren und Resolver-URLs — also Zeiger auf dezentral gehostete Passportdaten. Die Datenhaltungsverantwortung verbleibt beim Hersteller oder einem beauftragten Dienstleister.
CIRPASS-2 kritisiert an diesem Modell vor allem drei Punkte: die Governance-Struktur der Registry (wer betreibt sie, unter welchen Bedingungen?), die Frage der Datensouveränität bei grenzüberschreitenden Lieferketten und die noch offene Interoperabilität mit nationalen Systemen. Diese Kritik ist berechtigt — die Durchführungsverordnung zur Registry ist zum Redaktionsschluss noch im Entwurfsstadium.
Der JRC-Stahlentwurf als Blaupause für andere Sektoren
Warum Eisen und Stahl richtungsweisend sind
Das Joint Research Centre der Europäischen Kommission hat einen Entwurf für den DPP von Halbzeugprodukten aus Eisen und Stahl vorgelegt. Dieser Entwurf ist aus mehreren Gründen über die Stahlindustrie hinaus relevant: Er formalisiert erstmals systematisch die Unterscheidung zwischen Daten auf Produktebene und Daten auf Chargenebene — eine Differenzierung, die für Datenbankarchitektur und Identifier-Strategie grundlegend ist.
Produkt- vs. Chargenebene: eine strukturelle Weichenstellung
Der JRC-Entwurf ordnet Datenpunkte explizit einer von zwei Ebenen zu:
Chargenebene (Losnummer):
- Recyclatanteil
- Legierungszusammensetzung
- Produktspezifischer CO₂-Fußabdruck (PCF)
Produktebene (Seriennummer):
- Abmessungen
- Zertifizierungen
- Konformitätserklärungen
Der produktspezifische CO₂-Fußabdruck wird nach dem Entwurf auf Basis von Berechnungsregeln ermittelt, die mit dem ISO-14067-Standard kompatibel sind. Das ist insofern bedeutsam, als es eine methodische Mindestanforderung definiert — nicht nur eine Datenpflicht.
Die Batterieverordnung (EU) 2023/1542 — bislang der einzige verbindliche Sektorakt mit eigenen DPP-Pflichten — kennt diese Unterscheidung bereits implizit. Der Stahlsektor-Entwurf formalisiert sie jedoch erstmals explizit, was für alle nachfolgenden Sektorakte als Vorlage dienen dürfte.
Für Unternehmen, die heute ihre DPP-Datenbankarchitektur planen, hat das unmittelbare Konsequenzen: Ein flaches Datenmodell, das alle Attribute auf Produktebene führt, wird den regulatorischen Anforderungen nicht genügen. Wer bereits mit Bulk-Import-Workflows arbeitet, sollte prüfen, ob die Importstruktur zwischen Los- und Seriennummerndaten unterscheidet.
Verwandte Entwicklungen: REACH-Mikroplastik und RFID-Kodierung
ECHA-Leitlinien zu synthetischen Polymerpartikeln
Parallel zu den DPP-Entwicklungen hat die ECHA im Mai 2026 Leitlinien zur REACH-Meldepflicht für synthetische Polymermikropartikel veröffentlicht. Die erste Meldefrist für Hersteller und industrielle Nachnutzer von Polymer-Pellets, -Flocken und -Pulvern ist im Mai 2026 wirksam geworden.
Dieser Schritt ist kein DPP-Thema im engeren Sinne, aber er illustriert die breitere regulatorische Richtung: Die EU baut systematisch Meldepflichten für Stoffeigenschaften auf, die mittelfristig in DPP-Datenanforderungen einfließen werden. Unternehmen, die heute REACH-Daten erheben, schaffen damit eine Grundlage für spätere DPP-Attribute.
RAIN-RFID und GS1 Digital Link: Kodierungsstandards in der Praxis
Auf der Implementierungsseite hat TEKLYNX seine CODESOFT-Software aktualisiert und unterstützt nun GS1-„++"-Kodierungsschemata (EPC++ und ISO BD). Damit können Web-URLs direkt in RAIN-RFID-Tag-Speicher geschrieben werden — eine Anforderung, die aus der Kombination von EN 18220 und dem GS1 Digital Link-Standard folgt.
Das ist ein konkretes Beispiel dafür, wie die abstrakten Normanforderungen in Produktionssoftware ankommen. Für Unternehmen, die RFID-basierte Lieferkettenprozesse betreiben, bedeutet dies: Die Identifier-Strategie muss bereits beim Tag-Encoding beginnen, nicht erst beim Resolver-Setup.
Was Unternehmen jetzt tun sollten
Die regulatorische Lage lässt sich in drei Handlungsfelder gliedern:
1. Normkonformität prüfen: Die Normen EN 18216–18223 sind veröffentlicht. Wer heute DPP-Systeme aufbaut, sollte sicherstellen, dass die gewählten Datenträger, Identifikatoren und APIs mit diesen Normen kompatibel sind. Die Open-Source-Testumgebungen, die auf der DPP4EU-Konferenz vorgestellt wurden, bieten dafür eine erste Prüfmöglichkeit.
2. Datenmodell nach Ebenen strukturieren: Der JRC-Stahlentwurf zeigt, wohin die Reise geht. Unternehmen sollten ihr Datenmodell so aufbauen, dass Chargen- und Produktdaten sauber getrennt und separat adressierbar sind. Das betrifft sowohl die interne Datenhaltung als auch die API-Schnittstellen zum DPP-System.
3. Registry-Entwicklung verfolgen: Die Durchführungsverordnung zur zentralen DPP-Registry ist noch nicht final. Die Kritikpunkte von CIRPASS-2 — insbesondere zur Governance und Datensouveränität — sind inhaltlich stichhaltig und könnten den finalen Entwurf noch beeinflussen. Unternehmen sollten die Registry nicht als fertige Infrastruktur einplanen, sondern als Variable in ihrer Systemarchitektur behandeln.
Die Normen sind da. Die ersten sektorspezifischen Entwürfe liegen vor. Was jetzt zählt, ist der Aufbau von Implementierungskompetenz — bevor die Fristen der Durchführungsverordnungen das Tempo vorgeben.
