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

One product can have multiple passports, side by side

Yes, that happens: a product does not necessarily need just one passport. The ESPR (Regulation (EU) 2024/1781) governs the passport obligation per product category, through a delegated act. A product that falls under such an act receives a passport. But if that product is composed of components that themselves also fall under their own passport obligation — for example because a different regulation applies to that specific component — then there is not one passport that replaces everything. Multiple passports then exist side by side: one for the end product, and one or more for the components that themselves also have a passport obligation. Article 9 of the ESPR is structured so that a passport can refer to data from the passport of a component, instead of everything being recorded twice. It is therefore not a choice between passports, but a matter of determining which layers of the product have their own passport obligation and how they relate to each other.

For composite products, not for duplicates

This issue arises with products that consist of multiple components, more than one of which can separately fall under a passport obligation — think of a device with a built-in battery, where that battery may be subject to a separate regulation with its own passport obligation alongside the regulation for the device itself. This then involves two different obligations that happen to come together in the same physical product, not the same obligation twice for the same product. The latter is not the intention: one product under one delegated act should have one passport, linked to one unique identification code as referred to in Article 12 of the ESPR. If an importer or manufacturer accidentally has two passports created for the same product under the same regulation, that is not a "multiple passports" situation as meant here, but an error that should be corrected. A product that happens to be sold under two trade names also does not automatically receive two passports — the identification is attached to the product, not to the name under which it is offered.

No fixed date yet, but a fixed sequence

There is no fixed date yet for when this will become concrete for electronics and ICT equipment. The ESPR works with a work plan for the period 2025-2030, in which a delegated act is prepared per product category; for electronics and ICT, these acts are expected no earlier than 2027. As long as the act for a specific subcategory does not yet exist, there is also no passport obligation for that category — and therefore no question of whether one or multiple passports are needed. That question only becomes concrete once it is clear which delegated acts apply to which parts of a product. Until that time, nothing is required in this area; however, it is already possible to see which components a product consists of and whether a separate passport or registration obligation already exists or is in the pipeline elsewhere.

How to handle this in practice

It starts with mapping the composition of the product: which parts are in it, and are there any of those parts that might already be subject to a separate passport or product obligation, separate from the end product. Next, you need to check whether a delegated act or regulation exists or is being prepared for those parts, and if so, who is responsible for that part — this may be a different party than the manufacturer or importer of the end product, for example a supplier. Subsequently, it is practical to determine how the passports are linked to each other: via a reference in the passport of the end product to the passport of the part, instead of retyping the same data. Finally, it is wise to wait with definitive choices about the design until the relevant delegated act has been published, because only then will it be clear which data must go where.

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

That a passport can refer to or take over data from the passport of a part follows from Article 9 of the ESPR, which regulates the content and design of the digital product passport. That each product receives its own, unique identification code — which allows passports to be distinguished from each other and linked together without duplicate or confusing registrations — follows from Article 12 of the ESPR. Together, these articles form the basis for a system in which a composite product with multiple passport-obligated parts can still be documented clearly.

Those who wish to prepare now can best start by drawing up an overview of the parts of their own product and checking which of them may themselves be subject to a separate regulation; once the delegated act for their own product category is published, the date and precise breakdown will be shown here.

What this is based on

The regulation itself is on EUR-Lex. We provide references per statement; you do not have to take our word for it.

What you must concretely do

What is expected of you

A product with multiple components, materials, or functions may fall under more than one regulation for the digital product passport. Consider a device that contains a battery, or a product that falls under both an electronics sub-category and a separate regulation for, for example, textiles or construction materials. The ESPR (Regulation (EU) 2024/1781) is a framework regulation: Article 9 describes what a digital product passport must contain in general terms and how it must be accessible, but the specific requirements per product group come in delegated acts per sub-category. This makes the overlap of multiple passports on one product a realistic scenario, not an exception.

One unique identification code per product, also in case of overlap

