Der neue praktische Engpass: Wer darf einen Pass registrieren?
Das EU-DPP-Register ist seit dem 20. Juli 2026 operativ. Für viele Teams stand zunächst die technische Frage im Vordergrund: Lässt sich ein Produkt-Identifier registrieren, und löst der Datenträger korrekt auf? Das ist nötig, aber unvollständig. Mit der Durchführungsverordnung (EU) 2026/1778 vom 16. Juli 2026 bekommt die vorgelagerte Identität eine eigene regulatorische Bedeutung: Registrieren sollen verifizierte Wirtschaftsakteure, und der Zugriff auf Registerfunktionen ist nicht dasselbe wie der öffentliche Zugriff auf Produktinformationen.
Das ist kein Anlass, QR-Codes komplizierter zu machen. Es ist ein Anlass, Verantwortlichkeiten, Nachweise und Berechtigungen vor dem ersten produktiven Registrierungsprozess sauber zu modellieren. Der folgende Leitfaden trennt diese Ebenen und zeigt, was Hersteller jetzt praktisch vorbereiten können.
Drei Identitäten, die nicht vermischt werden dürfen
In einem DPP-Projekt treten mindestens drei unterschiedliche Identitäten auf.
Erstens gibt es den Wirtschaftsakteur: das Unternehmen oder den Einzelunternehmer, der ein Produkt in Verkehr bringt oder im Register handelt. Artikel 4 der Verordnung 2026/1778 knüpft die Einstufung als „verified economic operator“ an einen Identitätsnachweis. Für in der EU ansässige Einzelunternehmer nennt der Rechtsakt etwa eine qualifizierte elektronische Signatur oder ein eIDAS-konformes elektronisches Identifizierungsmittel mit hohem Vertrauensniveau. Juristische Personen müssen ebenfalls über definierte Nachweise verifiziert werden.
Zweitens gibt es den menschlichen Benutzer. Einkauf, Stammdatenpflege, Compliance, externe Dienstleister und ein DPP-Service-Provider handeln nicht automatisch mit derselben Befugnis. Ein Benutzerkonto ist deshalb kein Ersatz für den verifizierten Unternehmenskontext. Es braucht eine nachvollziehbare Zuordnung: Wer handelt für welchen Wirtschaftsakteur, mit welcher Rolle und bis wann?
Drittens gibt es die Produktidentität. Ein GTIN, eine Seriennummer oder ein anderer Identifier beschreibt das Produkt beziehungsweise die geforderte Granularität; er belegt nicht, dass die Person am Bildschirm zur Registrierung berechtigt ist. Das ESPR trennt diese Sphären ausdrücklich: Der Datenträger verbindet das Produkt mit dem Pass, während das Register die eindeutigen Identifikatoren und Registrierungsdaten hält. Die Kommissionsübersicht zum DPP beschreibt den Ablauf entsprechend: Produktinformationen werden erstellt und registriert, anschließend erzeugt das Register eine eindeutige Registrierungs-ID.
Wer diese drei Identitäten in einer Tabelle, einem API-Token oder einem gemeinsamen E-Mail-Postfach zusammenzieht, schafft später ein Audit- und Betriebsrisiko. Die richtige Frage lautet nicht „Wer kennt den Link?“, sondern „Wer darf im Namen dieses Wirtschaftsakteurs eine Registerhandlung auslösen?“.
Öffentlicher QR-Zugriff ist keine Registerberechtigung
Ein QR-Code auf dem Produkt bleibt ein Zugang zum Pass. Er ist kein Login-Mechanismus für das Register und sollte auch nicht zu einem werden. Verbraucher, Reparaturbetriebe, Recycler und Behörden benötigen jeweils andere Informationen. Der aktuelle Kommissionsleitfaden zum DPP beschreibt ausdrücklich, dass Informationen nach Nutzerrollen zugänglich sind.
Praktisch empfiehlt sich daher eine klare Schichtentrennung:
- Der öffentliche Scan liefert eine stabile, kostenfrei erreichbare Passansicht mit den für die jeweilige Produktgruppe vorgeschriebenen Informationen.
- Eine rollenbeschränkte Oberfläche verwaltet Nachweise, Lieferantendaten, Änderungsverläufe und interne Freigaben.
- Der Register-Connector darf nur die erforderlichen Registrierungsdaten übermitteln und eine Antwort des Registers einem konkreten Produktdatensatz zuordnen.
Das verhindert zwei verbreitete Fehlannahmen. Erstens: Ein „geheimer“ QR-Link ersetzt keine Zugriffskontrolle; er kann weitergegeben werden und ist kein belastbarer Berechtigungsnachweis. Zweitens: Das Register ist nicht der Speicherort für sämtliche Produktunterlagen. Die Kommission erläutert, dass die vollständigen Produktinformationen beim Wirtschaftsakteur oder einem DPP-Service-Provider liegen können; registriert werden die erforderlichen Metadaten und Identifier.
Was die Verordnung technisch nahelegt
Die Verordnung 2026/1778 beschreibt das Register nicht als bloße Lookup-Datenbank. Sie nennt unter anderem eine API für Registrierung und Datenempfang, eine Plattform zur Bestätigung von Existenz und Vollständigkeit, ein Schema für eindeutige Registrierungs-IDs, ein Verzeichnis verifizierter DPP-Service-Provider, ein Logsystem sowie Identifikations- und Autorisierungsschemata. Datenmodelle müssen zudem versioniert sein.
Aus diesen Vorgaben folgt keine fertige Produktarchitektur. Sie liefern aber robuste Leitplanken:
Unternehmensprofil vor Produktimport
Legen Sie vor einem Massenimport einen kontrollierten Unternehmensdatensatz an. Dazu gehören die juristische Einheit, ihr Status als Wirtschaftsakteur, der gewählte Identitätsnachweis, der Zeitpunkt der Prüfung und die verantwortliche Stelle. Den Nachweis selbst sollte ein DPP-System nur speichern, soweit das nötig und zulässig ist; häufig genügt ein Prüfstatus mit Referenz und Ablauf- oder Neubewertungslogik.
Delegation ist ein eigener Datensatz
Wenn ein Service-Provider oder eine Agentur tätig wird, braucht die Delegation einen Umfang. Sinnvoll sind mindestens Wirtschaftsakteur, erlaubte Aktionen, Produktgruppen oder Marken, Beginn, Ende und Widerruf. Ein allgemeiner API-Schlüssel ohne Mandatsgrenze ist für eine registrierungsrelevante Handlung zu grob.
Registrierung als nachweisbarer Vorgang
Pro Registrierung sollten Teams mindestens die lokale Produktversion, den übermittelten Identifier, die Antwort inklusive Registrierungs-ID, Zeitstempel, handelnde Rolle und Fehlerklasse festhalten. Damit lässt sich später unterscheiden, ob ein Pass fachlich unvollständig war, ein Identifier kollidierte oder die Berechtigung fehlte. Die Protokollierung soll nicht zur Sammlung unnötiger personenbezogener Daten werden; sie soll eine verantwortliche, prüfbare Handlungskette schaffen.
Berechtigungen testen wie Fachregeln
Testfälle sollten nicht bei „API antwortet 200“ enden. Prüfen Sie mindestens: Ein unberechtigter Benutzer kann keine Registrierung auslösen; ein delegierter Provider kann nur das vereinbarte Mandat bearbeiten; eine abgelaufene Delegation wird abgewiesen; die öffentliche Passansicht offenbart keine internen Register- oder Nachweisdaten; und ein erneut eingereichter Vorgang wird nachvollziehbar als Wiederholung behandelt.
Ein schlanker Startplan für die nächsten Wochen
Beginnen Sie nicht mit einer Vollmigration. Wählen Sie eine kleine, repräsentative Produktmenge und eine reale Verantwortlichkeitskette.
- Ordnen Sie für jedes Pilotprodukt Hersteller, Inverkehrbringer, Datenverantwortliche und gegebenenfalls Service-Provider zu.
- Dokumentieren Sie, mit welchem Verfahren der Wirtschaftsakteur verifiziert wird und wer die Prüfung freigibt.
- Definieren Sie Rollen für Entwurf, fachliche Freigabe, Registrierung und reine Leserechte.
- Registrieren Sie einen Testdatensatz mit versionierten Produktdaten und protokollieren Sie Registrierung, Antwort und Korrekturpfad.
- Testen Sie den öffentlichen QR-Zugang getrennt von internen Rollen und dem Register-Connector.
- Üben Sie Widerruf und Wechsel: Was passiert bei einem Dienstleisterwechsel, einer geänderten Unternehmensbezeichnung oder einem fehlerhaften Identifier?
Dieser Ablauf passt auch zu der bereits veröffentlichten Empfehlung, Register, Resolver und Datenquelle getrennt zu testen. Neu ist der Schwerpunkt: Vor einer robusten API-Integration muss klar sein, welche verifizierte Organisation und welche Rolle die Handlung verantwortet.
Was noch nicht behauptet werden sollte
Die Register-Verordnung schafft den technischen und organisatorischen Rahmen. Sie macht nicht jede Produktgruppe sofort DPP-pflichtig und ersetzt keine sektorspezifischen delegierten Rechtsakte. Die Kommission ordnet die Einführung weiterhin produktgruppenweise ein; nach ESPR-Delegierten Rechtsakten ist grundsätzlich eine Übergangszeit von mindestens 18 Monaten vorgesehen. Ebenso ist ein verifizierter Unternehmensstatus kein Freibrief für unvollständige oder falsche Produktdaten.
Für Teams ist die Konsequenz dennoch konkret: Identität, Mandat, Rollen und Protokollierung gehören in den DPP-Backlog, bevor Registrierungen skalieren. So bleibt der QR-Code der einfache öffentliche Einstieg — und die Registerhandlung wird zu dem, was sie regulatorisch ist: eine verantwortliche, nachvollziehbare Aktion eines verifizierten Wirtschaftsakteurs.
