DPP-Dienstleister-Anforderungen: EU-Regeln für Plattformen

Redaktionelle Aktualisierung, 22. Juli 2026: Produktivregister, Testumgebung, API-Zugang und erste Umsetzungsunterlagen sind verfügbar. Der veröffentlichte Benutzerleitfaden richtet sich jedoch ausschließlich an Wirtschaftsakteure und enthält weder ein Anbindungsverfahren für Dienstleister noch ein Zertifizierungsverfahren oder eine öffentliche Zertifizierungsliste. Die Verordnung (EU) 2026/1778 verlangt zwar eine Liste verifizierter DPP-Dienstleister; dabei geht es jedoch um Identitäts- und Zugriffsprüfung für Registerfunktionen, nicht um Zertifizierung, Akkreditierung oder die Übernahme produktrechtlicher Verantwortung.

Warum die Dienstleister-Schicht wichtig ist

Viele Unternehmen denken beim Digitalen Produktpass immer noch an die sichtbare Ebene: Produktdaten, QR-Codes, Verbraucherseiten und Konformitätserklärungen.

Für die EU ist das jedoch nur ein Teil des Bildes. Es gibt auch eine Infrastrukturebene: die Systeme und Dienstleister, die DPP-Datensätze speichern, verwalten, bereitstellen, sichern und langfristig steuern.

Deshalb bereitet die Europäische Kommission einen delegierten Rechtsakt speziell für DPP-Dienstleister vor.

Für Softwareplattformen hat das direkte Bedeutung. Es deutet darauf hin, dass DPP-Anbieter mehr werden könnten als gewöhnliche SaaS-Anbieter. Sie könnten zu einem regulierten oder teilweise regulierten Teil des DPP-Ökosystems werden, von dem Portabilität, Steuerung, Kontinuität und zuverlässiger Datenzugang erwartet werden.

Was die Kommission regulieren möchte

Die Initiative der Kommission zu DPP-Dienstleistern erklärt, dass sie Rückmeldungen dazu einholen will, wie Dienstleister Daten speichern und verwalten sollen und ob ein Zertifizierungssystem erforderlich ist.

Diese Fragestellung ist wichtig, weil sie zeigt, dass es nicht einfach um die Bedienbarkeit der Oberfläche oder die Erzeugung von QR-Codes geht. Die eigentlichen Fragen betreffen die Systemarchitektur:

• Wer kontrolliert die Daten?
• Wie werden sie gespeichert?
• Wer hat Zugriff?
• Wie bleibt die Verfügbarkeit über die Zeit erhalten?
• Brauchen Dienstleister eine formale Qualifikation oder Zertifizierung?

Der endgültige Rechtsakt ist noch nicht verabschiedet, aber die Fragen der Systemsteuerung sind bereits klar umrissen.

Der rechtliche Rahmen ist enger als die politische Debatte

Artikel 11 Absatz 2 ESPR ermächtigt die Kommission ausdrücklich, im delegierten Rechtsakt drei Punkte festzulegen:

1. Anforderungen, die Anbieter erfüllen müssen, um DPP-Dienstleister zu werden;
2. gegebenenfalls ein Zertifizierungssystem zur Prüfung dieser Zugangsvoraussetzungen; und
3. Anforderungen, die Anbieter bei der Erbringung von DPP-Diensten erfüllen müssen.

Nur dieser Umfang lässt sich sicher als feststehend beschreiben. Erwägungsgrund 40 liefert einen nicht operativen, aber relevanten Hinweis: Er sieht klarere Rollen und Verantwortlichkeiten von Ausgabestellen und Dienstleistern bei Erstellung, Authentifizierung, Verarbeitung und Speicherung von DPP-Daten sowie möglicherweise beim Rückzug wichtiger DPP-Elemente wie Kennungen und Datenträger vor. Er legt diese Einzelpflichten jedoch nicht selbst fest und garantiert nicht, dass jeder Punkt in den endgültigen Rechtsakt aufgenommen wird.

