What is the register of digital product passports and what must I enter in it?

What you must concretely do

What is expected of you

The European registry of digital product passports is a central facility in which certain data about each product passport is registered, alongside the passport itself which remains hosted by the manufacturer, importer or a service provider such as Ferropas. Article 13 of the ESPR (Regulation (EU) 2024/1781) describes this registry, Article 14 describes the associated web portal through which data from passports can be disclosed. For a trading company or processor with 10 to 100 employees, this amounts to a number of practical points of attention.

The passport must comply with the registry

The product passport itself is not in the registry — it remains with the party hosting it. What does go into the registry is a set of core data that identifies the passport and makes it findable: think of the unique product identification code, the link to where the passport can be found, and data about the party responsible for the passport. For a metal processor, this means that the way products are identified must comply with what the registry expects. Those wondering how each product receives a unique identification codewill find there the basis that is also needed for the registry link.

The QR code must point to the correct location

The QR code on the product or the associated documentation is the link between the physical steel and the digital passport — and indirectly also to the registry entry. Article 14 concerns the web portal through which data can be consulted; that accessibility starts with a correctly functioning data carrier. In practical terms, this means that the question how the QR code is applied to the steel is not separate from the registry obligation: a QR code that does not lead to a current, correctly linked passport undermines the entire system, even if the passport is correct in substance.

Data must remain current and consistent

The registry is not a snapshot upon delivery, but a reference that must remain current for as long as the passport exists. For a company processing hundreds or thousands of steel batches, the question is relevant whether passports are maintained per batch or per item, and how changes — a new owner of the passport, an adjusted hosting location — are processed. Those establishing processes for this would do well to determine in advance whether steel is registered per batch or per item, because that choice determines how many registry entries are created and how manageable that remains.

Integration with existing systems

For many companies, it is unattractive to maintain a separate system alongside existing inventory and order administration. The registry obligation therefore also touches on the question of how product data from an ERP system are provided to the passport and, via the passport, to the registry. This is one of the places where early consideration of integration with your own ERP or inventory system can prevent a lot of manual work later.

Where things go wrong in practice

A number of situations recur among companies that deal with the registry.

A first situation is that the identification code of a product changes — for example following an internal reorganisation of item numbers — without the registry entry being updated. The passport still exists, but is no longer findable via the code used internally.

A second situation arises when a company ceases operations or is taken over, and no one has recorded who remains responsible for the registry entry and the underlying passport. This is relevant not only to the passport itself, but also to the question what happens to the product passport if a company ceases operations — a question that is just as relevant for the registry link as it is for hosting.

A third situation is that a product requires multiple digital product passports — for example because it consists of different materials that each fall under different rules — and the register entries for those do not refer to each other consistently. This raises the question how multiple digital product passports for one product work together, which directly affects how those products end up in the register.

A fourth situation is that the data format in which data is supplied does not align with what is needed for linking to the register. Because not everything has yet been worked out in delegated acts, it is advisable to look now at which data file is needed for the digital product passport, so that later adjustment is limited.

A fifth situation is uncertainty about small or irregular components, where a supplier assumes that registration is not feasible and omits the link to the register. For such cases there is practical information about how a QR code is applied to a small piece of steel, which often makes the problem solvable.

What you can document

• An overview of which unique identification codes are linked to which digital product passports and register entries, including a procedure for changes.
• Agreements with the hosting party (such as Ferropas) about who keeps the register entry current during the lifespan of the digital product passport — a question that is linked to how long a product passport must remain available.
• A documented procedure for batch versus individual item registration, so that new employees or departments apply this consistently.
• Documentation of the chosen data format and the link with the ERP system, so that in the event of a system change or audit it is clear how data was supplied.
• An internal point of contact or procedure for the situation in which the company ceases operations, is taken over, or a product line is discontinued — including who is then responsible for the register entry.

Ferropas offers templates for part of this documentation; for the precise content of the register and the web portal, the text of Article 13 and Article 14 of the ESPR remains the official source, especially as long as the implementing delegated acts have not yet been published.