The EU DPP Registry: What It Actually Stores, and What It Doesn’t

There is a date on the Digital Product Passport calendar that gets less attention than it should: 19 July 2026. That is the deadline for the European Commission to set up the EU’s central DPP registry, written into Article 13 of the Ecodesign for Sustainable Products Regulation. It is also the part of the system that gets described wrong most often, usually as some giant EU database that will hold all your product information.

It isn’t that. Getting the difference straight is worth a few minutes, because it changes what you need to build, who you can trust to host your data, and how worried you should be about 19 July in the first place.

The EU DPP registry is a directory, not a database

The registry is an index. It records where each product’s passport lives, not what is in it.

Think of it as the phone book rather than the conversation. When a customs officer, a market surveillance authority, or a customer resolves a product’s identifier, the registry’s job is to point them to the right place: your system, or the system of whoever hosts your passport. The actual passport data, the material composition, the carbon figures, the repair information, is served from there, never from the registry itself.

Article 13 is explicit about the minimum. The registry stores, in a secure manner, at least the unique identifiers of the products that have a passport. For goods imported and released for free circulation, it also stores the customs commodity code, so an import can be checked at the border. That is close to the whole of it. Identifiers and pointers, not content.

What does the EU DPP registry store, and what does it leave out?

The registry holds a small set of structured pointers. Your product data is not among them.

What goes in, at minimum:

• The unique identifiers, the globally unique, resolvable IDs that name and register the product. The unique product identifier (the UPI) is the one most people mean; customs also checks a registration identifier against the registry.
• For products imported and released for free circulation, the commodity code used at customs.

That is the floor the regulation fixes. The Commission can specify further fields by delegated act, and the registry is meant to tie data carriers to identifiers, so the exact extended list is still being settled. What does not change is the principle underneath it: identifiers and pointers, not content.

What stays out:

• The passport’s contents. Every attribute a customer or regulator actually reads sits on your host, not in Brussels.
• Anything that would make the registry a single point of failure for the data itself. It points; it does not serve.

This is why “the EU will hold our product data” is the wrong mental model. There is no central store of your passport content. You host it, or you pay a provider to host it, and either way the obligation to keep it reachable stays with you. The persistence standard, EN 18221, is precisely about that duty: how long the data has to stay available, including after a product is discontinued or the company behind it reorganises.

What happens when someone scans a product?

A scan resolves from the data carrier, through the registry’s record of where the passport lives, to the host that serves it. The registry is in that path as a pointer and a checkpoint. It is never where the data itself sits.

The flow is worth walking through once, because it makes the registry’s narrow role obvious:

1. Someone scans the data carrier on the product. It carries an identifier, typically expressed as a resolvable web link such as a GS1 Digital Link URI.
2. The identifier resolves against the registry, which holds the authoritative record of where that product’s passport is hosted. For an authority or a customs officer, the same lookup is where the identifier gets verified as genuine and, for an import, matched against the declared commodity code.
3. The passport data is served from the host, your system or your provider’s, filtered to what that particular viewer is allowed to see.

So the registry never holds the answer to “what is in this passport.” That lives with you, behind your access rules. Its job is to point and to verify, not to deliver.

“Set up by 19 July” does not mean you have to register anything yet

The 19 July 2026 deadline is on the Commission, not on you. For most manufacturers, nothing becomes due that day.

This is the part that causes needless alarm. Article 13 obliges the Commission to have the registry infrastructure set up by 19 July 2026. It does not switch on a registration duty for every product in the EU on the same date. Registration becomes mandatory product group by product group, each tied to its own delegated act and its own compliance date.

Batteries go first. From 18 February 2027, batteries over 2 kWh need a battery passport, and that is the first sector where registering in the central registry actually bites. Textiles follow later, realistically around 2028 once their delegated act and application window have run. Construction sits on a separate track under the Construction Products Regulation, later still. If you make jackets or windows, 19 July 2026 changes nothing operational for you yet. The infrastructure goes live; your obligation waits for your sector.

So the honest read is that 19 July is an infrastructure milestone, not a cliff. Treat anyone selling it to you as an imminent deadline for all products the way you would treat any other manufactured urgency. And keep in mind that EU timelines move. A set-up deadline being on the books is not the same as the registry being fully operational on the day, and it would not be the first European IT deadline to slip.

Who actually checks that you comply?

No single EU body polices the Digital Product Passport. Enforcement is national, and it runs on machinery that already exists.

The ESPR doesn’t create a new passport police. Its enforcement chapter, Articles 77 to 83, plugs into the EU’s Market Surveillance Regulation (EU) 2019/1020, borrowing its definitions of “market surveillance authority,” “customs authorities” and “release for free circulation” wholesale. The same framework that already polices non-food products across the EU is the one that will check passports.

