Die EU hat bereits eine Referenzarchitektur für den Pass gebaut

Während Unternehmen auf delegierte Rechtsakte warten, hat EU-finanzierte Arbeit gebaut und getestet, wie ein System für den digitalen Produktpass (DPP) aussehen sollte. CIRPASS-2 hat im Juni 2026 eine Referenzarchitektur in Version 1.1 veröffentlicht, und die Pilotprojekte laufen in genau den Kategorien, die als erste verbindliche Regeln bekommen: Textil, Elektronik, Bau und Reifen.

Das ist wissenswert, auch wenn nichts davon Gesetz ist.

Was eine Referenzarchitektur ist, und was nicht

Sie ist eine Beschreibung der Bausteine, die ein Passsystem braucht, der Rollen der verschiedenen Akteure und einer Reihe von Empfehlungen, wie sie zusammenwirken sollten. Sie ordnet das den ESPR-Anforderungen zu.

Sie ist nicht bindend. Nichts darin verpflichtet jemanden, und ein System, das davon abweicht, ist nicht unkonform.

Was sie praktisch ist: die detaillierteste öffentliche Aussage darüber, wie "gut" aussieht, aus dem Teil des Ökosystems, der die Normen beeinflussen wird. Wenn Interoperabilität irgendwann beurteilt wird, wird sie in diesem Vokabular beurteilt.

Warum das kaufmännisch mehr zählt als technisch

Das Risiko, das Vorstände beim Pass übersehen, ist nicht, eine Prüfung nicht zu bestehen. Es ist, ein System zu wählen, das keine Daten mit den Systemen austauschen kann, die deine Kunden und Lieferanten wählen.

Ein Pass, der nur innerhalb der Plattform eines Anbieters auflöst, funktioniert bestens, bis das Einkaufssystem eines Kunden ihn automatisch lesen will, ein Marktplatz ihn anzeigen will oder ein Recycler ihn ein Jahrzehnt später abfragen will. Dann hört ein geschlossenes System auf, eine Produktentscheidung zu sein, und wird zu etwas, um das deine Lieferkette herumarbeiten muss.

Die Referenzarchitektur existiert genau, um diesen Ausgang zu verhindern, und deshalb ist es eine Absicherung und keine Compliance-Übung, sich daran auszurichten.

Was man einen Anbieter dazu fragt

Drei Fragen, für die du kein 97-seitiges Dokument lesen musst.

Kennt ihr die CIRPASS-2-Referenzarchitektur, und wo weicht ihr davon ab? Die nützliche Antwort nennt eine Abweichung und erklärt sie. Ein Anbieter, der volle Übereinstimmung mit einem Dokument behauptet, das noch eine Empfehlung im Entwurf ist, übertreibt.

Welche der Pilotkategorien habt ihr euch angesehen? Die Pilotprojekte sind öffentlich und bringen echte Integrationsprobleme ans Licht, besonders beim Datenaustausch mit Lieferanten.

Wie geht ihr mit Aktualisierungen von Dritten um? Lieferanten und Reparierende, die Daten in jemand anderes Pass einspielen, ist der Punkt, an dem die Architektur konkret wird und an dem sich Implementierungen am stärksten unterscheiden.

Die erwähnenswerte Lücke

Eine Beobachtung zum Umfang der Architektur, keine Kritik: Es gibt keinen Baustein für verbrauchergerichtete Echtheitsprüfung, und Fälschung wird nicht als Anwendungsfall behandelt. Der Scan ist als Weg zu Daten modelliert, nicht als Weg zu prüfen, ob ein Produkt echt ist.

Genau dort sitzt unsere eigene Verbraucher-App, und das ist der Grund, warum wir Echtheit und Pass als einen Code behandeln und nicht als zwei Systeme. Es ist eine Beobachtung darüber, was das Referenzmodell abdeckt, kein Beleg dafür, dass sich niemand sonst damit befasst.

Quellen

• CIRPASS-2, *D4.1 Reference Architecture*, Version 1.1, 9. Juni 2026, einschließlich der Bausteine des
• DPP-Dienstleisters und der Architekturempfehlungen.