DPP Registry vs Decentralized Data: What the EU Registry Stores

Status as of June 2026: The EU DPP registry must be established by 19 July 2026 under ESPR Article 13. The regulation fixes the deadline and the minimum content (unique identifiers and data carriers), but the detailed data fields, any public API and the onboarding flow are still being specified by the Commission. This article explains the confirmed architecture, not unpublished technical internals, and will be expanded as implementing acts and specifications are published.

The Two-Minute Version

The EU is not building one giant database that stores every Digital Product Passport. Under ESPR Article 13, the European Commission must set up a registry by 19 July 2026, but that registry is an index, not a warehouse. It records the unique identifiers and data carriers needed to find a passport. The actual product data stays decentralized, held by the economic operator (the manufacturer or importer) or by a DPP service provider acting on its behalf.

This distinction matters because the wrong mental model leads to wrong decisions. If you assume a central database, you plan to upload everything to Brussels. If you understand the real model, you plan to keep control of your own structured data and connect it to the registry through identifiers. The second model is the one the regulation actually describes.

What the Registry Is, and What It Is Not

Article 13 ESPR gives the registry a narrow, specific job. The Commission must store, at minimum, the unique identifiers (defined under Article 12) and the data carriers (Article 10) that let a passport be located and connected to its product. The first version is being stood up for the battery passport, with broader product coverage added over time.

What the registry is not:

• It is not a public database of all passport content.
• It is not where consumers read product information, which is the role of the data carrier and, where provided, the web portal.
• It is not your data storage. Your structured product records stay with you or your provider.
• It is not a substitute for the passport itself. The passport lives behind the data carrier, not inside the registry.

The safe reading today is that the registry covers at least identifiers and carriers, with any further scope defined later by implementing acts and technical specifications.

Four Layers People Confuse

Most confusion comes from collapsing four distinct things into one word. ESPR keeps them separate, and so should your architecture.

Layer	ESPR basis	What it holds	Who runs it
Data carrier	Article 10	The scannable link, such as a QR code, on the product, packaging or documentation	You, the economic operator
The passport (product data)	Article 9	The actual structured product data, kept decentralized	You or your DPP service provider
The registry	Article 13	An index of unique identifiers and data carriers	The European Commission
The web portal	Article 14	A public access point to search and compare DPP data	The European Commission

A fifth element, the DPP system (Article 11), is the set of technical design and operation rules that make these layers interoperate. It governs how the passport works, not where the data physically sits.

Why the Product Data Stays Decentralized

The decentralized model is a deliberate design choice, not an accident of timing. The economic operator remains responsible for the product and its passport, so the operator keeps control of the underlying data. The registry connects to that data through identifiers; it does not absorb it.

Industry feedback to the Commission has been strongly in favour of this model. Large manufacturers and data-space initiatives argued that a central content database would create a single point of failure, lock-in risk and confidentiality problems. The consistent recommendation was that external providers should act as an interoperability and hosting layer, while the operator retains ownership and control of the data.

For companies, the practical takeaway is simple: build structured, exportable, standards-based product records that you control, and connect them to the registry through open identifiers. That keeps you portable between providers and aligned with how the regulation actually works.

The Backup Copy: Continuity Without Centralization

Decentralization raises a fair question: what happens if a provider disappears? ESPR answers it with a backup copy requirement. A copy of the passport must remain available through an independent third party, so the data survives if the original economic operator ceases to exist or a provider fails.

This is continuity, not centralization. The backup is a safety net for authorities and the value chain, released under defined conditions such as insolvency or cessation, not an open mirror of all passport data. The detailed rules for service providers and backups are expected in a dedicated delegated act, with adoption foreseen for late 2026.

How the Standards Encode This Architecture

The horizontal DPP standards from CEN/CENELEC JTC 24, published as EN standards in May 2026, map almost directly onto the layers above. They define the framework, not the data fields of any specific sector.

Standard	Scope	Architectural role
EN 18219	Unique identifiers	How a product, operator and passport are identified
EN 18220	Data carriers	How a carrier resolves to the correct passport
EN 18221	Data storage, archiving and persistence	How decentralized data stays available over time
EN 18222	APIs for lifecycle and search	How systems create, update and find records
EN 18223	System interoperability	How different systems understand the same data
EN 18216	Data exchange protocols	How data is transmitted between parties

Editorial update, 16 July 2026: the references to these six standards were published in the Official Journal on 15 July 2026 by Commission Implementing Decision (EU) 2026/1736. A DPP conforming to a standard benefits from a presumption of conformity with ESPR Articles 10 and 11 only to the extent covered by that standard. What Decision 2026/1736 changes →

Publication as an EN standard was the first milestone; publication of the references in the Official Journal gave those six standards the effect set out in ESPR Article 41(2). Two further standards, on access-rights management and on data authentication, remain outside the package published by Decision 2026/1736.

The Draft Registry Implementing Regulation