Article 12 of the ESPR requires a unique identification code with which a product can be traced back to its passport. For a company with 10 to 100 employees, this means in practice that a choice must be made at which level this code is assigned: at the level of the complete end product, or also at the level of a separate component that itself falls under its own regulation (such as a battery). How that identification code is structured and linked is described on the page about how you assign each product a unique identification code. In case of passport overlap, working out this structure is usually the first bottleneck, because a wrong choice later becomes difficult to reverse without having to reissue the codes and QR codes already issued.

One data carrier, possibly multiple passports behind it

Article 9 of the ESPR assumes a data carrier on the product that refers to the passport. With a product with multiple passports, the question arises whether there is one QR code that leads to one combined view, or whether it refers to separate passports that each follow their own regulation. For a manufacturer or importer of electronics, this means that the structure of the content must be determined in advance, in consultation with the party that compiles and hosts the passport. The technical aspect of that reference — which identifier structure is used for this — is related to the question what GS1 Digital Link is and whether it is necessary for the product passport, because this structure is intended precisely to unlock multiple data layers behind one link.

Consistency between passports on the same product

When a product falls under two regulations, the principle is that the data that appear in both passports are not contradictory. A weight, a material composition, or a manufacturer name that is stated differently in one passport than in the other is an inconsistency that will be noticed during inspection. For a medium-sized company, this means that data provision to the party that compiles the passports ideally comes from one source file rather than from two separate input processes. This aligns with the question in which format the product passport data must be submitted, whereby a standardized format makes it easier to have the same data reach multiple passports without having to enter them manually twice.

Registration in the European register under multiple regulations

The register of digital product passports is the place where certain data about issued passports can be found centrally. For a product that falls under multiple sub-categories, it is relevant to ask whether registration for each applicable regulation happens separately, or combined. More about how that register works and what must be included in it can be found on the page about the register of digital product passports. As long as the delegated acts per sub-category have not yet been published, it is not yet possible to determine exactly how registration in case of overlap will proceed; this will be updated here once those acts are available.

Where things go wrong in practice

A common situation is a device with a replaceable battery, where the end product manufacturer assumes the battery supplier has already arranged the passport for that component, while that passport is never linked to the identification code of the end product. The result is a QR code that leads to the end product's passport, but says nothing about the battery inside it.

Another situation arises when a product is sold both as an individual item and in a bundled package, and the question is whether that one product then receives one passport or whether the packaged unit needs its own layer. This touches on the question how the product passport works for a box with multiple devices in it, and is often only noticed late in the process, after the QR codes have already been ordered.

It also happens that two departments within the same company, or two external parties, independently supply data for what is ultimately the same physical product — resulting in two slightly different descriptions of the same material or weight in two passports that exist side by side.

Furthermore, things go wrong when the choice of identification code structure is left to the IT department without having previously established at which product level (end product, module, component) that code is assigned, causing it to become apparent later that some of the products do not fit the chosen system.

A final recurring point is the moment when a company links its product range to an existing ERP or inventory system: if that system was set up before the need for multiple passports was an issue, it often lacks the field to indicate for each article which regulation(s) it falls under. This raises the broader question whether the product passport can be linked to the company's own ERP or inventory system.

What you can document

An overview per product group of which regulations (electronics, batteries, or others) may be applicable, including the status of the associated delegated acts.
The chosen structure for the unique identification code: at which product level (end product, component, packaging unit) codes are assigned and how they relate to each other.
A single source file or standardised data submission format for data that appears in multiple passports, so that the same data does not end up in different passports via separate input processes.
Agreements with suppliers (such as battery manufacturers) about which party compiles which part of the passport and how those parts are linked to each other.
A documented procedure for what happens if a delegated act for one of the applicable sub-categories is published or amended, so that existing passports can be adapted accordingly.

This is not legal advice. This page provides general information about the regulations that this platform covers. We are not familiar with 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 incorrect? Let us know — corrections take priority.