tyrepas.eu

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

Tyres have their own passport, separate from the vehicle they are mounted on

A tyre receives its own digital product passport as a tyre, and that passport is separate from any passport for the vehicle on which the tyre is mounted. The ESPR (Regulation (EU) 2024/1781) works with delegated acts per product group: for each group of products falling within the regulation, the data the passport contains and how it is structured are laid down separately (Article 9). In this arrangement, a tyre is an independent product with its own passport, linked to the tyre model — not to the specific vehicle on which it happens to be fitted. As soon as a vehicle, a battery or another component also falls under its own delegated act, that component receives its own passport. Those passports then exist alongside each other, not intertwined: the tyre passport does not change when the tyre moves from one vehicle to another, and the vehicle passport does not need to track tyre replacements. The connection between those separate passports runs via identification codes (Article 12), not via a single merged document.

For the tyre model, not for the tyre-plus-vehicle combination

This applies to the tyre as a product in itself — the model, the data of the manufacturer or importer, the characteristics laid down in the applicable delegated act. It does not apply to how a fleet manager brings together all passports of a complete vehicle (tyres, any battery, other components) in one overview; that is a practical matter for whoever manages the fleet, not a legal merger that the ESPR itself regulates. It also does not apply to components that do not yet fall under their own delegated act: without such an act, there is no mandatory digital product passport for that product group either, regardless of how closely that component is connected to a tyre or vehicle that does fall under the regulation. And the regulation says nothing about which passport is 'leading' once a tyre becomes part of a larger whole — the ESPR approaches each product via its own product group, not via the assembled end product.

Date for tyres not yet confirmed

There is no fixed date yet on which the digital product passport for tyres becomes mandatory, and thus no point at which it becomes clear in practice how a tyre passport works together with any other passports. The ESPR work plan for 2025-2030 mentions a delegated act for tyres expected in 2027; only with that act will it be fixed which data the tyre passport contains and from when it is mandatory. As soon as that act is published, the date will be added here. Until then, there is no obligation for tyres to have a digital product passport — the mechanics of Article 9 and Article 12 are already laid down in the regulation itself, the specifics for tyres are not yet.

This is how you handle it if multiple passports are involved

If you import tyres or resell them to fleet managers, you can reasonably assume that the tyre digital product passport will then be a standalone document, structured around the tyre model and distinguished by its unique identification code (Article 12). A first step is to verify which data from the tyre itself will be recorded — brand, model, technical characteristics, origin — separately from the vehicle on which the tyre will be fitted. A second step is to account for the fact that a fleet manager working with multiple digital product passports, for example tyres and, where applicable, a vehicle digital product passport, will consult those passports side by side themselves; the ESPR does not require automatic linking outside of the identification codes. A third step is to organise your own administration in such a way that the unique identification code of each tyre can be traced back to the correct batch and the correct digital product passport, so that a tyre which moves from one vehicle to another carries its own digital product passport with it, rather than the digital product passport remaining attached to the vehicle. Those wishing to prepare now would be well advised to maintain product data per tyre in a manner that is independent of which vehicle the tyre is fitted to — this aligns with how the ESPR links product groups and digital product passports to each other.

Legal basis: Article 9 and Article 12 of the ESPR

The fact that each product receives its own digital product passport follows from Article 9 of the ESPR (Regulation (EU) 2024/1781), which links the digital product passport to a product or product model within a product group designated via a delegated act — not to a complex assembled end-product in which multiple product groups are combined. The fact that separate digital product passports can nevertheless be linked to each other follows from Article 12, which provides for a unique identification code per product. This code makes it possible to retrieve data on a specific item or model and to relate it to each other, without the digital product passports themselves being merged into a single document.

Those who are already working with tyrepas.eu or considering doing so can limit themselves to providing the data from the tyre itself as supplied by the manufacturer or importer; a link with any other digital product passports for the same vehicle is not a prerequisite for building the tyre digital product passport. Once the delegated act for tyres has been published, this page will be updated with information on which identification codes and links are specifically expected.

What this is based on

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

What you must do concretely

What is expected of you

