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

One product, multiple passports: the link runs via the identification number

If a product requires multiple digital product passports, they are not merged into a single document — they remain separate and are linked to each other via unique identification codes. This occurs in two situations: a product is composed of components that have themselves already been placed on the market separately and thus already have their own passport obligation (think of a battery in a device), or a product falls under more than one product group for which the ESPR (Regulation (EU) 2024/1781) has separately developed rules. In both cases, each passport receives its own scope and content, and the unique product identification code ensures that the passports are traceable as part of the same whole. This does not result in an endless collection document, but rather a structure of linked, self-contained passports.

For assembled products and products that fall under multiple product groups

This issue applies to products composed of multiple, independently tradeable components where one or more already has its own passport obligation, and to products that fit into multiple product groups simultaneously — for example because one product group regulation addresses the function of the product and another addresses a material or component within it. This does not concern the situation in which the same information happens to be requested twice for the same product, and it also does not concern a freedom of choice to voluntarily create a second passport alongside the mandatory one — the ESPR works with exactly one unique product identification per product, not with duplicate or parallel registrations for the same case. For most products, which fall under exactly one product group and do not contain components with their own passport obligation, this entire issue does not arise: one passport is sufficient.

When this will apply is determined per product group, not in the ESPR itself

The ESPR itself establishes the framework — Article 9 for the content and functioning of the digital product passport, Article 12 for the unique identification codes — but the concrete obligation to maintain a passport only arises per product group, via a delegated act for that group. For a product that falls under multiple product groups, this means that one obligation may come into force earlier than another, simply because the delegated acts are not all adopted at the same time. A fixed date when 'the linking of multiple passports' as a whole must function is not specified in the consulted sources. What is certain: as soon as a delegated act for a product group becomes applicable, the passport obligation applies from that moment for products in that group, and the identification structure of Article 12 functions as the mechanism by which any other passports for the same product remain traceable.

How to approach this in practice

The first step is to determine which product group or product groups the product falls under — this determines which delegated act(s) apply and thus which passport content is required. The second step is to check whether the product contains components that are already being placed on the market separately under a different regulation and thus may already have or will have their own passport — a built-in battery is the most common example. The third step is to establish the correct unique identification codes per passport: product identification, and where relevant the identification of the market actor and the production facility, so that the passports can point to each other instead of information being entered twice. The final step is to submit the data per product group to the party that compiles and hosts the passport, so that each passport contains the codes that refer to the other(s). On prodpas.eu this is set up per product group: the data that apply to that group are processed into the passport for that group, with the identification code that makes it possible to read the individual passports of the same product together.

The basis: Article 9 and Article 12 of the ESPR

Article 9 of the ESPR (Regulation (EU) 2024/1781) regulates what a digital product passport must contain and how it is made accessible via the data carrier; the precise content per product group is specified via the delegated act for that group. Article 12 of the same regulation regulates the unique identification codes — for the product, the market actor and the production facility — which are the key to being able to link data and documents that belong together without combining them in a single file. Together, these two articles form the basis on which multiple passports for one product can exist side by side and yet be searchable as a coherent whole.

Anyone who is uncertain whether a product falls under one or multiple product groups is well advised to check this per component and per function of the product on the basis of the applicable or upcoming delegated acts, and to keep the data per group separate when submitting for the passport.

Where this is based on

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

What you must do concretely

What is expected of you

A product with multiple applications or components may fall under more than one product group for which a digital product passport applies. Think of a device containing a battery, or a textile product with an electronic component. The ESPR (Regulation (EU) 2024/1781) sets out in Article 9 what a product passport must contain, but product group-specific legislation determines anew which information is mandatory for that component or application. This means that one physical product may in practice have to deal with multiple passports, each with their own content, their own update requirements, and possibly their own unique identification code according to Article 12 of the ESPR.

Determining which passports apply

For a company with 10 to 100 employees, this first means an inventory: which components of the product fall under which product group, and which of those product groups already have an elaborated requirement for a digital product passport. This is not a one-time task — as more product groups come under the ESPR, a product that currently can manage with one passport may later have to deal with a second. Anyone working without an overview in this area often discovers the second obligation by chance, for example through a question from a customer.

Determining whether the passport applies per component or for the assembly as a whole

A second step is to determine whether a passport is drawn up per component or for the assembled product as a whole. This varies by product group and by situation, and the outcome is not always obvious: a battery in a device may need its own passport while the device itself receives a different passport that refers to that battery. More on that consideration is set out on the page about whether each part receives its own passport or the product as a whole. For practical purposes it is especially relevant that this issue is resolved beforehand, not only when the passport is about to be published.

Ensuring that the passports complement rather than contradict each other

When a product works with multiple passports, they must be mutually consistent. Data that appears in both passports — a brand name, a model number, a production date — should be the same everywhere. This seems self-evident, but becomes more difficult when the passports are compiled by different departments or different suppliers, and when they are updated at different times. There is a technical possibility to link passports to each other, so that a passport of a component refers to the passport of the assembled product or vice versa; how this works is described on the page about linking multiple product passports.

Giving each passport its own identification code

Article 12 of the ESPR (Regulation (EU) 2024/1781) sets out the unique identification code that is assigned to a product. With multiple passports for one product, the principle is that each passport — and therefore each passport object, whether that is a component or the whole — receives its own identification code. In practical terms, this means that the system by which identification codes are issued must be able to handle this layer: not one code per article number, but possibly multiple codes for what administratively is one product. The setup is described on the page about assigning a unique identification code to each product.

One QR code or multiple on the product

Physically, this raises the question of how many QR codes a product carries. A product with two relevant passports can in theory receive two QR codes, but this is not always practical or necessary — a single data carrier can also direct to a landing page from which the different passports are accessible. Which setup is appropriate depends on how the product group-specific requirements prescribe the data carrier. Background on the placement of the code is set out on the page about how the QR code for the product passport comes onto the product.

Where things go wrong in practice

A common problem is that a company has a complete passport for the main product, but fails to realize that an embedded component — a battery, an electronic circuit board — falls under its own product group requirement with its own passport. This often only becomes clear when a supplier asks about it themselves.

A second situation: the two passports exist, but have been built separately by different teams, with slightly different data about the same component. A repair date that has been updated in one passport but not in the other creates confusion for those consulting the passport.

A third situation arises when a product is modified — a component is replaced with a different model — and only one of the two passports is updated. The link between the two passports then becomes factually incorrect, even if the linking technology itself still works.

A fourth, common situation is duplicate work: because no one has an overview of which passports already exist, the same source data is manually entered again for a new passport instead of being managed from a single location. Linking with your own ERP or inventory system can prevent this; how this works is described on the page about linking the product passport to your own system.

A fifth situation is that with composite products having multiple passports, no one knows anymore which passport belongs to which QR code, especially when a product has been modified over time and old data carriers have been left in place.

What you can document

An overview per product of all components and applications, along with which product group requirement applies to them and whether a passport obligation applies.
A documented decision on whether the passport is drawn up per component or for the product as a whole, with the justification for that decision.
A list of unique identification codes per passport object, including which code belongs to which physical component.
Agreements on who maintains which passport and at what point passports are realigned following a product modification.
A documented linking structure between passports, including which data take precedence in case of overlap.
An overview of which QR code on the product refers to which passport or which landing page.

Templates are available for these items that can serve as a starting point when setting up this overview and the associated agreements.

This is not legal advice. This page provides general information about the regulations that this platform concerns. 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 on the basis of the sources above, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections are given priority.