DPP-Daten aktuell halten: Was die ESPR wirklich vorschreibt

Seit der Verabschiedung der ESPR-Verordnung (EU) 2024/1781 ist der Digital Product Passport (DPP) verbindliches EU-Recht. Was viele Unternehmen unterschätzen: Der DPP ist kein statisches Dokument, das einmal bei der Markteinführung erzeugt wird. Er muss über den gesamten Produktlebenszyklus aktuell gehalten werden — und die Anforderungen daran werden zunehmend präziser.

Dieser Artikel erklärt, welche Daten wann aktualisiert werden müssen, wie die Registry-Architektur das Update-Modell beeinflusst und welche technischen Muster sich in der Praxis bewähren.

Was die Verordnung zum Update-Zyklus sagt

Statische vs. dynamische Datenfelder

Die ESPR selbst nennt keine explizite Update-Frequenz, legt aber fest, dass der DPP „aktuelle und genaue Informationen" enthalten muss. Die Konkretisierung erfolgt auf Sektorebene — und hier liefert der JRC-Entwurf für Halbzeugprodukte aus Eisen und Stahl das bislang klarste Bild.

Der Entwurf unterscheidet systematisch zwischen zwei Datengranularitäten:

Ebene	Identifier	Beispieldaten	Update-Anlass
Chargenebene (Lot)	Losnummer	Recyclatanteil, Legierungszusammensetzung, PCF nach ISO 14067	Bei Produktionsänderung, neuer Charge
Produktebene (Item)	Seriennummer	Abmessungen, Zertifizierungen, Konformitätserklärungen	Bei Rezertifizierung, Rückruf, Reparatur

Diese Unterscheidung ist für die Datenbankarchitektur entscheidend: Chargen-Daten werden typischerweise einmal pro Produktionslauf geschrieben und sind danach stabil — es sei denn, eine Nachberechnung des CO₂-Fußabdrucks ergibt einen korrigierten Wert. Produktebenen-Daten hingegen können sich über die gesamte Nutzungsdauer ändern, etwa wenn ein Gerät repariert oder eine Zertifizierung erneuert wird.

Die Batterieverordnung (EU) 2023/1542 kennt diese Unterscheidung bereits implizit: Kapazitätsdaten, die sich durch Degradation verändern, müssen aktuell gehalten werden — eine Anforderung, die ohne klare Architektur kaum erfüllbar ist.

Die Registry als Verzeichnis, nicht als Datenspeicher

Ein häufiges Missverständnis betrifft die Rolle der zentralen DPP-Registry. Der Entwurf der Durchführungsverordnung zur DPP-Registry stellt klar: Die Registry speichert ausschließlich den eindeutigen Identifier, den Resolver-Endpunkt und den Warencode — nicht die eigentlichen Passdaten.

Das bedeutet für das Update-Management: Passinhalt und Registry sind getrennte Systeme. Wer Produktdaten aktualisiert, muss in der Regel nicht die Registry anfassen — es sei denn, der Resolver-Endpunkt ändert sich (etwa bei einem Systemwechsel). Das CIRPASS-2-Konsortium hat in seiner Stellungnahme zum Registry-Entwurf explizit auf dieses Architekturmuster hingewiesen und empfiehlt, die Norm EN 18219 als verbindliche Referenz in die Durchführungsverordnung aufzunehmen — unter anderem, um die Interoperabilität mit dem GS1 Digital Link sicherzustellen.

Update-Szenarien in der Praxis

Szenario 1: Neuer CO₂-Fußabdruck durch Lieferantenwechsel

Der produktspezifische CO₂-Fußabdruck (PCF) wird nach dem JRC-Stahl-Entwurf auf Chargenebene gepflegt und muss mit ISO-14067-kompatiblen Methoden berechnet werden. Wechselt ein Stahlproduzent seinen Energieträger oder Schrottlieferanten, ändert sich der PCF der neuen Charge — nicht aber der bereits ausgelieferten Chargen.

Technisch bedeutet das: Der DPP-Datensatz der alten Charge bleibt unverändert. Für die neue Charge wird ein neuer Datensatz angelegt, der denselben Resolver-Endpunkt nutzen kann, aber eine neue Losnummer als Identifier trägt.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Szenario 2: Ablaufende Zertifizierung auf Produktebene