Die genauen Eignungskriterien, Dienstleistungspflichten und ein möglicher Zertifizierungsmechanismus sind noch nicht veröffentlicht. Portabilität, Kontinuität, Cybersicherheit, Interoperabilität und Rollentrennung sind gut belegte Umsetzungsthemen; die Konsultationsunterlagen zeigen jedoch politische Optionen und nicht die endgültige Regel.

Einen Teil der Grundlage liefert der ESPR bereits: Ein DPP kann vom Wirtschaftsakteur oder von einem Dienstleister gespeichert werden; das Design muss ein hohes Maß an Sicherheit und Datenschutz gewährleisten; ein Anbieter darf DPP-Daten nicht über das für die Dienstleistung erforderliche Maß hinaus verkaufen, weiterverwenden oder verarbeiten, sofern der Wirtschaftsakteur dem nicht ausdrücklich zugestimmt hat; und Artikel 10 Absatz 4 verlangt eine Sicherungskopie über einen DPP-Dienstleister. Erwägungsgrund 38 beschreibt diesen Sicherungsanbieter als unabhängigen Dritten. Der delegierte Rechtsakt soll die Steuerung der Dienstleister konkretisieren, nicht diese Pflichten neu erfinden.

Das aktuelle DPP-Portal der Kommission nennt für den Dienstleister-Rechtsakt das Jahr 2027, führt ihn derzeit aber zweimal auf: einmal im zweiten und einmal im dritten Quartal. Bis die Kommission diese Unstimmigkeit beseitigt oder den Entwurf veröffentlicht, ist das Jahr ein brauchbares Planungssignal, das Quartal hingegen nicht.

Was die Registerverordnung jetzt ergänzt

Die angenommene Registerverordnung regelt das künftige Dienstleisterregime nicht abschließend, beseitigt aber eine wichtige Unklarheit.

• Das Register wird eine Liste verifizierter DPP-Dienstleister führen. Sie sollte nicht als EU-Zertifizierungsliste bezeichnet werden: Die Verifizierung betrifft den Zugang zu Registerfunktionen, nicht die Feststellung, dass sämtliche künftigen Betriebsvorgaben erfüllt sind.
• Ein berechtigter Dienstleister in der Wertschöpfungskette muss verifiziert sein, um Registrierungen anzulegen oder zu ändern. Soweit für eine Registrierung relevant, prüft das Register außerdem den Verweis auf einen Sicherungsanbieter.
• Die Verordnung schafft ein maschinenlesbares semantisches Repositorium mit dokumentierten APIs und gemeinsamen Formaten. Das unterstützt die Interoperabilität; die endgültigen dienstleisterspezifischen Regeln bleiben dem separaten delegierten Rechtsakt vorbehalten.
• Der Wirtschaftsakteur bleibt für die Richtigkeit der DPP- und Registrierungsdaten verantwortlich. Eine verifizierte Plattform kann technische Arbeiten ausführen, ohne diese rechtliche Verantwortung zu übernehmen.

Diese Unterscheidung ist für die Beschaffung wichtig: Fragen Sie, ob ein Anbieter Verifizierung, Versionierung, semantische Interoperabilität und Export unterstützt. Akzeptieren Sie jedoch keine Behauptung eines „EU-zertifizierten DPP-Dienstleisters“, solange ein künftiges rechtliches Zertifizierungssystem sie nicht tatsächlich trägt.

Was bereits aus dem laufenden Prozess sichtbar ist

1. Die Dienstleisterrolle wird von der Produkteigentümerrolle getrennt

Hersteller, Importeure und andere Wirtschaftsakteure bleiben für die Produktkonformität verantwortlich. Die Dienstleisterrolle ist anders: sie betrifft die Infrastruktur, die DPP-Datensätze in der Praxis funktionieren lässt.

