technology

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.

6/10/2026 · 9 min read · InfoDPP

Reviewed on 9 October 2026. The Registry has been open since July and its common rules are set out in Regulation (EU) 2026/1778. The user guide v1.03 of 16 September described battery registration as dependent on a semantic catalogue that was not yet defined. The September FAQ and webinar provide further battery guidance and planned publication dates. This statement does not establish whether battery registration is available today. Registry User Guide v1.03; EU Registry and testing environment.

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 affects how companies prepare. Rather than uploading all product data to a central database, companies need to maintain their own structured records and connect them to the registry through identifiers.

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 data carrier provides access to the passport, which is not stored in 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

ESPR distinguishes four elements. Keeping them separate in your systems makes it easier to assign responsibility for each one.

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 is stored.

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.

Decentralized hosting still needs safeguards for availability, export, continuity and confidentiality. When assessing a provider, check who controls the data, how it can be moved to another system and what happens if the hosting service stops.

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.

The purpose is continued availability, not centralised storage. 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.

Keep control of your product data and store it in a structured form that you can export. Use identifiers that work across systems. Prepare for identity verification before registration becomes mandatory for your products, and plan for renewal.

What the September battery guidance adds

For batteries, creating and maintaining the passport means managing its data. Registration is the separate submission of the required information to the EU Registry. The September FAQ, questions 2.1 and 6.5, confirms that the full battery passport stays with the responsible operator or an operator authorised in writing. The Registry holds registration information and metadata.

The same FAQ explains how restricted battery data will be handled. The forthcoming act under Article 77(9) is intended to define legitimate interest, access and permitted use of the data. It will not provide a central authentication mechanism for repairers or recyclers. The operator hosting the battery passport manages that access. Question 7.6 also says that fields not yet applicable are absent from the active battery data model and can be introduced in a later version. These explanations are published for batteries. They should not be presented as a completed access or data model for other sectors.

At the 30 September battery webinar, the Commission announced technical specifications for battery semantics and data formats for the end of October 2026. Registry API integration guidelines were planned for the end of December. These are announced publication dates, not legal deadlines or confirmation that all product groups can already be connected. Check the actual specifications before designing an integration around their contents.

Verification renewal has a broader legal basis. Articles 4 and 5 of Regulation (EU) 2026/1778 limit verified status to the expiry of the identification means or three years, whichever comes first, for the actors covered by those provisions. The battery FAQ repeats that rule. Expiry prevents further registrations or changes to Registry data until verification is repeated; this is distinct from editing the passport held in the operator’s own system.

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.

The registry serves operators registering passports and the relevant authorities. Consumers normally reach accessible product information by scanning the data carrier. Article 14 provides for a separate public web portal for searching and comparing passport data.

What the Regulation Does Not Settle

The regulation sets legal requirements; implementation guidance explains how to use the system. 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 User Guide v1.03 adds (16 September 2026)

The September version of the guide does not change the legal picture, but it clarifies several practical requirements for using the Registry:

Battery registration in the September guide. Version 1.03 states that registration requires a battery semantic catalogue that had not yet been defined. The guide describes the situation on 16 September. It does not establish whether registration is available today.
Unique product identifier. The UPI is mandatory, must be a URL starting with https:// in a format compliant with the JTC 24 standards, and may be up to 2000 characters long; model and batch identifiers are optional, and only the item level is currently available for batteries.
Organisation identifiers. A legal person should preferably use its national trade register number, with LEI, VAT number, eID or a national local identifier as alternatives; a natural person should preferably use a tax identification number. The value must match the attribute in the sealing certificate exactly.
Qualified seal or signature. The sealed PDF declaration must be countersigned with a qualified seal (legal person) or a qualified signature (natural person) created on a qualified device or via a qualified remote signing service. A qualified certificate installed as a software file produces only an advanced signature and is rejected; Adobe Acrobat users must set the default signing format to CAdES-Equivalent, and only PAdES Baseline B, T, LT or LTA is accepted.
Commission signing and validation tools. The guide points to the Commission’s free DSS tools to sign locally and to validate the file before upload; the validation result must show QESeal or QESig, not AdESeal-QC or AdESig-QC.
File rules. The organisation-verification declaration must be a PDF, at most 1 GB, with a file name of up to 100 characters. DPP batch submissions are a separate workflow using XML or JSON with at most 100 records; one invalid record rejects the batch.

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.
Check portability: ask whether you can export your data and change providers without breaking existing QR-code links.
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 entered 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.

Can I already register a battery passport in the Registry?

The user guide v1.03 of 16 September 2026 described successful battery registration as dependent on a semantic catalogue that was not yet defined. At the 30 September battery webinar, technical specifications were planned for the end of October. These documents do not establish the Registry’s live availability today. Check the current battery specifications, testing environment and helpdesk before planning a registration. Organisation verification and passport registration remain separate steps.

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?

Portable data and open identifiers can help, but do not alone guarantee that a provider can be changed without replacing codes. Control of the domain, resolver configuration and contractual continuity must also be preserved.

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.

Official Sources

Start preparing for DPP by organising the data for one product. Try OriginPass.eu to see how you can present it in a digital passport.

Continue Reading

Related guides