Two layers do the checking, and the registry sits at the heart of one of them:

• Inside the market, national market surveillance authorities inspect products, demand access to passport data, and can order corrective action, withdrawal or recall when something is missing or wrong.
• At the border, customs authorities verify that an imported product’s registration identifier and commodity code match what’s in the registry before releasing it for free circulation. This is the registry’s enforcement role in practice: it is the reference customs check against. A product that doesn’t match can be refused entry.

Penalties are set nationally, not in Brussels. Article 74 requires each member state to make them effective, proportionate and dissuasive, weighing the seriousness of the breach and any economic gain. There is no single EU fine scale, so what non-compliance actually costs depends on where you’re caught.

For a Norwegian manufacturer, the picture is concrete enough already. The law that carries the EU product framework into Norwegian law, the Sustainable Products and Value Chains Act (lov om bærekraftige produkter og verdikjeder), came into force on 1 July 2024. The ESPR itself is EEA-relevant but not yet taken into the EEA Agreement, so it does not formally bind Norwegian producers yet. When it is incorporated, the Norwegian Environment Agency (Miljødirektoratet) is set to take the central supervisory role, with NVE, which already runs ecodesign and energy-labelling supervision, proposed as a market surveillance authority alongside it for the products it covers today. So the regulator that eventually asks to see your passport data is a Norwegian one, not an EU one, and it is shaping up to be Miljødirektoratet, with NVE on the energy side.

The printed code can’t change. What it points to can.

That gap is the strongest practical reason the directory model works in your favour. A QR code, once printed onto a product, is fixed for the life of that product. What sits behind it is not.

When you print a data carrier onto a product, you are committing ink to something you can’t recall from the field. If that code resolved straight and only to one provider’s servers, changing providers would mean reprinting and relabelling every unit already shipped, which at any real volume is not an option. The indirection is what saves you. The carrier holds a stable identifier; the binding between that identifier and where the live passport is served is data, and data can be changed.

So switching DPP provider becomes a pointer update, not a reprint. The code you put on a product two years ago keeps resolving. You change only what it ultimately resolves to.

That is what we’ve built for at DPPA, ahead of the registry going live. The EU registry isn’t operational yet, so nothing routes through it today; in the meantime the codes we generate resolve through our own layer, with the registry part simulated against the spec. The design is ready to cut over to the official registry the day it’s up: the entry we register there will carry the URL of the live passport on our side, and from then on, moving a passport to a different host is a change to that pointer, while the printed code stays exactly as it is. That is the concrete difference between owning your identifiers and renting them.

The catch is that the same mechanism only protects you if you can actually use it. The registry entry points at a host. If that host is a platform you do not control, and the entry can’t be moved when you change provider, the indirection that should free you becomes a tether instead. Your identifiers resolve to someone else’s system, and switching means untangling who owns what.

So the questions to put to any DPP vendor before you sign are concrete ones:

• If we leave, can we take our unique product identifiers with us, or are they minted in a scheme only you control?
• Can the registry entry be repointed to a different host without re-registering every product?
• Where exactly is the passport data stored, and can we export it in full, in a structured format?

A provider building against the standards answers those in a sentence. One that hedges is telling you something about the exit cost.

Want straight answers to those three questions for your own products? DPPA gives you unique identifiers you own and a registry entry you can repoint, so you can switch hosts without reprinting a single code. Get in touch.

What should you do before 19 July?

You do not need to wait for your sector’s rules to use this date well. Use it as a dry run.

One question gets you most of the way there: starting from an identifier you actually control, can someone resolve their way to current, structured data about your product? Not a PDF, not a spreadsheet emailed on request, but data served on demand from a system, the way the registry will expect. If the answer is no, you have just found your real gap, and you have found it with time to spare rather than under a 2027 deadline.

The work that gets you there is the work that pays off regardless of which sector you are in: clean, item-level product data, an identifier scheme you own, and a host you can repoint. None of that gets overturned when your delegated act finally lands. It is the safe place to start, and 19 July is a good reason to start now. For the wider checklist of what to do before the first deadlines, see our practical guide to DPP implementation before 2027.

FAQ

Trying to work out what 19 July actually means for your products, rather than what a vendor’s deadline email says it means? That is most of what we do. DPPA builds Digital Product Passport infrastructure for manufacturers, with a focus on item-level product data and identifiers you own and can move. We sit on Standard Norge’s DPP committee, SN/K 624, the Norwegian mirror of the CEN-CLC/JTC 24 group writing the standards behind the registry, so we have been building against them as they were drafted. If you want a straight answer on where your products stand, get in touch.

For the wider picture of what is built and what is still missing in mid-2026, see DPP in Mid-2026: What’s Actually Built, What’s Still Missing.