The EU DPP Registry is an index, not a database

Most teams picture the EU registry for digital product passports as a large database where their product data will be uploaded and kept. It is close to the opposite, and the misunderstanding leaves a hole in a lot of compliance plans.

What the registry actually holds

The architecture of the digital product passport (DPP) is deliberately hybrid.

At EU level there is a registry. It stores the unique identifiers for products and links each identifier to the location of that product's passport. Delegated acts for specific product groups may require some additional information to be stored there, and each act specifies what.

The passport data itself is decentralised. It is hosted by the individual economic operators, or by service providers acting on their behalf. The registry points; it does not hold.

Alongside the registry sits a public web portal, where consumers, businesses and authorities can search and compare product information.

Why the distinction changes your plan

If you assumed the Commission would store the passport, your plan is missing the part where you stand up the record, host it, keep it accurate and make it resolve on demand, for every product, for years after the sale.

That is not a filing exercise. It is running a small piece of public infrastructure on behalf of your own products, and the obligation does not end when the product ships. The economic operator is responsible for maintaining data accuracy across the product's lifecycle.

So the real question is not whether the EU will store your data. It is whether, when the registry points at your product, there is a complete and correct passport waiting at the other end.

What this means at the border and in the field

Customs authorities can search the registry electronically at the point of entry to check that a passport has been registered for a product before it is released for free circulation. That check is on the registration, not on the quality of your data.

Market surveillance authorities work the other way round. They scan the carrier on a physical product, reach your documentation, and check it. The registry helps them find passports; the verification lands on the record you host.

Note the timing: the interconnection enabling automated customs verification is scheduled to be operational within four years of the relevant implementing act entering into force. The architecture tightens over time rather than arriving fully formed.

Three questions worth asking any provider

Where does the passport actually live, and under whose control? Decentralised hosting means someone holds the data. Knowing who, and on what terms, is the first question.

What happens if that provider disappears? The regulation requires the passport to keep working for the product's life, and a back-up copy must be available through a service provider. This is covered in data continuity.

Can the record be exported? If the answer is complicated, the passport is hostage to a vendor relationship that has to outlast the product.

Junction serves passports through a public REST API built on the IEC 61406 identification link standard, and binds authenticity and the passport into one code per product. The registry points. Our job is making sure something real is there to point to.

Sources

• European Commission, *Digital Product Passport: Frequently Asked Questions*, January 2026 update,
• questions 18 and 19.
• Regulation (EU) 2024/1781 (ESPR), Article 15(3) on the customs interconnection timeline.