My product needs multiple product passports — how does that work together?

One passport per product is the starting point of the ESPR

Where multiple digital product passports for the same product come into play, the ESPR's starting point is not that these exist side by side, but that the data converge in one digital product passport per product, linked to one unique identification code. Article 9 of the ESPR (Regulation (EU) 2024/1781) describes what a digital product passport must contain and how it must be accessible; Article 12 governs the unique identification code by which a product and the associated data are unambiguously linked to each other. This code is the pivot point: it ensures that different data sources — from the manufacturer, from a processor, from a certification body — reach the same physical product, even if that data stems from multiple obligations at the same time. For a semi-finished product of steel or iron, this means that it is not the intention that there will be a separate "ESPR passport" alongside another passport for the same product; the system is designed around one access point per product.

For whom and for what this applies — and for what it does not

This concerns the structure of the digital product passport itself, as the ESPR envisages it: one identification code, one centrally accessible data record. It does not concern other obligations that remain separate from the passport, such as CE marking, a material certificate or an inspection report — those documents do not disappear and are not automatically part of the passport, although data from them can be included in the passport. It also does not concern the question of whether iron and steel are currently already subject to an obligation: that is not yet the case, because no delegated act has yet been adopted for this product group. And it does not concern the precise technical manner in which data from different EU regulations will in practice be combined when a product is subject to more than one regulation with its own passport obligation — that detail follows from delegated acts that do not yet exist, and Articles 9 and 12 themselves do not specifically address it.

What is not yet fixed, and what is

There is no fixed date yet for when this will apply to iron and steel. What is fixed is the framework: the European Commission is working with a work plan for 2025-2030, in which the first delegated acts are expected in 2026, with obligations coming into force at a later date. Which product groups and with what content this will happen is determined separately for each delegated act — for iron and steel, that act does not yet exist. Until such an act is published and enters into force, there is no legal obligation for this product group to have a digital product passport, and there is therefore also no concrete regulation yet on how that passport relates to any other passport obligations on the same product. As soon as the act is published, the date and content will be updated here.

How to approach this in practice

The first step is to check whether your own product, in addition to a future ESPR obligation, also falls under another EU regulation that already records data on the same product or will soon have its own passport-like obligation. The second step is to keep that existing documentation in order and store it in an organised manner — certificates, composition data, origin information — regardless of which system it will eventually be placed in, because this is the basis from which a future passport will be compiled. The third step is not to get ahead of a technical link that does not yet exist: as long as there is no delegated act for iron and steel, there is also no established way in which data from multiple regulations come together in one record. The fourth step is to align your own sources (manufacturer, importer, processor) on who supplies which data, so that when the obligation and the associated identification code do exist, merging into one passport is a matter of transferring data rather than having to reconstruct data afterwards.

Where this follows from: Article 9 and Article 12 of the ESPR

The basis for all this lies in two articles of the ESPR (Regulation (EU) 2024/1781). Article 9 specifies what a digital product passport must contain in terms of content and how it must be accessible to the parties involved. Article 12 regulates the unique identification code that links a product to its data record — the technical link that ensures that there is one recognisable point of reference per product, rather than loose, unlinked datasets. Together, these articles form the framework within which "one product, one passport" is established as a principle, even though further implementation for specific product groups — including iron and steel — must still come through delegated acts.

Those who wish to prepare now would be well advised to make existing product documentation centrally and digitally accessible, so that it can later be linked without difficulty to the unique identification code once it exists; further waiting is for this product group at this time the only thing that can actually happen, because the obligation itself does not yet exist.

What this is based on

The regulation itself can be found on EUR-Lex. We provide references for each statement; you do not have to take our word for it.

What you must concretely do

What is expected of you

A steel product can become part of multiple regulatory trajectories at the same time. A steel beam or plate is in itself a semi-finished product, but is often processed into a construction product, a machine component, or something with a battery in it. Each of those applications may soon bring its own digital product passport, structured according to the ESPR but filled with product-group-specific requirements that differ per delegated act. How those passports relate to each other when one physical product falls under multiple regulations has not yet been worked out in detail — the ESPR provides the framework, the product-group-specific delegated acts must develop that further.