The Commission has published a draft implementing regulation laying down the implementation arrangements for the registry under Article 13 (reference Ares(2026)4424976). Its public feedback period ran from 29 April to 27 May 2026 and is now closed, with 222 submissions received. As of June 2026 the act is not yet adopted and has not appeared in the Official Journal, so the points below come from the draft and may change before adoption.

The draft is the first text to describe concrete registry mechanics, and several points matter for how companies will connect:

• Verified economic operators. Creating or modifying a registry entry is restricted to operators whose identity has been verified at the eIDAS assurance level “high”, for example through qualified electronic seals or qualified electronic attestations of attributes.
• Re-verification cycle. Verified status is not permanent. It expires after a maximum of three years, so operators have to re-verify periodically.
• Automated conformity checks. The registry runs automated semantic checks before accepting an entry, rather than storing arbitrary data.
• Decentralised by design. Consistent with the architecture above, the registry holds identifiers, verification records and audit logs, while the passport content stays with the operator.

These rules reinforce the practical advice in this article: keep ownership of structured, exportable data, use open identifiers, and plan for an identity-verification step, and its renewal, for the moment the registry connection becomes mandatory.

Who Actually Reads the Registry

The registry is built for verification, not for consumer browsing. Customs and market surveillance authorities are the primary users: they need a reliable way to confirm that a product entering or circulating in the EU has a valid passport, and to reach the right data through its identifiers.

This is why the registry connects to enforcement infrastructure rather than to a marketing front end. Consumers reach product information by scanning the data carrier; authorities use the registry and the identifiers behind it. Keeping these audiences separate is part of the design.

What Is Still Being Specified

An honest explainer has to mark the edges of what is confirmed. As of June 2026, the following are not yet fixed in public detail:

• The exact data fields the registry will store beyond identifiers and carriers.
• Whether a public API, beta environment or full onboarding flow will be available on 19 July 2026. The Article 13 deadline is a legal establishment date, not a promise of a finished public interface.
• The scope and timing of the web portal under Article 14.
• The final requirements and any certification scheme for DPP service providers, expected in a delegated act later in 2026.

We will expand this article as those acts and specifications are published. The architecture above is stable; the technical internals are not yet public.

What to Do Now

• Keep ownership of your data: store structured product records you can export, not data locked inside one provider.
• Use open identifiers: a GS1 Digital Link style identifier keeps your carrier portable and registry-ready.
• Separate the layers in your own systems: carrier, passport data, identifiers and access rights are distinct concerns.
• Ask providers the right question: not “do you store my data” but “can I export it and switch without breaking my QR codes”.
• Plan for backup and continuity: understand how your provider handles the mandatory backup copy and data release conditions.
• Track the implementing acts: registry detail, the web portal and service-provider rules will arrive through later acts.

FAQ

Is the EU DPP registry a central database of all product data?

No. Under ESPR Article 13 the registry stores at least the unique identifiers and data carriers needed to locate a passport. The product data itself stays decentralized with the economic operator or its DPP service provider. The registry is an index, not a warehouse.

What actually happens on 19 July 2026?

That is the legal deadline for the Commission to establish the registry, with the first version aimed at the battery passport. The date fixes establishment, not a guarantee that a full public API, beta or onboarding flow is available on that day.

Where does the actual passport data live?

With the economic operator or a DPP service provider acting on its behalf. The data carrier on the product resolves to that decentralized record. ESPR also requires a backup copy through an independent third party for continuity.

What is the difference between the registry and the web portal?

The registry (Article 13) is an index of identifiers and carriers used mainly by authorities. The web portal (Article 14) is a public access point to search and compare DPP data. They are separate elements with separate purposes.

Does decentralized data mean I am locked into one provider?

It should mean the opposite. If you keep structured, exportable records and use open identifiers such as GS1 Digital Link, you can switch providers without re-issuing your data carriers. Vendor lock-in comes from proprietary formats, not from the registry.

Do I upload my passports to the Commission?

You register the identifiers and carriers needed to connect to your passport, not the full content of every passport. The detailed registration mechanics will be set out in implementing acts and technical specifications.

Read Next

• EPREL vs the DPP Registry: How the Two EU Registries Connect
• What Is a Digital Product Passport?
• What Data Goes Into a DPP? Complete Data Requirements
• DPP Service Provider Requirements Explained
• GS1 Digital Link for DPP
• Common Specifications: The EU’s Fallback Plan for DPP Standards
• ESPR DPP Implementation Status 2026: Standards, Registry, Gaps

Official Sources

• ESPR Regulation (EU) 2024/1781, Article 13
• European Commission: Implementing the ESPR
• CEN/CENELEC JTC 24: published DPP EN standards
• Commission answer E-000888/2026(ASW): JTC 24 standards and DPP registry status
• DPP service providers: delegated act initiative

---

Building DPP records you actually control? Start free on OriginPass.eu and keep ownership of your structured product data, registry-ready and portable by design.