Diese Unterscheidung legt nahe, dass die EU klarere Grenzen wünscht zwischen:

• Verantwortung für die Regelkonformität
• Dateneigentum
• technischem Betrieb
• langfristiger Kontinuitätssicherung

Hinweis zum Batteriepass: Die Batterieverordnung verwendet eine andere Konstruktion als die künftige ESPR-DPP-Dienstleisterrolle. Die Kommission bestätigte im Mai 2026, dass sie auf bevollmächtigte Betreiber verweist, die im Namen des verantwortlichen Wirtschaftsakteurs handeln; diese Bezeichnung sollte daher nicht automatisch auf jedes Plattformmodell übertragen werden. Praktisch bleibt der verantwortliche Wirtschaftsakteur für den Batteriepass verantwortlich. Ein bevollmächtigter Betreiber kann technische oder organisatorische Aufgaben in seinem Namen unterstützen, übernimmt diese Verantwortung aber nicht und ist nicht dasselbe Konzept wie ein künftiger ESPR-DPP-Dienstleister.

2. Steuerung wird zur erstrangigen Anforderung

Die Initiative fragt nicht, ob Plattformen sich um Steuerung kümmern sollten. Sie setzt voraus, dass Steuerung wichtig ist, und fragt, welches Modell gelten sollte.

3. Portabilität entwickelt sich zu einer zentralen Designerwartung

Das Konsultationsprotokoll legt nahe, dass DPP-Systeme nicht auf dauerhafte Abhängigkeit von einem Anbieter ausgelegt sein sollten. Offene Strukturen, Exportfähigkeit und Anbieterwechsel-Logik werden als zentrale Plattformthemen sichtbar.

4. Sicherungskopien und Kontinuität sind keine Nebensachen

Die langfristige Verfügbarkeit von DPP-Daten steht im Zentrum der Debatte. Plattformen, die nur auf die aktive Produktanzeige ausgerichtet sind, könnten regulatorische Erwartungen verfehlen, wenn die Kontinuität von Sicherungskopien formalisiert wird.

Vier Gestaltungsbereiche, auf die Plattformen sich vorbereiten sollten

Auch bevor der delegierte Rechtsakt endgültig ist, zeichnet sich bereits ein nützliches Vorbereitungsmodell ab.

1. Klares Dateneigentum und Steuerung-Grenzen

Am besten lässt sich eine Architektur begründen, bei der der Wirtschaftsakteur die Kontrolle über die Produktdaten behält und der Dienstleister die technische Dienstleistungsebene bereitstellt.

Eine seriöse Plattform sollte erklären können:

• Wem die Daten gehören
• Wer sie bearbeiten darf
• Wie Änderungen nachverfolgt werden
• Wie Datensätze exportiert werden
• Was geschieht, wenn die Geschäftsbeziehung endet

Wenn eine Plattform das nicht klar erklären kann, ist sie aus Steuerung-Perspektive bereits schwach aufgestellt.

2. Interoperabilität und Vermeidung von Anbieterbindung

Dies ist der stärkste Konsensuspunkt im Konsultationsprotokoll.

Für Plattformen sollte Interoperabilität kein nettes Extra sein, sondern das zugrunde liegende Modell prägen:

• Identifikatoren sollten portabel bleiben
• Datensätze sollten in einem nutzbaren, strukturierten Format exportierbar sein
• Systeme sollten proprietäre Abhängigkeiten vermeiden, die Migration erschweren
• Ein Anbieterwechsel sollte Unternehmen nicht zwingen, ihre Produktdatenbasis von Grund auf neu aufzubauen

Ein übertragbares Konzept ist die risikoärmere Vorbereitung; die genauen Pflichten beim Anbieterwechsel bleiben jedoch dem delegierten Rechtsakt vorbehalten.

3. Regeln für Sicherungskopien und Kontinuitätsplanung

