DPP Registry vs Decentralized Data: What the EU Registry Stores
EU DPP Registry rules are adopted: what it stores, why passport data remains decentralized, and how API, verification and versioning work.
Status as of 22 July 2026: the Commission has opened the production Registry and separate testing environment and published the Economic Operators User Guide v1.0. The Commission describes the Registry as operational and registration as available through a secure interface or API. Testing requires a separate EU Login and the same valid organisation data and qualified signature or seal used for production verification. Product-specific testing, including for batteries, still depends on the applicable semantic catalogue and sector rules. Regulation (EU) 2026/1778 enters into force on 6 August 2026.
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. Implementing Regulation (EU) 2026/1778 makes its role concrete: it is a central index and verification layer, not a warehouse for the full passport. It registers identifiers, where relevant commodity codes, and high-level registration data; the actual product data stays decentralized, held by the economic operator or its DPP service provider.
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
ESPR Article 13 requires the Commission to store the unique product identifiers and commodity codes necessary for customs use. Regulation 2026/1778 specifies the operational record: the product identifier, where relevant the commodity code and service-provider reference, the identity of the registrant, registration date and integrity information. It also creates a unique registration identifier for each registration.
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 full-passport 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 Commission describes the registry as storing unique identifiers, registration data and high-level metadata, not all detailed DPP content. The applicable product rule still determines which DPP data must exist and at what level it must be issued.
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 | ESPR Article 13 + Regulation 2026/1778 | Registration identifiers, product identifiers, commodity codes where relevant, and high-level registration data | 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 Article 10(4) answers it with a backup-copy requirement through a DPP service provider. Recital 38 describes that backup provider as an independent third party. Keeping the operative rule and the recital separate matters: the backup duty is binding, while the recital explains the intended continuity model.
This is continuity, not centralization. The backup supports continued availability after events such as insolvency, liquidation or cessation of activity; it is not an open mirror of all passport data. The detailed continuity and access arrangements follow the applicable product act and future provider rules. A separate delegated act on DPP service providers and any certification scheme remains to come; Regulation 2026/1778 does not replace it.
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 Registry Implementing Regulation Is Now Adopted
Regulation 2026/1778 turns the former draft into binding horizontal registry rules. Its most practical effects are these:
- Verified operators and value-chain actors. Only verified actors can register or modify a DPP where the applicable Union law allows them to act. Verification uses the eIDAS-based routes set out in Articles 4 and 5; its validity ends when the credential expires and in any event after three years. Until re-verification, the actor cannot create or change registrations.
- Model, batch or item registration. The registry must register a DPP at the level required by the product-specific rule. Where more than one Union act applies, the most granular level applies. Item-level records must link to the relevant batch or model identifiers where those exist.
- Interface and API. Registration can be made through the secure web interface or the API. The act legally requires both channels, but it does not itself publish endpoint URLs, credentials or payload examples.
- Automated technical checks. Before registration, the system checks semantic conformity, consistency between required registry data and the DPP, granularity and, where relevant, commodity-code validity and the reference to a backup DPP service provider. This is a technical registration check, not a determination that the product complies with all substantive EU product law.
- Versioning and evidence. Every creation, modification, deletion and status change is logged. Registry data is versioned and time-stamped; the default retention period is ten years unless another Union act provides otherwise. Once generated, a signed proof of registration remains available for 90 days and may be generated again.
- Semantic repository and provider list. The Commission must operate an authoritative, machine-readable semantic repository with documented APIs and common formats, and a list of verified DPP service providers. “Verified” here concerns registry identity/access status; it is not the future provider certification scheme.
The rules reinforce the practical advice in this article: keep ownership of structured, exportable data, use interoperable identifiers, and plan for identity verification and renewal when registry connection becomes mandatory for your product.
Who Actually Reads the Registry
The registry is built for registration and verification, not as the main consumer-browsing interface. Verified economic operators and eligible value-chain actors use it to create or maintain registrations; competent and customs authorities use it to verify records and reach the relevant DPP data through identifiers.
This is why the registry combines registrant and authority workflows rather than acting as a marketing front end. Consumers normally reach accessible product information by scanning the data carrier, while the Article 14 web portal is the separate public search-and-comparison layer. Keeping these functions distinct is part of the design.
What the Regulation Does Not Settle
An honest explainer still has to mark the boundary between law and implementation material. Regulation 2026/1778 does not itself set:
- the product-specific DPP fields, access rights or applicable registration level for every sector;
- a public endpoint catalogue, authentication implementation, payload examples or onboarding instructions for the API;
- a universal requirement to register every product immediately;
- the final service-provider delegated act or a provider-certification scheme.
The production Registry, separate test environment and Economic Operators User Guide went live on 20 July. The guide documents organisation enrolment and form/file submission workflows, while the Commission’s launch announcement states that registration is available through the secure interface or API and that technical documentation and a semantic repository are available. Companies should test the current product-specific models, particularly for batteries, while treating the regulation and the applicable sector rules as the legal baseline.
What to Do Now
- Keep ownership of your data: store structured product records you can export, not data locked inside one provider.
- Use interoperable identifiers: GS1 Digital Link is one practical option, not the only legally permitted route.
- 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 verification and versioning: identify who will register, how it will authenticate, and how your platform will preserve an auditable revision history.
- Plan for backup and continuity: understand how your provider handles the backup link where the applicable product rule requires one.
- Track product-specific acts: they decide when registration applies and what the DPP must contain.
FAQ
Is the EU DPP registry a central database of all product data?
No. It stores registration identifiers, product identifiers, commodity codes where relevant, and high-level registration data. The product data itself stays decentralized with the economic operator or its DPP service provider. The registry is an index and verification layer, not a warehouse.What actually happened in July 2026?
The Commission adopted Regulation (EU) 2026/1778 on 16 July and published it on 17 July. It enters into force on 6 August. On 20 July, the production Registry, separate testing environment and implementation resources became available. The Commission describes the Registry as operational and registration as available through a secure interface or API; product-specific use still depends on the applicable semantic catalogue and sector rules.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 Article 10(4) also requires a backup copy through a DPP service provider; Recital 38 describes that provider as an independent third party.What is the difference between the registry and the web portal?
The registry (Article 13) is the central registration, indexing and verification layer used by economic operators and 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 reissuing your data carriers. Dependence on one provider comes from proprietary formats, not from the registry.Do I upload my passports to the Commission?
Not the full content of every passport. You register the required registry information, including identifiers and, where relevant, the commodity code, through the interface or API. Product-specific law determines the DPP content and registration level.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
- Commission Implementing Regulation (EU) 2026/1778 (DPP Registry)
- European Commission: DPP Registry
- European Commission: DPP Registry production and testing environments
- DPP Registry User Guide for Economic Operators v1.0 (PDF)
- Commission Implementing Decision (EU) 2026/1736 (DPP standards)
- European Commission: Implementing the ESPR
- CEN-CENELEC: first DPP standards and their status in the EU Official Journal
- 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.