Konformitätserklärungen und Zertifizierungen haben Ablaufdaten. Sobald eine neue Zertifizierung ausgestellt wird, muss der DPP auf Produktebene aktualisiert werden. Da der Resolver-Endpunkt unverändert bleibt, ist kein Registry-Update nötig — nur der Datensatz hinter dem Endpunkt ändert sich.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Szenario 3: Resolver-Migration bei Systemwechsel

Wechselt ein Unternehmen seinen DPP-Dienstleister, ändert sich der Resolver-Endpunkt. In diesem Fall muss die Registry aktualisiert werden — und zwar für jeden betroffenen Identifier. Das ist der aufwändigste Update-Typ, weil er einen Registry-Write erfordert.

Empfehlung: Nutzen Sie einen stabilen, eigenen Resolver (z. B. dpp.ihrunternehmen.de) als Zwischenschicht, der intern auf den jeweiligen Dienstleister weiterleitet. So bleibt der in der Registry eingetragene Endpunkt dauerhaft stabil.

Technische Anforderungen an das Update-System

Versionierung und Audit-Trail

Die ESPR verlangt keine explizite Versionierung, aber die Kombination aus Produkthaftung und Zollkontrolle macht einen Audit-Trail faktisch unumgänglich. Wenn ein Zollbeamter in 2030 den DPP eines 2027 produzierten Stahlträgers prüft, muss nachvollziehbar sein, welche Daten zum Zeitpunkt der Einfuhr galten.

Minimales Schema für eine versionierte DPP-Tabelle:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link als stabiler Identifier-Anker

Der GS1 Digital Link trennt Identifier und Resolver sauber: Der QR-Code auf dem Produkt kodiert eine URL wie https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, die über den GS1-Resolver oder einen eigenen Resolver auf den aktuellen DPP-Datensatz zeigt. Aktualisierungen am Datensatz erfordern keine neue Etikettierung — der physische Datenträger bleibt unverändert.

TEKLYNX hat seine CODESOFT-Software aktualisiert und unterstützt nun GS1-„++"-Kodierungsschemata, mit denen Web-URLs direkt in RAIN-RFID-Tag-Speicher geschrieben werden können — eine Anforderung, die aus der Kombination von EN 18220 und dem GS1 Digital Link-Standard folgt.

Governance: Wer darf was aktualisieren?

Neben der technischen Frage stellt sich die Governance-Frage: Welche Akteure in der Lieferkette dürfen welche Felder des DPP schreiben? Das CIRPASS-2-Konsortium hat hier kritische Punkte zur Datensouveränität bei grenzüberschreitenden Lieferketten identifiziert.

Ein Praxismodell unterscheidet drei Rollen:

Hersteller (Creator): Schreibt alle Felder bei Erstellung; darf alle Felder aktualisieren.
Autorisiierter Akteur (Editor): Darf definierte Felder aktualisieren (z. B. Reparaturhistorie, neue Zertifizierungen) — dokumentiert mit eigenem Identifier.
Leser (Reader): Kann alle öffentlichen Felder lesen, keine Schreibrechte.

Ecommerce Europe hat in seinem Positionspapier zur DPP-Implementierung gefordert, dass auch für Gebrauchtprodukte „partielle DPPs" möglich sein sollen — also Datensätze, die nur einen Teil der ursprünglichen Felder aktualisieren. Das ist technisch heute schon umsetzbar, fehlt aber noch als formale Kategorie in den Durchführungsverordnungen.

Fazit

DPP-Daten aktuell zu halten ist kein einmaliger Aufwand, sondern ein Betriebsprozess. Die wichtigsten Erkenntnisse aus dem aktuellen Regulierungsstand:

Trennen Sie Charge und Produkt — die Identifier-Strategie bestimmt, welche Daten wann aktualisiert werden müssen.
Die Registry ist kein Datenspeicher — Updates am Passinhalt erfordern in der Regel keinen Registry-Write.
Versionierung ist faktisch Pflicht — auch wenn die Verordnung sie nicht explizit vorschreibt.
GS1 Digital Link entkoppelt physischen Datenträger und Datensatz — das reduziert den Aufwand bei Datenaktualisierungen erheblich.
Governance-Rollen müssen vorab definiert werden — wer darf was schreiben, und wie wird das protokolliert?

Die Normen werden präziser, die ersten Piloten laufen — wer jetzt die Architektur richtig aufsetzt, vermeidet teure Korrekturen, wenn die sektorspezifischen Durchführungsverordnungen in Kraft treten.