Die DPP-Dienstleister-Debatte kehrt wiederholt zu Sicherungskopien, Kontinuität und der Frage zurück, was geschieht, wenn der ursprüngliche Betreiber oder Dienstleister verschwindet.

Plattformen sollten bereits in Kategorien denken wie:

• Aktive Bereitstellung gegenüber einem reinen Sicherungsdienst
• Snapshot- oder Kontinuitätskopie-Logik
• Bedingungen für die Datenfreigabe
• Nachvollziehbare Aufbewahrung des letzten gültigen Produktdatensatzes

Nicht jedes Detail ist bereits bekannt, aber die Anforderung, ernsthaft über Kontinuität nachzudenken, besteht bereits.

4. Zugriffskontrolle und Umgang mit vertraulichen Daten

DPP ist nicht nur eine öffentliche Webseite für Verbraucher. Viele DPP-Datensätze werden Datenschichten mit unterschiedlichen Zugriffsrechten enthalten.

Plattformen sollten daher erwarten, Folgendes zu unterstützen:

• öffentliche Verbraucherinformationen
• vertrauliche B2B-Daten
• Zugangsebenen für Behörden
• Nachvollziehbarkeit von Zugriffen und Änderungen

Dies ist eines der deutlichsten Zeichen, dass DPP-Plattformen näher an regulierter Infrastruktur als an gewöhnlichen Content-Management-Tools sind.

Zertifizierung: Was bekannt ist und was nicht

Die Zertifizierung ist eine der größten offenen Fragen in der Debatte über Dienstleister.

Was bereits bekannt ist

• Die Kommission hat ausdrücklich gefragt, ob ein Zertifizierungssystem benötigt wird
• Einige Interessenträger unterstützen eine unabhängige Ex-ante-Zertifizierung nachdrücklich
• Andere bevorzugen flexiblere Modelle
• Sicherheits- und Steuerung-Reife sind als Haupterwartung sichtbar

Was noch nicht bekannt ist

• Ob die Zertifizierung für alle Dienstleister verpflichtend wird
• Welche Stelle Dienstleister bewerten würde
• Ob das endgültige Modell zwischen verschiedenen Anbieterrollen unterscheidet
• Wie aufwendig der Prozess für kleinere Softwareunternehmen sein könnte

Die praktische Schlussfolgerung: Bauen Sie so, als müssten Sie irgendwann strukturierte Steuerung, nachvollziehbare Änderungen, Zuverlässigkeit und Sicherheitsreife nachweisen.

Warum dezentrale Architektur immer wieder auftaucht

Eine der deutlichsten aus den Rückmeldungen erkennbaren Gestaltungspräferenzen ist die Unterstützung für eine dezentrale Steuerung. Interessenträger wollen vermeiden, dass ein Anbieter zum unvermeidlichen, intransparenten Eigentümer der Produktdaten eines Unternehmens wird.

Das bedeutet nicht, dass jeder DPP selbst gehostet oder technisch vollständig verteilt sein muss.

Für Plattformen deutet das auf einen resilienteren Ansatz hin:

• Der Kunde besitzt die Produktdaten
• Der Dienstleister betreibt die Dienstleistungsebene
• Exporte und Portabilität sind normal, nicht die Ausnahme
• Die Kontinuität der Sicherungskopien setzt keine Kontrolle des Anbieters über das gesamte Datenökosystem voraus

Das passt gut zur breiteren EU-Präferenz für offene Standards und interoperable digitale Infrastruktur.

Was Plattformen 2026 aufbauen sollten: noch vor dem endgültigen Rechtsakt

Am nützlichsten sind jene Vorbereitungsschritte, die unter mehreren möglichen rechtlichen Endzuständen wertvoll bleiben.

1. Strukturierte Exporte

Wenn ein Kunde wechselt oder neue Steuerung-Anforderungen erfüllen muss, muss der Datensatz in der Praxis portabel sein, nicht nur in der Theorie.

