EU Commission Consults Draft Regulation for Central DPP Registry

Background: Why a Central Registry for Digital Product Passports?

The Digital Product Passport (DPP) is the cornerstone of the European Ecodesign for Sustainable Products Regulation (ESPR), which has been in force since July 2024. It requires manufacturers to provide machine-readable data records for a growing number of product categories — from batteries and textiles to electronics. But where do the references to these records actually live? That is precisely what the new implementing regulation addresses.

On April 29, 2026, the European Commission published a draft Implementing Regulation on the DPP Registry, which is now open for public consultation. The document describes how a centralized registry will store unique product identifiers and link them to product data hosted in a decentralized manner. This is not a database of the product data itself — it is a directory of references.

This architectural choice is deliberate: the EU does not want to create a monolithic data silo, but rather an interoperable network of manufacturer systems that can be discovered through a shared central node.

What the Draft Actually Requires

Structure: Central Registry, Decentralized Data

The core principle of the draft is clear: the Registry stores only unique identifiers (UIDs) and the associated resolver endpoints — that is, the URLs where the actual DPP data can be retrieved. The product data itself remains with the manufacturer or a designated data operator.

This model is conceptually closely aligned with GS1 Digital Link, the open standard that connects GTINs with structured web URIs. A scanner or a market surveillance authority can use the central registry entry to locate the responsible resolver and retrieve the complete passport data from there.

Registration Obligations for Economic Operators

The draft establishes that manufacturers and importers are required to register their products in the registry before placing them on the market. Specifically, they must:

submit the unique product identifier (UID),
provide the resolver endpoint (URL) at which the DPP can be accessed,
supply metadata on the product category and the responsible economic operator.

Registration is to be carried out via a standardized API, the technical specification of which is still being developed by ECLASS and other standards bodies. The draft references the ongoing work of CEN/CENELEC JTC 24, which is tasked with harmonizing the data models.

Access Rights and Data Protection

One of the central points of contention in the consultation will likely be the question of who may access which registry data. The draft distinguishes three classes of actors:

Actor	Read Access	Write Access	Notes
Public / Consumers	Resolver URL, product category	No	No commercially sensitive trade data
Market Surveillance Authorities	Full entry including metadata	No	Uniform across the EU
Economic Operators (manufacturers, importers)	Own entries	Yes	Authentication via EU Login

Commercially sensitive information — such as supplier relationships or purchase prices — is explicitly not to be stored in the Registry. For that, the draft points to the option of defining access levels (Access Rights) within the DPP itself, as already provided for in the ESPR Delegated Regulation for Batteries.

Technical Implications for Manufacturers and IT Service Providers

API Integration and Bulk Registration

For companies with large product portfolios, the question of bulk registration is critical. The draft outlines a REST API through which UIDs can be submitted in batches. A simplified example of how such a registration call might be structured:

POST /registry/v1/products
Content-Type: application/json
Authorization: Bearer <EU-Login-Token>

{
  "uid": "https://id.gs1.org/01/04012345678901/21/ABC123",
  "resolverEndpoint": "https://dpp.example.com/resolver",
  "productCategory": "ESPR:TextileUpperGarment",
  "economicOperator": {
    "eori": "DE123456789",
    "name": "Muster GmbH"
  }
}

The UID itself must conform to a recognized identification system — the draft explicitly names GS1 GTINs as well as ISO/IEC 15459-compliant codes. Proprietary systems are permitted, but must be globally unique and permanently resolvable.

For companies already working with tools like qr3.app Bulk Import, the underlying principle does not change significantly: a structured CSV or JSON delivery of UIDs and resolver URLs can be mapped to the Registry API. The real challenge lies in governance — who within the organization is responsible for maintaining entries when resolver URLs change or products are withdrawn from the market?

Lifecycle Management: Recalls and Archiving

The draft also addresses the product lifecycle after market placement. Manufacturers are required to update registry entries when:

the resolver endpoint changes,
the product is recalled (the entry must then be marked as "recalled" but not deleted),
the company is dissolved or transferred.

The archiving obligation is set at at least 10 years after the last time the product was placed on the market — a requirement that poses a particular challenge for SMEs without their own IT infrastructure.

Timeline and Next Steps

The public consultation on the draft is expected to run until the end of June 2026. Comments can be submitted via the EU Have Your Say portal. The Commission has signaled its intention to adopt the final implementing regulation before the end of 2026, in order to align with the first product-specific ESPR delegated regulations — most notably for textiles (planned for 2027).

For the Batteries Regulation, which has been binding since February 2024, a special arrangement applies: the Battery Passport system initially operates through a separate mechanism, but is intended to be integrated into the central Registry in the medium term.

What Companies Should Do Now

Even though the regulation is not yet final, there are preparatory steps you can take today:

Define your UID strategy: Decide whether to rely on GS1 GTINs or an alternative system. GS1 Digital Link has the advantage that the identifier simultaneously functions as a resolvable web URI.
Build your resolver infrastructure: The resolver endpoint must be permanently accessible and versioned. Use stable base URLs — not dynamic short URLs.
Define data maintenance processes: Who in your organization is responsible for registry updates when products change or are recalled?
Monitor the consultation: The final regulation may differ from the draft — particularly regarding API specifications and access rights.

Assessment: What the Registry Does — and What It Doesn't

The central DPP Registry is not a quality certificate or a conformity assessment. It is a directory service — comparable to a DNS for product identifiers. The accuracy of the DPP data remains the responsibility of the economic operators and is verified by market surveillance authorities.

Industry critics — including BusinessEurope — have already noted that the dual structure of a central registry and decentralized data storage increases compliance costs without meaningfully improving data protection. Proponents, including environmental organizations such as the European Environmental Bureau, argue in turn that only a central entry point can ensure enforceability by authorities.

The consultation phase will reveal whether the Commission holds to the hybrid architecture or makes adjustments. For companies beginning their technical preparations now, the key takeaway is this: the fundamental principles — unique identifiers, stable resolvers, structured metadata — will remain valid regardless of the final regulatory text.