Can I link multiple digital product passports to each other?
Product components may have their own passport that links to the main passport
Yes, that is possible, and it is actually part of how the digital product passport is structured. A product often consists of multiple parts or components that themselves are also subject to passport requirements — think of a battery in a device, or a motor in a machine. The ESPR (Regulation (EU) 2024/1781) is based on a structure in which the passport of the end product can refer to the passports of the components from which it is composed. This happens via unique identification codes that are assigned to products, components, economic operators and facilities. These codes make it possible to link passports to each other without all information being recorded twice.
This concerns the structure of one product, not the arbitrary linking of separate passports
The linking for which the ESPR is designed follows the physical composition of a product: a passport of a component that is part of a larger product, linked to the passport of that larger product. This is different from arbitrarily connecting passports of products that have nothing to do with each other, for example to group them under one brand or one customer. There is no mechanism in the regulation for this. It is therefore a link that reflects the supply chain: component belongs to product, not product belongs to another product. For those hosting multiple product groups on one platform — as is the case with prodpas.eu — this means that each passport remains a standalone, valid document, even if it is part of a larger structure. The link adds a reference, it does not replace the own obligations that come with the component passport.
When this will apply exactly has not yet been determined for every product group
The ESPR itself describes the principle and technical conditions for linking passports, but the concrete obligation to maintain a passport — and thus also the question of when components must actually have their own, linkable passport — is laid down separately for each product group. There is therefore no general date that applies to all products. For product groups for which no specific regulation has yet been established, there is currently no passport requirement and therefore no linking obligation. What is certain is the framework within which that linking must work: based on unique identification codes, technically interoperable, and set up so that a passport of a component is recognizable and retrievable from the passport of the end product.
What this means for setting up passports
Anyone considering linking passports would be wise to first map out which components of a product are already or will be subject to a passport requirement. This determines whether there will be two (or more) passports that need to be linked to each other, or whether one passport for the entire product is sufficient. Next, it is important to know which unique identification code belongs to which component, so that the reference in the main passport is correct and remains up to date — especially if a component changes supplier. In practical terms, this means that data about components should preferably be available when the end product passport is being compiled, rather than being added afterwards. For a manufacturer or importer working with multiple product groups, it is advisable to review this per product: not every component has a passport requirement, and not every passport therefore needs to be linked. Where that is the case, the linking is inherent in the technology — it is not a separate part that is added, but a fixed element in the structure of the passport.
Where this is laid down: Articles 10 and 11 of the ESPR
The requirements for the content of the digital product passport, including the use of unique identification codes for products, market participants and facilities, are set out in Article 10 of the ESPR (Regulation (EU) 2024/1781). The technical implementation — how the passport functions, how data is recorded and how passports of components can be linked to the passport of the assembled product — is set out in Article 11 of the same regulation. Together, both articles form the framework within which product group-specific rules will later specify when and for which components this will apply in practice.
If you are setting up a passport at this time and already know that a product is assembled from components with their own passport obligation, it is best to indicate this immediately when submitting the product data, so that the link is properly included in the passport from the outset rather than being corrected later.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 11 (technical design and operation of the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
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
Products rarely exist on their own. A washing machine has a motor from one supplier and a control board from another, a piece of furniture consists of a frame and upholstery material, an electronic device has a battery that may itself also be subject to a passport requirement. Whether passports can be linked to each other is therefore not theoretical: it is precisely the situation many manufacturers and importers find themselves in.
Each passport remains linked to a unique identification code
Article 10 of the ESPR (Regulation (EU) 2024/1781) requires that the digital product passport can be traced to a specific product, model or batch via a unique identification code. That code is the starting point for a link: a passport of a component can be referenced from the passport of the assembled product, and vice versa. For a company of 10 to 100 employees, this above all means discipline in administration: each component that has its own passport must be given its own code that cannot be confused with that of the end product or other components. How that code is precisely structured is described at how you give each product a unique identification code.
The technical design must be able to handle links
Article 11 of the ESPR addresses the technical design and functioning of the digital product passport, and sets requirements for how passports must be able to communicate with each other and with other systems. This means that a link is not something a company designs on its own discretion; the structure must comply with the technical standards that apply to the passport. In practice, this comes down to the choice of a platform or service provider that already supports this structure, so a manufacturer does not have to build its own linking logic. Anyone wondering whether that is compatible with existing software can read more about it at linking the product passport to its own ERP or inventory system.
Multiple passports on one product must be mutually recognisable
Some products fall under more than one product group or must meet multiple requirements at the same time, with the result that not one but multiple passports are relevant for the same product. Article 10 expects that the data contained in a passport can be traced and are not contradictory. For a company that purchases components from different suppliers, each of whom have already had their own passport created, this means that it must be determined which passport belongs to which level of the product. This coincidence of passports is described more extensively at how multiple product passports work together on one product.
The link must still work after years
A passport that refers to another passport is only useful if that reference endures. Article 11 sets requirements for the durability of the technical functioning of the passport, which also applies to cross-references. For a company, this means that a link is not a one-off technical action, but something that must continue to function as long as the passport is active. How long that is varies by product group and is described at how long a product passport must remain available.
Where things go wrong in practice
A furniture manufacturer purchases upholstery fabric from a supplier who has already had a passport created for it, and refers in its own passport to that of the fabric. When the fabric supplier changes without notifying this, the passport of the furniture refers to data that no longer belong to the delivered product.
An electronics company installs a passport-liable battery in a device, but treats the battery's passport and the device's passport as completely separate documents without cross-reference. Anyone consulting the device's passport will then find no indication that a passport for the battery also exists.
An importer establishes a link between two product passports based on a product code that was modified internally after a system migration, causing the link to no longer align with the code listed in the component's passport.
A company that combines components from multiple suppliers into a single end product assumes that the suppliers will automatically update their passports, while no one has agreed on who does this and when. See also what is involved in automatically updating data in the digital product passport.
A manufacturer treats the link between component and end product as equivalent to the question of whether a component needs its own passport, whereas these are two different questions. The answer to the first question depends on the setup, the answer to the second is described in whether a component receives its own passport or the product as a whole.
What you can document
- An overview of all components within a composite product that have their own passport, with the associated unique identification codes.
- An agreement with suppliers on who is responsible for keeping the component's passport up to date, and how changes are communicated to the party assembling the end product.
- A documented structure of which passports refer to each other, so that when switching systems or migrating, it can be verified that all links remain intact.
- A note on which product groups apply to a specific product, and which passports are accordingly relevant.
- Documentation of the technical standard or platform on which the link is based, so that when changing service providers it is clear what needs to be transferred.
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.