2. Nachvollziehbare Audit-Historie

Plattformen sollten davon ausgehen, dass die Fähigkeit zu zeigen, wer was wann und auf welcher Grundlage geändert hat, wichtiger wird.

3. Rollenbasierte Zugriffslogik

Auch wenn der endgültige Rechtsakt das Modell verfeinert, ist differenzierter Zugriff bereits eine vernünftige Grunderwartung.

4. Klare Kontinuitätspolitik

Plattformen sollten definieren, was mit Datensätzen geschieht, wenn ein Kundenkonto geschlossen wird, die Dienstleisterbeziehung endet oder Kontinuitätspflichten ausgelöst werden.

5. Offene Architekturentscheidungen

Systeme, die auf offenen Identifikatoren, strukturierten Datensätzen und Migrationslogik basieren, sind besser positioniert als Systeme, die auf Abhängigkeit und Intransparenz setzen.

Was Unternehmen beim Kauf eines Zugangs zu einer DPP-Plattform fragen sollten

Dieser Artikel richtet sich nicht nur an Softwareentwickler. Er richtet sich auch an Hersteller, Importeure und Markeninhaber, die Anbieter bewerten.

Nützliche Fragen umfassen:

• Wie handhaben Sie Dateneigentum?
• Können Datensätze in strukturiertem Format exportiert werden?
• Wie gehen Sie mit Sicherungskopien und Kontinuität um?
• Wie trennen Sie öffentliche und zugangsbeschränkte Daten?
• Wie gestalten Sie Interoperabilität?
• Was geschieht, wenn wir den Anbieter wechseln möchten?

Das sind keine Randfall-Beschaffungsfragen mehr. Sie gehen direkt an den Kern der Frage, wie glaubwürdig die DPP-Architektur eines Anbieters wirklich ist.

Strategische Schlussfolgerung

Der endgültige delegierte Rechtsakt für DPP-Dienstleister steht noch bevor. Aber die Design-Richtung ist bereits deutlich genug, um praktische Entscheidungen zu unterstützen.

Das wahrscheinlich resilienteste DPP-Plattformmodell basiert nicht auf Intransparenz, proprietären Ausstiegsbarrieren und schwacher Kontinuitätslogik. Das stärkere Modell baut auf:

• klarer Steuerung
• exportierbaren, strukturierten Datensätzen
• Interoperabilität
• rollenbasiertem Zugriff
• verlässliche Verfahren für Sicherungskopien und Kontinuität

Unternehmen müssen nicht warten, bis jedes technische Detail festgelegt ist, um diese Kriterien bereits anzuwenden.

Weiterlesen

• Wer darf einen DPP betreiben? EU-Regeln für Dienstleister
• Was ist ein Digitaler Produktpass (DPP)?
• DPP-Datenanforderungen: Welche Daten Sie wirklich brauchen
• ESPR-DPP-Umsetzungsstatus 2026

Offizielle Quellen

• Initiative der Europäischen Kommission: Digitaler Produktpass: Regeln für Dienstleister
• Antwort der Kommission an das Parlament E-000888/2026(ASW): Batteriebetreiber und ESPR-DPP-Dienstleister
• ESPR-Verordnung (EU) 2024/1781
• Durchführungsverordnung (EU) 2026/1778 (DPP-Register)
• Europäische Kommission: DPP-Register
• Europäische Kommission: DPP-Portal und indikativer Zeitplan
• Have Your Say-Portal der Europäischen Kommission

---

Wenn DPP-Plattformen auf strengere Anforderungen an Steuerung, Übertragbarkeit und Kontinuität zusteuern, ist es sinnvoll, mit einem Betreiber zusammenzuarbeiten, der diese Entwicklungen von Anfang an verfolgt. OriginPass behandelt Produktdaten als strukturierte, übertragbare Infrastruktur, nicht nur als Passseiten in einer Benutzeroberfläche.