can I use a product passport for multiple variants of the same product

One passport per model, not per individual product

No, in practice a product passport operates at the level of model or variant, which means that each variant that differs on a relevant point gets its own passport — but that is different from one passport per sold unit. A product passport is linked to a unique identification code, and that code is designed to uniquely identify a product or a product group with identical characteristics. If two variants differ from each other in something that is relevant to the information requirements of the passport — a different material, a different battery, a different energy performance — then as a rule that means two passports, even if they look almost identical. If two products are identical in all relevant respects, for example only a colour difference that changes nothing about composition or performance, then a shared passport for that group is more appropriate.

Where the dividing line is: characteristic versus colour

This applies to manufacturers and importers who market one product in multiple versions: different sizes, colours, materials, capacities or performance classes within one product line. The demarcation lies in the question of whether the difference between the variants affects something that appears in the passport or should appear in it. If it concerns data that is identical for all variants — origin, general components, the company behind the product — then reuse of the same basic data across multiple passports is feasible. If it concerns data that differs per variant — a different repair manual because the component is constructed differently, a different durability indication, a different recycling percentage — then that is precisely the information the passport is designed for, and it must not be obscured by applying one passport across multiple differing variants. What therefore cannot be done: use one passport for variants that are actually different products, in the hope that the QR code still works the same. What can be done: use the same underlying data structure and the same platform for a whole series of variants, as long as each variant gets its own correct passport and its own code.

No fixed date yet, but a fixed structure already

There is not yet a general date on which this obligation applies to all product groups; that is determined separately per product group in the delegated regulation that applies to it. What is already established, regardless of which product group comes first, is the structure laid down in the ESPR itself: how a passport must technically work, what the unique identification code must be capable of, and what basic requirements apply to the passport. That structure will not change per product group, only the content and the entry into force date will. If you already have an assortment of variants, you can therefore perfectly well think about the division into passports per variant, without having to wait for the date on which your own product group becomes mandatory. More about that build-up over time is on the page about what is already established while the rules are not yet final.

How this works out in practice for an assortment with variants

A logical first step is to organize the assortment according to what truly differs between the variants and what does not: two variants with exactly the same materials, the same lifespan and the same repair process, but a different colour, are a different situation than two variants with a different battery capacity or a different energy label. Next, it is useful to determine at which level the unique identification code is assigned: per individual sold unit, per batch, or per model variant — this varies per product group and is described in the requirements that apply to that group. After that comes the question of which data are generic (and can therefore be entered once and reused across multiple passports) and which data must be supplied separately per variant. For a platform that compiles passports from the data of the manufacturer, that is a matter of establishing the common basis once and completing only the differing fields per variant — this saves repeated work without creating the risk that a variant with incorrect or shared data leaves the factory. Anyone who wants to work through this step by step will find a more concise overview on the page how to approach the digital product passport step by step.

The basis: Articles 12, 11 and 10 of the ESPR

That a passport belongs to a unique identification code is stated in Article 12 of the ESPR (Regulation (EU) 2024/1781); that article governs how a product or product group is made identifiable and is the core of the question of whether two variants with or without a shared passport go through life. The technical design of the passport itself — how it is structured and how it must function — follows from Article 11, and the general requirements to which a passport must comply are set out in Article 10. Which data a passport must precisely contain, and thus which differences between variants truly require a separate passport, is filled in by the ecodesign, performance and information requirements from Articles 5 to 7, further elaborated per product group.

Anyone who currently has an assortment with multiple variants and wants to know how that translates into a division of passports can place their own product overview alongside the requirements of their own product group as soon as these are known, and in the meantime already organize the data structure in such a way that variant differences are recorded separately.

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

One passport per variant sounds awkward if a product comes to market in ten colours or sizes. The question of whether that can be done differently breaks down into a few separate obligations that together determine what is and is not permitted.

Each physical variant requires its own unique identification code

Article 12 of the ESPR (Regulation (EU) 2024/1781) requires that a product be linked to a unique identification code. That code is intended to make it possible to unambiguously trace one product, or one product model. For a company with 10 to 100 employees, this means in practice that it must be considered at which level identification must take place: per sold unit, per batch, or per model. The ESPR allows for identification at model level when the products within that model are otherwise identical, but as soon as there is a difference in composition, material or performance, a separate code is more appropriate than a shared one.

The content of the passport must be correct for the product to which it applies

Article 10 of the ESPR (Regulation (EU) 2024/1781) sets out the requirements that the digital product passport must meet, including that the information in the passport corresponds to the product that the passport represents. This is the key point in the question about variants: a passport may be shared as long as the underlying data actually apply to all copies under that code. As soon as a variant differs in material composition, repair possibilities, origin of components, or anything else that must be stated in the passport according to the product group requirements, one shared passport no longer fits that variant.

The product group requirements determine what counts as "the same product"

Articles 5 to 7 of the ESPR (Regulation (EU) 2024/1781) govern the ecodesign requirements and the corresponding performance and information requirements per product group. These requirements are further specified per product group, and precisely that specification determines which level of detail is relevant. For one product group, colour may be irrelevant to the passport, for another product group a different composition certainly counts as a different product. This means that the answer to the variants question is never generic for "a product", but is linked to what is mandatorily laid down for that specific product group. If you want to know whether the digital product passport applies to your own assortment, there you will find the starting point to determine per product group what the requirements are.

The technical design must maintain the link between passport and carrier

Article 11 of the ESPR (Regulation (EU) 2024/1781) describes the technical requirements for the digital product passport, including how the data carrier (in practice usually a QR code) unlocks the passport. When one passport is used for multiple variants, that technical link must still be sound: every QR code on every copy must lead to the correct, up-to-date information. In practice, variant management creates the greatest risk here, because a shared passport can contain a data field that is correct for one variant and no longer correct for another.

Where things go wrong in practice

Colour variants are placed under one passport without checking whether the material composition is the same. Paint, coating or fabric can differ in composition by colour, which has implications for recycling information that must be included in the passport.

A product line is adjusted over time (new supplier of a component, different batch of raw material), but the existing passport remains unchanged. The QR code then points to information that is still correct for older copies, but no longer for newer ones.

Size variants of a product (S/M/L, or different dimensions) are treated as "the same product", even though repair instructions or component information may differ by size.

An importer takes over the manufacturer's passport for their own assortment, without verifying whether their own purchased variant exactly matches the variant for which the passport was originally compiled.

When internal discussion about "is this the same product group or not" fails to reach a decision before the QR codes are already on the packaging, an error is only discovered after production and correction becomes more work than clarifying things beforehand.

What you can document

An overview per product line of which variants exist and in which respects those variants differ from each other (material, composition, origin of components, repair possibilities).
A decision document in which it is established for each variant whether it falls under a shared passport or receives its own unique identification code, with the reasoning for this.
A change log: when a supplier, component or composition changes, it is recorded whether that has consequences for the existing passport of that variant.
Agreements with the supplier or manufacturer about who is responsible for notifying changes that affect the passport, especially when the passport is compiled by a party other than your own organization.
A fixed procedure for linking the QR data carrier to the correct variant, including a check before production that the code refers to the correct content.

Organizations that include this topic in their broader approach can best do so as part of the step-by-step approach: how the product passport is set up step by step addresses the order in which these types of decisions are made, and why variant management early in the process yields more than correcting afterwards. For companies that still want to try out how this works in practice before the obligation comes into effect for their own product group, there is the possibility to create a test version of the product passport, in which variant structures can be tested without consequences.

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 based on the sources above, reviewed by a human on 2026-09-05. Is something incorrect? Let us know — corrections are given priority.