A tyre is sometimes part of a larger whole: a complete wheel, a fleet contract, or a vehicle that itself is also subject to product passport obligations. Within the tyre itself, multiple aspects may also become subject to passport requirements (material use, repair data, recycling information). Article 9 of the ESPR (Regulation (EU) 2024/1781) governs the digital product passport, but does not in itself provide an exhaustive answer to the question of what happens if a product technically falls into multiple passport-mandatory categories. This is elaborated per product category in the delegated acts. For tyres, this has not yet been published.

One unique identification code per product

Article 12 of the ESPR requires a unique identification code, linked to the specific product. For a company with 10 to 100 employees, this means in practice that thought must be given to the exact level at which that identification is made: per tyre size, per production batch, or per individual item. How that works out precisely for a tyre, and how that relates to tyre size as a characteristic, is described on the page about how tyre size relates to the unique identification code. Whoever must link multiple passports to one physical product — for example because it is part of a wheel-axle assembly — would do well to use that identification code as a fixed anchor point, even if the content of the passport differs per application.

One data carrier, possibly multiple passports behind it

The QR code on the tyre is the physical point of access through which a reader obtains information. Article 9 shows that the passport itself is a structured set of data that is disclosed via that data carrier. For a tyre that forms part of a broader assembled product (think of a complete wheel that is sold separately), it may occur that the tyre refers to a passport at component level, and the assembled product refers to a passport at system level. How that QR code ends up precisely on the product and what is practically involved is set out on the page about how the QR code for the product passport gets on the tyre. Important to note: one data carrier can in practice refer to one passport, or to a structure in which multiple data layers are incorporated — this is a technical matter related to GS1 Digital Link.

Registration in the European register

Article 12 is linked to the obligation to have passport data included in the central EU register. With multiple passports for related products, it is important to know what exactly ends up in that register and at what level (product, batch, or model). The page about the European register of digital product passports describes what is recorded there. For a mid-sized company, this mainly means: gaining clarity on which information unit is precisely registered, so that there are no duplicate or conflicting registrations when a tyre enters commerce through multiple channels (loose, as part of a wheel, as part of a vehicle).

Consistency between systems

When a product appears in multiple passports, inconsistency lurks: different data on the same characteristic, or passports that no longer run in sync after a change. This is primarily an operational matter. Companies that have their passport data fed from a central system can limit this risk. More on this is on the page about linking the product passport to an ERP or inventory system.

Where things go wrong in practice

An importer registers a tyre separately, and later again as part of a complete wheel — with slightly different specifications in both passports, because the data comes from two different internal sources.

A fleet manager receives a QR code from the supplier that refers to a passport at model level, while the end-user's question concerns a specific item — with a different production date or batch than stated in the passport.

A wholesaler sells the same tyre under two different tyre sizes to different customers, and in doing so accidentally reuses passport data in part without adjusting the size-specific characteristics. See also the explanation on reusing data for other tyre sizes of the same model — this can be done in certain cases, but not without attention to what differs per size.

A manufacturer updates the material information of a tyre, but the change does not automatically reach the passport of the assembled wheel product in which that tyre is incorporated — with the result that two passports no longer match each other.

A company assumes that one QR code is sufficient for all applications of a product, without checking whether the underlying data structure (via GS1 Digital Link or a comparable system) correctly distinguishes multiple passports from each other. See the explanation on the page on what GS1 Digital Link is and whether it is necessary for the product passport.

What you can record

  • An overview of which product at which level receives a unique identification code (individual product, batch, assembled product), so that it is clear which passport belongs to which identification.
  • An internal agreement on which data source is leading when a characteristic appears in multiple passports (for example material information that appears in both the tyre passport and the passport of an assembled wheel).
  • A procedure for updating linked passports when one of them changes, so that related passports do not diverge.
  • Documentation of the link between the QR code on the physical product and the underlying passport structure, including the question of whether one data carrier can refer to multiple passports.
  • A note on which data have been registered in the European register, and at which product level, so that this can easily be traced when the assortment is adjusted or expanded.
  • Recording of internal responsibility: who within the company checks whether linked passports (for example when sold as a separate part versus as part of an assembled product) remain consistent.

Until the delegated act for tyres is published, it cannot be said with certainty how this relationship between multiple passports for tyres will be filled in exactly. This page will be updated as soon as that act appears.

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