My supplier supplies components from different product categories — how do I handle that?

One data request per product group, not a collective request

A supplier that delivers components for products from different product groups will in practice face as many different information questions as there are product groups — not one uniform request. This is because the requirements for the digital product passport are laid down per product group in its own delegated act: what must appear in the passport of a piece of furniture is different from what must appear in the passport of an electronic device or a textile product. A supplier that, for example, delivers the same plastic components for a kitchen appliance and for a piece of furniture is thus effectively supplying under two different regulations at the same time, even though the physical product is the same.

Who this applies to, and where the boundary lies

This issue arises for manufacturers and importers who purchase components, materials or semi-finished products from one supplier, while those components end up in end products that fall under different product groups. It does not apply when a supplier supplies to multiple customers, but those customers all manufacture products within the same product group — in that case, only one set of requirements applies, regardless of the number of customers. Nor does this concern the question of what exactly a supplier must deliver; those substantive requirements (material composition, origin, repair data, and the like) are set out each time in the delegated act of the relevant product group itself. What Article 38 of the ESPR (Regulation (EU) 2024/1781) does address is the obligation of an actor in the supply chain to make that information available upon request — irrespective of how many different product groups that actor serves.

What is already established and what is not

There is no general date on which this obligation enters into force for all product groups at the same time. While the ESPR itself is in force, the concrete requirements for a digital product passport — and with it, the question of which data a supplier must provide for a specific group — only arise per product group, once a delegated act has been adopted for that group. For a product group for which no delegated act yet exists, there are therefore no concrete passport requirements and no concrete information obligation to the supplier based on it. Until that point, the main thing is to follow which product groups are first in line, so that preparation does not lag behind the moment when an act enters into force.

How to approach this in practice

The order that logically follows starts with the component itself: ascertaining in which end product it ends up, and under which product group that end product falls. Some suppliers deliver the same component to multiple customers who incorporate it into very different products — the component itself does not determine the product group, the end product it is used in does.

Next, it should be checked whether a delegated act has already been adopted for that specific product group, and thus whether concrete passport requirements already apply. Only then does it become clear which data exactly is needed.

Subsequently, it is advisable to direct a separate and specific request to the supplier per product group, rather than one general request 'for all data'. The reason is that the required dataset differs per group: what is relevant for one group (for example, data on repair or disassembly) may not apply to another group. A collective request runs the risk that the supplier provides something that is too much for one group and too little for another.

It is also advisable to record per product group which information has been requested, when, and what has been received. This overview is not only practical for your own administration, but also substantiates your own digital product passport obligation: it demonstrates that the source of the data per group has been verified, rather than generically assumed.

Finally, this is not a one-time exercise. As more delegated acts are adopted and more product groups fall under the ESPR, this process repeats itself: verify again whether an existing component now also falls under a new regulation, and if so, direct a targeted request to the supplier again.

Where this follows from: Article 38 and Article 10 ESPR

Article 38 of the ESPR (Regulation (EU) 2024/1781) stipulates that actors in the supply chain — including suppliers of components and materials — are obliged to provide, upon request, the information necessary to compile the digital product passport, including to economic operators other than their direct customer. Article 10 of the same regulation determines that the content of the passport per product group is established in the corresponding delegated act. The combination of these two articles explains why there is no uniform, cross-group dataset: the obligation to provide data is general (Article 38), but what data must be provided differs per group (Article 10).

What to do about this

A first step is to create an overview of all components supplied by this supplier, with the end product and corresponding product group for each component. Then, per group, verify whether a delegated act has already been adopted, and if so, what data it requires. On this basis, a targeted request can be drawn up per group for the supplier, instead of one general question about "all passport data".

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

A supplier that delivers textiles, furniture components and electronics faces a different moment of obligation, different data requirements and possibly a different scope of application of the delegated regulation for each of those categories. The ESPR (Regulation (EU) 2024/1781) works with product group-specific delegated acts: the basic regulation sets the framework, but the content of the passport differs per group. For the purchasing company, this means that one supplier relationship in practice consists of multiple, separately managed dossiers.

What is expected of you

For each product group, establish whether and when the passport applies

The fact that a supplier delivers under one name and one framework agreement says nothing about the moment of application of the passport per product. Textile components may be made mandatory at a different time than electronic components from the same supplier, simply because the delegated act for that group has a different date of application. For a company of this size, this means that procurement administration must be organised not by supplier but by product group: track for each article group whether, and from which moment, the passport is mandatory. Those who have not yet clarified this can find a starting point in when the product passport becomes mandatory for products and in the broader question whether the digital product passport applies to the company's own products.

Request data separately for each product group

Article 10 of the ESPR describes which categories of data a digital product passport must contain, but the precise details — which parameters, which test methods, which substances are reported — are determined per product group in the delegated act. One request to the supplier with the text "send the passport data" therefore produces three different answers for three product groups, or, worse, one incomplete answer that does not fit any of the groups properly. In practice it works better to formulate a separate data request for each product group, asking which data are precisely needed for that specific category. An overview of what to ask in that regard can be found in which data you must request from your product suppliers.

Clarify responsibility in the chain per role

Article 38 of the ESPR describes obligations for actors in the supply chain, including making available information needed to comply with passport obligations. Which party in the chain plays which role — manufacturer, importer, authorised representative — can differ per product group, even if it is the same supplier physically. A supplier who acts as a manufacturer within the EU for one product group may import components from outside the EU for another group, with a different regime of responsibilities. In that latter situation it is useful to look at what the passport means for import of products from outside the European Union.

Contractually set out that supply differs per product group

A purchasing contract that speaks in general terms about "supply of passport data" provides little guidance when a supplier delivers in good time for one group and not for another. It is more workable to agree per product group, or at least per category with its own date of application, when which data are to be supplied and in which format. How that concretely lands in a contract is described in how you record the supply of passport data in your procurement contract.

Where things go wrong in practice

A common mistake is treating the supplier as one block: data is requested once, a contract is signed once, and it is assumed this covers all products. As soon as one of the product groups becomes mandatory earlier than the others, it turns out that this group was never specifically enquired about.

A second situation is that the supplier himself does not realise that his range falls under different regimes. He supplies, for example, primarily electronics and treats a small supplementary range of textiles in the same way — with the result that for those textile components the wrong, or insufficient, data are supplied.

A third recurring point is that internal procurement systems code products by product group, but do not link them to a passport status. As a result, with a new order it is not apparent that a certain product group is now subject to the obligation, while another group from the same supplier has not yet been affected.

A fourth situation arises in subcontracting: the supplier itself delivers an assembled component, but has part of it made by a third party. For one product group that component is decisive for the data in the passport, for the other it is not. If this is not broken down, there is a risk of missing data that must specifically come from that subcontractor — see also which data to request from a subcontractor making a component.

A fifth situation is that one assumes that verified accuracy of data for one product group automatically says something about the reliability of data for another group from the same supplier. This is not the case: each product group has its own source data and its own verification step, as can also be read at how to verify a supplier's data for accuracy.

What you can document

An overview per product group of the supplier, including the applicable delegated act number and the date on which the passport for that group will become effective.
Per product group a separate data request to the supplier, instead of one general request for the entire assortment.
Contractual agreements that establish per product group, or per category with its own implementation date, when and in what format data will be supplied.
An established division of roles: for which product group the supplier is the manufacturer, for which group he acts as importer, and what that means for the obligations on both sides.
A note for each product group as to whether subcontractors are involved in its production, with a separate data request directed to those parties.
A file per product group with the received data, the verification steps and the date of the last update, so that a change in one product group is not accidentally applied to another.

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.