One unique identification code per product

Article 12 of the ESPR (Regulation (EU) 2024/1781) governs the unique identification code by which a product is linked to its passport. For a company with 10 to 100 employees, this means in practice that there must be a system that tracks which code belongs to which product, and that this link is not lost when a product changes owner or is processed into something larger. Where multiple passports per product exist, it is relevant to ask whether there will be one code for the entire product, or whether components (such as the steel in a composite construction product) retain their own code. More about the structure of that code can be found in how do I give each product a unique identification code?

Accessibility of data via a single data carrier

Article 9 of the ESPR (Regulation (EU) 2024/1781) sets requirements for the digital product passport as a whole: what data it must contain, who may access it, and how it remains accessible. When a product combines multiple passports, this means for a processing company that careful attention must be paid to which data carrier unlocks which information. One QR code can in theory point to multiple data sources, but the technical arrangement of that has not yet been determined. How that data carrier comes to be on the product is described in how does the QR code for the product passport get onto my steel?, and the question of whether a standardised link is needed for that comes up again in what is GS1 Digital Link and do I need it for the product passport?

Registration at the correct level

When a product consists of multiple layers — the raw steel, the semi-finished product, the end product — the question arises whether passport data are recorded per batch, per piece, or per composite product. For a metal processor who buys steel and processes it further, this is a practical choice that has consequences for how many passports ultimately need to be managed and at what level they come together. See more on this in do I register steel per batch or per piece?

Where things go wrong in practice

A construction company processes steel with its own passport into a composite building element that itself also receives a passport. Without clear agreement on which passport shows which data, there is a risk that the same information (for example origin or composition) appears in two places, with slightly different values because one has been updated and the other has not.

A metal processor buys steel with a passport from the manufacturer, processes it into a component, and does not know whether a new passport is needed for the processed product or whether the passport of the raw material "travels along". This leads to postponement of a choice that actually needs to be made beforehand.

A company applies one QR code to a composite product that points to the passport of the end product, but the underlying steel components technically also have a right to their own retrievable passport. During an inspection or when a customer asks questions, it then turns out that those underlying data are not easy to find.

A trading company sells steel on to a customer who integrates it into a machine with its own passport obligation. The question of who is responsible for keeping the steel data current within that machine passport is not recorded, so when a later change occurs (for example a different alloy) it is unclear who must communicate that.

A company assumes that the European register will automatically establish the link between related product passports. What exactly must be included in it and how product passports of composite products relate to each other is not yet known in detail — see what is the register of digital product passports and what must I enter in it?

What you can document

An overview of which products or product groups in the assortment may fall under more than one product passport obligation, and which legislation applies to it.
An internal agreement on the level at which passport data is registered (raw material, semi-finished product, end product), so this is not determined anew per order.
Documentation of the unique identification code per product and how that code is passed on to the next party in the chain, including the question of whether a link with your own ERP or inventory system helps — see can I link the product passport to my ERP or inventory system?
An agreed arrangement with suppliers and customers about who manages which part of the passport data when a product is processed into something new.
A saved version of the submission format in which passport data is exchanged, so this does not depend on the memory of one employee — more about this in in what format must I submit the data for the product passport
A note on how physically small parts that still need their own passport are provided with a data carrier, relevant for composite products with small steel components — see how do I get a QR code on a very small piece of steel

These records make it easier later, when the product group-specific rules for steel become known, to quickly connect without having to rebuild the basic administration.

This is not legal advice. This page provides general information about the legislation that this platform deals with. We do not know your situation. If you are in doubt about your own case, consult a lawyer or the competent supervisory authority.

Written with AI based on the sources above, checked by a human on 2026-08-22. Is something not right? Let us know — corrections are given priority.