what should I pay attention to when choosing a supplier for the product passport
Pay attention to the link with the data registers, not just to a nice dashboard
A software solution for the product passport you choose based on what happens under the hood: how the data are stored, who can access them, and whether the system connects to the registration register that the European Commission is setting up. Article 10 of the ESPR (Regulation (EU) 2024/1781) sets requirements for the passport itself — which data it must contain, how long they are kept, who may modify them — and article 11 concerns the technical design: how the passport is structured, linked to a unique carrier, and read by a QR-code or similar system. A supplier offering this platform must therefore not only sell a solution that produces a passport today, but one that does so correctly over the years to come, even as the technical standards are further developed.
This concerns the technique, not the content of your assortment
The choice of a software supplier is a different question from whether a specific garment falls under the obligation. Which products precisely fall under the digital product passport and when is described in what a digital product passport for clothing and textiles precisely comprises and in the guidance on whether the product passport applies to a specific assortment. This article does not address that substantive scope, nor does it address the costs of a passport — that is covered in the overview of what a product passport for clothing and textiles costs. Here it concerns specifically the criteria by which to assess a supplier or platform, irrespective of who manufactures or sells the product.
The obligation is not yet fixed, the technical requirements are already fixed in part
There is no fixed date on which software choice becomes unavoidable. The delegated act for textiles is expected according to the work plan of the European Commission for ecodesign of sustainable products, with clothing with a high proportion of textile fibres as the first category. As long as that act has not been published, it is not determined from which moment a passport becomes mandatory. What is already fixed are the general requirements for the digital product passport from articles 9, 10 and 11 of the ESPR: these form the framework within which each delegated act for a product category is further developed. A supplier preparing for this now is therefore not too early.
Five points to go through with a supplier
The first question is whether the system can link data to a unique product identification and a carrier such as a QR-code, as article 11 of the ESPR describes. A solution that only generates a loose PDF file does not meet the idea of a passport that is continuously accessible and updatable. The second question is who enters and manages the data: with a private label or import the information often runs through multiple parties, and a system that clearly separates roles and rights — manufacturer, importer, brand — prevents anyone from no longer knowing who made the last update or may do so. The third question concerns the retention period and hosting: article 10 sets requirements for the availability of the passport during the product's lifetime, so a supplier who only offers a subscription for a couple of years without clarity on what happens afterwards leaves a gap in coverage.
The fourth question concerns data sources: can the system import data that already exists elsewhere, such as from a supplier statement, test report or fabric list, or must everything be entered manually. This also touches on the question of who is responsible for translation of data into the languages of the markets where a product is sold — a subject that is further developed in the guidance on who arranges for translation of product passport data. The fifth question is how the system handles changes after publication: a product passport is not a snapshot, and a supplier that offers no version control or adjustment capability makes it difficult to correct errors or update data without going through the entire chain again.
Furthermore, it is worthwhile to look at how a supplier handles the physical aspect of the data carrier: whether the QR code aligns with existing labels and packaging, or whether adjustments are necessary — a question that also comes up when considering whether clothing labels and packaging should now be adapted. Anyone wishing to tackle this step by step will find a sequential approach in the overview of how the product passport for clothing and textiles is being tackled step by step.
Where that is stated: articles 9, 10 and 11 of the ESPR
The basis for these criteria lies in article 9 of the ESPR (Regulation (EU) 2024/1781), which introduces the digital product passport as an instrument, supplemented by article 10 on the specific requirements for the content and availability of the passport, and article 11 on the technical design and operation, including the link with a unique carrier. The regulation itself does not cover a specific product category such as clothing; this is done through delegated acts, the planning of which can be found on the European Commission's website on the regulation for ecodesign of sustainable products.
Anyone who is now orientating themselves towards a supplier can use these five points as a checklist in a conversation or demo, and lay their own situation — assortment, supply chain, existing systems — alongside it to see which supplier fits best there.
What 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)
- Regulation (EU) 2024/1781 (ESPR), Article 9 (digital product passport)
- European Commission — ecodesign regulation for sustainable products
The regulation itself is available on EUR-Lex. We provide references for each statement; you do not need to take our word for it.
What you must do concretely
What is expected of you
Choosing a software supplier for the product passport is not a matter of finding the cheapest QR code generator. The ESPR sets requirements for the passport itself, and those requirements indirectly determine what a system must meet. Anyone who reviews this beforehand avoids the need for a new system later.
The passport must be linked to a physical data carrier
Article 9 of the ESPR (Regulation (EU) 2024/1781) describes the digital product passport as a data set that is linked to the product via a carrier — in practice usually a QR code. For a company with 10 to 100 employees, this means that the software solution must not only store data, but must also be able to provide a working link with a physical carrier on the product or the label. A system that only generates a PDF does not meet that requirement. Anyone who is still in doubt about this or whether the label should already be adjusted reads more about it at must I already adapt my clothing labels and packaging for the product passport.
The technical operation must meet fixed requirements
Article 11 of the ESPR (Regulation (EU) 2024/1781) covers the technical design and operation of the passport: among other things, that data must remain accessible, that the carrier and the storage system must function reliably, and that the data remain linked to the correct product, even if that product changes hands. For a company, this means that a supplier must be able to demonstrate how long data is retained, who can access it, and what happens if the company itself changes suppliers or ceases operations.
The content must align with what product legislation will require
Article 10 of the ESPR (Regulation (EU) 2024/1781) describes the requirements for the content of the passport, such as which data categories belong in it. That content is further detailed per product group through delegated acts — for clothing and textiles this has not yet been published. A software solution must therefore be flexible enough to adjust data fields later without the entire system having to be set up anew. Companies that are already collecting data are well advised to structure it in a way that can grow with the legislation; see also what can I do now whilst the rules are not yet final.
Where things go wrong in practice
A number of situations regularly come up in practice when choosing a software solution.
A company chooses a system that does generate QR codes, but does not guarantee long-term hosting. After a year the supplier stops operating or is taken over, and the QR codes on sold clothing point nowhere anymore.
Another company imports clothing through multiple suppliers from different countries and discovers that the chosen software does not allow data to be displayed in multiple languages, while the end customer is in a different country than where the product was produced. If you recognize yourself in this, you will find more about the responsibility for translation at must I arrange for translation of my product passport data myself.
A third situation: a brand sets up the passport for new collections, but forgets that there is still large inventory in the warehouse that may fall under the same rules once the date is set. The software is then not configured to retroactively link data to existing article numbers. More on this is at what do I do with clothing and textile stock already on hand when the rules come into effect.
A fourth recurring problem: the chosen system is set up for new sales, but does not account for second-hand sales or return flows, leaving it unclear whether and how the passport accompanies resale. See on this Does the product passport also apply to second-hand clothing and returns.
A fifth situation: during an inspection, a supervisory authority asks for insight into the source of data in the passport, and it turns out that the software does not maintain version history or source documentation — only the end result. What a supervisory authority can specifically ask for is described at what does a supervisory authority request during an inspection on clothing and textiles.
What you can record
When choosing a software supplier, it is practical to have a number of points confirmed in writing, so that there is no misunderstanding about what has and has not been promised.
- Hosting term and continuity — a written agreement on how long data remain accessible and what happens if the supplier ceases operations or is taken over.
- Ownership and transferability of data — establish that data can be exported on request, and under which conditions.
- Linking with the physical carrier — a description of how the QR code or other carrier is technically linked to the product, and who is responsible for applying it to the label or packaging.
- Expandability of data fields — an agreement that the system can add data categories once the delegated act for clothing and textiles is published.
- Source and version management of data — establish that source documents and changes remain traceable, not only the end result.
- Languages and target groups — agreements on which languages data are displayed in and who is responsible for the accuracy of translations.
If you want to go through this process step by step, including the question of when a software choice fits into the planning, you will find an overview at How do I approach the product passport for clothing and textiles step by step. For an indication of the costs associated with these choices, there is What does a product passport for clothing and textiles cost.
This is not legal advice. This page provides general information about the regulations that this platform covers. We are not familiar with 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-09-05. Is something not right? Let us know — corrections are given priority.