Der Digitale Produktpass ist keine ferne EU-Idee mehr, sondern beschlossenes Recht. Die Verordnung steht, die ersten Produktgruppen sind definiert, die Fristen laufen. Wer 2026 erst anfängt darüber nachzudenken, ist spät dran. Wir bauen seit Jahren Shops und Headless-Integrationen für Hersteller und Händler, die genau jetzt die Frage stellen: Was müssen wir wirklich tun, was ist Hype und wo fängt man technisch an? Dieser Artikel gibt die ehrliche Antwort.
Inhalt
- Was ist der Digitale Produktpass?
- Wer ist wann betroffen?
- Welche Daten muss der DPP enthalten?
- Wo liegt das eigentliche Problem? Nicht der QR-Code.
- Wie sieht die technische Architektur aus?
- PIM, ERP, Shop: Wer liefert was?
- Was kostet die DPP-Umsetzung?
- Was wir gerade in Projekten sehen
Was ist der Digitale Produktpass?
Der Digitale Produktpass (DPP, englisch Digital Product Passport) ist ein strukturierter, maschinenlesbarer Datensatz, der einem physischen Produkt eindeutig zugeordnet ist. Zugriff erfolgt über einen Datenträger am Produkt, meist einen QR-Code oder RFID-Chip, der auf eine standardisierte URL oder API führt. Der Datensatz enthält Informationen zu Material, Herkunft, Reparierbarkeit, Recyclingfähigkeit und CO₂-Fußabdruck.
Rechtliche Grundlage ist die EU-Ökodesign-Verordnung für nachhaltige Produkte (ESPR), die 2024 verabschiedet wurde. ESPR ist der Rahmen. Die konkreten Anforderungen pro Produktgruppe werden über delegierte Rechtsakte festgelegt. Parallel dazu gibt es produktspezifische Regelungen, etwa die EU-Batterieverordnung, die einen eigenen Battery Passport vorschreibt.
Der Kern in einem Satz: Jedes Produkt bekommt eine digitale Akte, die über seinen gesamten Lebenszyklus konsistent bleibt und für Behörden, Handel, Reparaturbetriebe, Recycler und Endkunden abrufbar ist.
Wer ist wann betroffen?
Das ist die Frage, die in jedem Workshop zuerst kommt. Und wo im Netz die meiste Verwirrung herrscht. Deshalb die nüchterne Einordnung:
- Batterien (Industrie- und EV-Batterien über 2 kWh): Battery Passport ab Februar 2027. Das ist die erste harte Frist und läuft über die Batterieverordnung, nicht über ESPR.
- Textilien: In der ersten Welle des ESPR-Arbeitsplans. Delegierter Rechtsakt wird vorbereitet, Pflicht voraussichtlich 2027 bis 2028.
- Eisen, Stahl, Aluminium: Ebenfalls erste Welle. Für B2B-Hersteller besonders relevant.
- Möbel, Reifen, Waschmittel: In Vorbereitung.
- Elektronik, Bauprodukte: Eigene Regelwerke, Details noch in Arbeit.
- Spielzeug: Neue Toy Safety Regulation verlangt DPP bis spätestens 2028.
Was du nicht liest: Eine pauschale Pflicht für "alle Produkte ab 2027". Diese Aussage geistert durch viele Artikel, ist aber falsch. ESPR wird produktgruppenweise ausgerollt. Bis alle priorisierten Gruppen abgedeckt sind, sind wir realistisch bei 2030.
Bedeutet für dich: Schau dir dein Sortiment an und ordne jede Produktkategorie einer Welle zu. Daraus ergibt sich dein interner Fahrplan. Wer Batterien oder Textilien verkauft, muss jetzt liefern. Wer Hundefutter verkauft, hat mehr Zeit.
Welche Daten muss der DPP enthalten?
Die genaue Datenstruktur wird pro Produktgruppe festgelegt, aber es gibt einen Kern, der in allen Entwürfen auftaucht:
- Produktidentifikation: Eindeutige ID (meist GS1 Digital Link), Modell, Seriennummer bei relevanten Produkten
- Materialzusammensetzung: Rohstoffe, chemische Zusammensetzung, Anteil recycelter Materialien
- Herkunft und Lieferkette: Herstellungsort, Lieferanten bei kritischen Komponenten
- Umweltdaten: CO₂-Fußabdruck, Energieverbrauch in der Nutzung, Wasserverbrauch
- Reparatur und Ersatzteile: Reparaturanleitungen, Ersatzteilverfügbarkeit, Reparierbarkeitsindex
- Recyclingfähigkeit: Demontagehinweise, Sortierhinweise, Entsorgungswege
- Compliance-Dokumente: Konformitätserklärungen, Zertifikate, Prüfberichte
Zugriffsrechte sind dabei granular. Endkunden sehen eine vereinfachte Ansicht. Behörden, Recycler und Reparaturbetriebe bekommen tiefere Daten. Lieferanten-sensible Informationen bleiben geschützt. Das ist ein eigenes Rollen- und Rechtekonzept, das in der Architektur frühzeitig mitgedacht werden muss.
Unser Hinweis: Die meisten Hersteller haben diese Daten schon, aber verstreut über Excel, PIM, ERP, PDF-Datenblätter und Mails mit Lieferanten. Das Datenmodell zusammenzuführen ist 80 Prozent der Arbeit. Der QR-Code am Produkt ist die letzten 5 Prozent.
Wo liegt das eigentliche Problem? Nicht der QR-Code.
Viele DPP-Angebote im Markt lösen das falsche Problem. Sie generieren einen QR-Code, legen eine hübsche Landingpage darunter und verkaufen das als "DPP-ready". Technisch ist das in zwei Tagen gebaut. Praktisch löst es null deiner echten Probleme.
Das echte Problem ist die Datenkonsistenz über Systeme und Zeit hinweg. Konkret:
- Daten-Herkunft: Wer ist Source of Truth für welches Attribut? PIM für Marketing-Daten, ERP für Lieferanten-IDs, Labor für Materialdaten, externes Tool für CO₂-Bilanz. Ohne klare Datenherkunft baust du ein Kartenhaus.
- Versionierung: Der DPP muss den Zustand zum Zeitpunkt des Inverkehrbringens dokumentieren. Wenn du dein Produkt 2028 änderst, muss der Pass für 2027-Produkte unverändert abrufbar bleiben. Zehn Jahre lang. Mindestens.
- Lieferanten-Daten: Deine CO₂-Daten sind oft nur so gut wie die Daten deiner Lieferanten. Die liefern aber heute Excel per Mail. Du brauchst einen Prozess und eine Schnittstelle, um das zu automatisieren.
- Multi-Language und Multi-Market: Pflichtangaben je nach Zielmarkt, Sprache, Produktvariante. Skaliert nur, wenn es strukturiert aus einem zentralen System kommt.
- Endpunkt-Stabilität: Die URL hinter dem QR-Code muss Jahrzehnte stabil sein. Kein Shop-Replatforming, kein Domain-Wechsel, kein CMS-Umbau darf den Zugriff brechen.
Wer den DPP als Marketing-Feature denkt, wird die Compliance-Seite unterschätzen. Und wer ihn rein als Compliance-Thema denkt, verschenkt das Business-Potential: Reparaturservice, Second-Life-Markt, Kundenbindung nach dem Kauf.
Wie sieht die technische Architektur aus?
In unseren Projekten läuft es auf drei Muster hinaus, je nach Ausgangslage und Sortiment.
Muster 1: PIM-zentriert
Das PIM ist Hub für alle produktbezogenen Daten. DPP-Daten werden als eigene Attributgruppen modelliert. Ausleitung über eine stabile API an einen separaten DPP-Service, der die öffentlichen Endpunkte bereitstellt. Shop bleibt konsumierender Layer.
Passt für: Hersteller mit ausgebautem PIM, mittlere bis große Sortimente, viel Produktvarianz.
Muster 2: Dedizierter DPP-Service neben dem Shop
Eigener Microservice, der die DPP-Endpunkte hostet. PIM und ERP schieben Daten via Event-Bus oder Batch in den Service. Datenträger-URL zeigt nicht auf den Shop, sondern auf den DPP-Service. Vorteil: Shop-Replatforming oder Domain-Wechsel brechen den Pass nicht.
Passt für: Unternehmen mit mehreren Vertriebskanälen, Marken-Setup mit mehreren Shops, Zukunftssicherheit im Vordergrund.
Muster 3: Plattform-Integration
Nutzung einer DPP-Plattform wie CIRCULARISE, Madaster, Circulor oder Aware. Eigene Systeme liefern Daten per API rein, die Plattform übernimmt öffentliche Bereitstellung, Versionierung und Zugriffssteuerung.
Passt für: Unternehmen, die schnell loslegen müssen und keine eigene Architektur aufbauen wollen. Nachteil: Abhängigkeit vom Anbieter.
In allen drei Mustern bauen wir den DPP Headless. Die öffentliche Ansicht ist ein minimaler Frontend-Layer, der rein eine API konsumiert. Das hält die Architektur austauschbar und skalierbar. Wenn du deinen Shop auf Shopware Headless oder commercetools betreibst, ist die Anschlussstelle sowieso schon da.
PIM, ERP, Shop: Wer liefert was?
Eine der häufigsten Fragen im Scoping. Faustregel:
- ERP: Artikelstamm, Lieferanten-IDs, Chargen, Seriennummern, interne IDs
- PIM: Marketing- und Produktattribute, Sprachvarianten, Medien, Varianten, Materialdaten, Klassifizierungen
- LCA-Tools / CO₂-Rechner: Umweltbilanz, Impact-Daten (z.B. über ecoinvent, SimaPro, externe Dienstleister)
- Dokumenten-Management: Konformitätserklärungen, Zertifikate, Testberichte
- Lieferantenportal / SRM: Upstream-Daten für Materialherkunft, Compliance-Statements
- Shop: Endkunden-Ansicht, Übergabe an Checkout, Nutzererlebnis. Nicht Source of Truth für DPP-Pflichtdaten.
Wenn du noch kein ausgebautes PIM-Setup hast, ist DPP genau der Auslöser, der das jetzt erzwingt. Wer versucht, DPP direkt im Shop zu modellieren, baut sich Altlasten fürs nächste Replatforming.
Was kostet die DPP-Umsetzung?
Pauschalpreise nennen wir bewusst nicht, weil die Spannweite riesig ist und vom Ausgangsstack abhängt. Aber als Orientierung, was wir in unseren Projekten sehen:
- Datenmodell-Audit und Gap-Analyse: ab 10.000+ EUR. Inventur deiner Daten, Mapping auf DPP-Anforderungen, Lücken identifizieren.
- PIM-Erweiterung um DPP-Attribute: ab 15.000+ EUR. Hängt stark davon ab, ob ein PIM existiert und wie sauber es gepflegt ist.
- DPP-Service als eigener Microservice: 40.000+ EUR, bei komplexen Sortimenten schnell 100.000+ EUR. Öffentliche API, Versionierung, Zugriffsrollen, Admin-UI.
- Lieferanten-Anbindung: 20.000+ EUR, bei vielen Lieferanten und tiefer Integration Richtung 100.000+ EUR.
- QR-Code-Integration in Produktkennzeichnung: Verpackungs- und Produktionsseitig, oft über bestehende Etiketten-Prozesse, niedrig fünfstellig.
- Laufende Pflege: ab 2.000+ EUR monatlich, abhängig von Sortiment und Update-Frequenz.
Kostentreiber Nummer eins ist in jedem Projekt die Datenqualität. Wer saubere Stammdaten und ein gepflegtes PIM hat, kommt deutlich günstiger weg. Wer sein Sortiment noch in Excel verwaltet, hat einen unsichtbaren Zusatzposten für das Aufräumen.
Was wir gerade in Projekten sehen
Drei Muster, die in unseren DPP-Workshops immer wieder auftauchen:
1. "Das lösen wir später." Die Batterieverordnung ist bereits in Kraft und greift Anfang 2027. Wer jetzt noch nicht weiß, wie sein Datenmodell aussehen soll, wird nicht rechtzeitig fertig. Ein sauberes DPP-Projekt dauert in unseren Projekten 6 bis 12 Monate, abhängig vom Ausgangsstack.
2. "Das macht unser Shopsystem." Shopsysteme sind keine DPP-Plattformen. Shopware, Shopify, commercetools können DPP-Daten anzeigen und einen QR-Code ausspielen, aber sie sind nicht der richtige Ort für die dauerhafte Datenhaltung und Versionierung. Wer DPP im Shop zentralisiert, baut Altlasten. Deshalb: Datenhaltung separat, Shop konsumiert.
3. "Wir kaufen eine Plattform und sind fertig." DPP-Plattformen sind ein sinnvoller Baustein, aber kein Komplettpaket. Die Daten müssen trotzdem sauber aus PIM, ERP und Lieferanten-Systemen kommen. Die Plattform liefert das Dach, nicht das Fundament.
In einem aktuellen Projekt bauen wir für einen Textilhersteller den DPP als eigenen Service neben dem Shopware 6 Shop. Daten kommen aus Storyblok für redaktionelle Inhalte, aus dem PIM für Stammdaten und aus einem externen LCA-Tool für Umweltdaten. Der Pass ist über eine eigene Subdomain abrufbar, stabil und vom Shop entkoppelt. Das ist der Ansatz, der auch Replatforming in fünf Jahren überlebt.
Fazit: DPP ist ein Datenprojekt mit einem kleinen Frontend
Der Digitale Produktpass wird gerne als neues Feature für den Online-Shop verkauft. In Wahrheit ist er ein Datenprojekt. Das Frontend, also der QR-Code und die Detailseite, ist der einfachste Teil. Die Arbeit liegt in Datenmodell, Systemintegration, Lieferanten-Anbindung und Versionierung. Wer das jetzt sauber aufsetzt, hat in fünf Jahren ein Asset. Wer abkürzt, baut Technical Debt, die spätestens beim nächsten Replatforming schmerzt.
Unser Rat: Fang nicht mit dem QR-Code an, fang mit dem Datenmodell an. Mach eine ehrliche Gap-Analyse. Bau die Architektur austauschbar. Und halte den Shop raus aus der Rolle der Source of Truth.
Häufige Fragen zum Digitalen Produktpass
Ab wann ist der Digitale Produktpass Pflicht?
Die Pflicht kommt produktgruppenweise, nicht pauschal ab einem Stichtag. Erste harte Frist ist Februar 2027 für Industrie- und EV-Batterien über die EU-Batterieverordnung. Textilien folgen voraussichtlich 2027 bis 2028 über ESPR, dann Eisen/Stahl/Aluminium, Möbel, Reifen und Elektronik. Spielzeug bis spätestens 2028 über die neue Toy Safety Regulation. Bis alle priorisierten Produktgruppen abgedeckt sind, sind wir realistisch bei 2030.
Wie komplex ist die Implementierung bei großen Produktkatalogen?
Die technische Umsetzung ist beherrschbar, das eigentliche Problem ist die Datenkonsistenz. Daten liegen verstreut in ERP, PIM, Laborsystemen, LCA-Tools und bei Lieferanten in Excel-Listen per Mail. 80 Prozent der Arbeit ist das Datenmodell zusammenzuführen und eine Source of Truth pro Attribut festzulegen. Der QR-Code auf dem Produkt sind die letzten 5 Prozent. Ohne ausgebautes PIM wird es schwer.
Welche Branchen sind zuerst betroffen vom digitalen Produktpass?
Batterie-Hersteller (Industrie/EV) durch die Batterieverordnung ab Februar 2027. Textilhersteller und Importeure in der ersten ESPR-Welle. Eisen-, Stahl- und Aluminiumindustrie. Möbel, Reifen, Waschmittel in Vorbereitung. Händler dieser Produkte sind ebenfalls betroffen, weil sie Daten sauber weitergeben und am Produkt zugänglich machen müssen.
Wie bereitest du dich am besten auf den Digitalen Produktpass vor?
Fang nicht mit dem QR-Code an, sondern mit dem Datenmodell. Schritt eins: Gap-Analyse. Welche DPP-Pflichtattribute verlangt deine Produktgruppe, welche liegen wo bereits vor, welche fehlen. Schritt zwei: Source of Truth pro Attribut festlegen (meist PIM, teilweise ERP oder externe Tools). Schritt drei: Architektur entscheiden (PIM-zentriert, dedizierter DPP-Service oder Plattform). Schritt vier: Lieferanten-Datenzulieferung automatisieren. Shop kommt zuletzt.
Welche Daten müssen im Digitalen Produktpass enthalten sein?
Die genaue Struktur wird pro Produktgruppe festgelegt. Kern-Attribute: eindeutige Produktidentifikation (meist GS1 Digital Link), Materialzusammensetzung inklusive recycelter Anteile, Herkunft und Lieferkette, Umweltdaten wie CO₂-Fußabdruck und Wasserverbrauch, Reparaturinformationen und Reparierbarkeitsindex, Recyclingfähigkeit und Demontagehinweise, Compliance-Dokumente und Zertifikate. Zugriffsrechte sind granular: Endkunden sehen weniger als Behörden oder Recycler.
Wer ist für die Datenpflege im DPP verantwortlich?
Rechtlich der Hersteller bzw. Inverkehrbringer. Händler müssen sicherstellen, dass die Daten korrekt verfügbar sind und am Produkt zugänglich bleiben. In der Praxis bedeutet das: Hersteller brauchen einen Prozess für Upstream-Daten von Lieferanten, Versionierung bei Produktänderungen und eine URL, die 10 Jahre und mehr stabil bleibt. Kein Shop-Replatforming, kein Domain-Wechsel darf den Zugriff brechen.
Wo muss der Digitale Produktpass abgebildet werden?
Physisch am Produkt oder auf der Verpackung als Datenträger, meist QR-Code oder RFID. Digital hinter einer stabilen URL, die den maschinenlesbaren Datensatz ausspielt und eine menschliche Detailansicht rendert. Der Shop kann eine Endkundenansicht integrieren, sollte aber nicht die Source of Truth sein. Empfohlen: eigener DPP-Service oder Subdomain, die vom Shop entkoppelt ist und Replatforming überlebt.
Du hast ein konkretes DPP-Projekt im Kopf?
30 Minuten Erstgespräch zu deiner Ausgangslage. Wir schauen uns an, welche Produktgruppen für dich relevant sind, wo dein Datenmodell gerade steht und welcher Architektur-Ansatz passt. Ehrlich, ohne Verkaufsdruck.
Geschrieben von Christian Dangl. Head of Technology bei dasistweb. Headless- und Integrations-Spezialist. Architekt hinter den meisten Headless-Shopware-Projekten im DACH-Raum. Wenn du ein konkretes DPP-Projekt planst: Erstgespräch vereinbaren
Weitere Artikel zum Thema: