The EU DPP Registry, demystified

On 19 July 2026, the EU Central DPP Registry went live — and with it, the most misunderstood component of the whole Digital Product Passport system moved from slideware to production.

The misunderstanding usually runs in one of two directions. Either teams believe the registry stores their product data (it doesn't, and confidentiality worries follow), or they believe it is someone else's problem (it isn't — registration duties sit with the economic operator). Let's take it apart properly.

What the registry is — and what it is not

The ESPR (Article 13) requires the Commission to run a central registry storing, for every product with a passport, the unique identifiers and a defined set of metadata. Think of it as a card catalogue for the entire single market:

• The unique product identifier (and where applicable, unique operator and facility identifiers)
• The product's commodity classification
• A pointer to where the passport itself resolves
• Compliance-relevant flags authorities need for lookups

What it explicitly does not store: your bill of materials, supplier tiers, carbon models, state-of-health telemetry, or any of the substantive passport content. That data stays in your (or your provider's) decentralised storage. The EU deliberately chose a federated architecture — a central index over distributed data — for scalability and confidentiality reasons.

Who must register, and when

The registration duty attaches to the economic operator placing the product on the market — manufacturer or importer — before the product is placed on the EU market. In sequence:

• Now → Feb 2027: battery passports are the first mandatory wave. Packs shipping from 18 February 2027 must have registry entries before they ship.
• 2028+: textiles and further ESPR categories join as their delegated acts activate, using the same registry and the same mechanics.
• Customs linkage: the registry is designed to interoperate with customs systems — the medium-term goal is that import declarations can be checked against registry entries, making an unregistered product visible at the border, not just during market surveillance.

In practice, your DPP platform performs the registration technically (ours syncs automatically at minting), but the legal responsibility cannot be outsourced. Put the sync obligation in your platform contract and audit it.

What actually happens at registration

The flow, stripped of ceremony:

1. Mint — a passport is created with its unique identifier (for us: a GS1 Digital Link built on your GTIN + serial or batch).
2. Submit — identifier plus required metadata goes to the registry via its machine interface.
3. Acknowledge — the registry returns a registration confirmation; store it, it is your evidence of compliance.
4. Maintain — lifecycle changes that affect registry metadata (a passport withdrawn, an operator change, a resolver migration) must be reflected. The entry is not fire-and-forget.

The registry also underpins authority access: market surveillance bodies use it to look up any product's passport from its identifier, without needing to know which vendor hosts it. One lookup surface for 27 member states.

The three questions to ask your platform provider

1. "Is registry sync automatic, and where is my acknowledgement receipt?" Registration evidence should be a queryable field on every passport record, not a quarterly export someone emails you.
2. "What happens to registry entries if we terminate the contract?" The correct answer involves migrating resolver pointers, not deleting entries. Anything that sounds like "the entries lapse" is disqualifying.
3. "Who handles a registry schema change?" The registry's technical specifications will evolve — the Commission has been explicit that the battery wave is a learning deployment. Schema evolution should be the platform's job, invisibly.

What July 2026 changed in practice

Since go-live, three things stopped being theoretical:

• The metadata schema is now concrete. Data models can be validated against a real interface instead of draft specifications — which surfaced gaps in more than one "ready" implementation, ours included (we shipped a schema patch in week two; that is what learning deployments are for).
• Registration became a launch-blocking step. Battery programmes shipping in early 2027 now sequence registry sync into their go-live checklists, right next to artwork freeze. Our data collection playbook covers where it sits in the calendar.
• The border story got real. With a live registry, the customs-interoperability roadmap moved from concept to integration planning. Importers should assume that by the end of the decade, "no registry entry" reads as "no market access" at the point of entry.

Registry, resolver, passport: three layers people conflate

A surprising number of compliance discussions go sideways because three distinct components get blended into one mental "database in Brussels". Keep them separate:

• The passport is the data record itself — the materials, footprints, events. It lives in decentralised storage operated by you or your platform provider. It is the thing consumers and recyclers actually read.
• The resolver is the routing layer that turns the identifier printed on the product (typically a GS1 Digital Link) into the right passport view for the right audience. It is operated by whoever runs your DPP infrastructure — and its domain should be governed by you.
• The registry is the Commission's central index of identifiers and metadata. It points at your resolver; it never replaces it.

A scan by a consumer never touches the registry at all — phone → resolver → passport. An authority lookup starts at the registry precisely because the authority has only the identifier and needs to find your resolver. Once the three layers are distinct, the compliance questions sort themselves: availability is a resolver/passport obligation, registration is a registry obligation, and identifier uniqueness underpins all three.

Common questions, short answers

• "Do we pay to use the registry?" No — it is Commission-operated public infrastructure. Your costs sit in the passport and resolver layers.
• "Can consumers search the registry?" The registry serves authorities and customs first. Public product lookup happens through the passport itself; a public web portal for basic passport discovery is on the roadmap but is not the primary interface.
• "We sell through distributors — who registers?" Whoever places the product on the EU market. For imports, that is typically the EU importer of record, not the overseas manufacturer — align this contractually before the first shipment, not after.
• "What if we change DPP providers?" Registry entries update to point at the new resolver. This is routine if your identifiers are portable — one more reason the identifier decision outranks every other technology choice.

The quiet significance

It is easy to read the registry as bureaucratic plumbing. It is better understood as the EU making product identity a piece of public infrastructure: one namespace, one lookup surface, federated data behind it. Every passport across every category — batteries this year, textiles next, furniture and steel after — hangs off the same index.

Get your identifiers and persistence story right once, and every subsequent category your business touches inherits the work. Get it wrong, and you will redo it per category, under worse deadlines.

Unsure what your registry obligations look like for 2027? Book a consultation — we'll walk your products through the registration flow, including a live sync against the sandbox.