Central Registry vs Decentralised Data in a DPP

The Digital Product Passport (DPP) system brings together two worlds: a central registry and decentralised data. Understanding what sits where helps you make sound decisions about hosting and providers. This article contrasts the two elements and shows why the design is beneficial.

Two elements, two roles

The DPP architecture deliberately separates two functions. The registry is centralised and acts as an index and verification layer. The passport data is decentralised and stays with the company or its provider.

This is not a technical compromise but a conscious division of roles. Each element does what it is best suited to: the registry provides a consistent reference point, and the data stays close to those responsible for it.

What is centralised

Little sits on the central side, but it is enough for the system to work:

• product identifiers,
• registration metadata,
• commodity codes where relevant,
• links to surveillance systems and the customs Single Window.

The registry confirms that a passport exists and who it belongs to. It does not, however, store its full content.

What is decentralised

What is most valuable stays with the company — the passport content itself. These are the data layers on identity, composition, environment and traceability that the carrier on the product points to.

This lets the company keep control of its data and how it is hosted and updated. We expand on the layered architecture in The four layers of a DPP system.

Why not one big database

The idea of a single central database of all passports sounds simple but has serious drawbacks. Such a database would be a single point of failure for the whole market and an attractive target for attacks.

The decentralised model spreads that risk:

• one provider's outage does not take down the whole system,
• companies do not have to hand over control of sensitive data,
• the registry stays lightweight and scalable,
• different sectors can use different technical solutions.

That is why decentralisation is a design principle, not a transitional stage.

Consequences for companies

Since the data stays on your side, you are responsible for its availability and continuity. Choosing a DPP service provider should therefore weigh backups, portability and the ability to export data without lock-in to a single provider.

That is the practical lesson of this architecture: the registry will not protect you, because it does not store your data. We cover this in Backups and continuity of DPP data.

Who is responsible for what

The technical split goes hand in hand with a split of responsibility. The economic operator — the manufacturer or importer — is responsible for the content and accuracy of the passport. Verification in the registry is an identity and access check, not a certification of data quality.

An analogy: catalogue and shelves

A library analogy helps. The registry is the catalogue: it says an item exists, who registered it and where to find it. The passport data is the books on the shelves — the actual content, which stays with those responsible for it.

The catalogue is single and shared, so everyone reaches the right entry. The shelves are distributed, so one failing does not close the whole library. This split captures the logic of the DPP system well.

Trade-offs of the decentralised model

Decentralisation has advantages, but it also brings duties onto the company. Since the data is with you, you are responsible for its availability, backups and exportability.

In a fully centralised model these duties would fall on the database operator, but at the cost of control and of the whole market's resilience. The EU deliberately chose resilience and company control, accepting that data continuity becomes a task for the economic operator and its provider.

Questions to ask a provider

Since you own the data layer, choosing a provider is a risk decision. It is worth asking, among other things:

• where and how the passport data is hosted,
• how often backups are made and what recovery looks like,
• whether the data can be exported in a structured format,
• what migration to another solution looks like without losing history.

The answers say more about data safety than the product's features alone.

Key takeaways

• The DPP system combines a central registry with decentralised data — each has a different role.
• The registry holds identifiers and metadata; the passport content stays with the company.
• Decentralisation spreads risk and lets companies keep control of their data.
• You, not the registry, are responsible for data availability and continuity.
• The manufacturer or importer owns the passport content; the registry verifies identity, not data quality.

See how CyfroPass hosts passport data and links it to the EU DPP registry. Visit cyfropass.pl and build a system that does not hinge on a single point of failure.