How do I approach the product passport for products step by step?
Five steps from product category to working passport
A digital product passport is best approached not by starting with the passport, but with the product category. The ESPR (Regulation (EU) 2024/1781) is a framework regulation: Article 9 describes what a digital product passport is in general terms and who is responsible for it, and Article 10 describes the requirements such a passport must meet. Which specific data must be included, for which product category, and from when, is not set out in these two articles themselves but is worked out separately for each product category in a delegated act. The steps that follow from this always follow the same pattern: find out whether and which regulation applies to your own product category, collect the data that results from this, ensure the passport technically complies with Article 10, and affix the data carrier to the product or packaging.
For manufacturers and importers, not for every product at once
Article 9 places the obligation for a digital product passport on the market operator who places the product on the market — in practice often the manufacturer or importer. This is the party that supplies the data and is responsible for its accuracy, even if the compilation and hosting of the passport is actually carried out by a service provider. Where this approach does not apply: a product only becomes subject to a passport obligation once a delegated act has been adopted for that specific product category. The ESPR itself does not therefore require all products to have a passport in one go; this happens gradually, product category by product category. A roadmap that is now being drawn up for one product category is therefore not automatically a blueprint for another: the data, the data carrier and the level of detail can vary by product category, even though the underlying framework in Articles 9 and 10 is the same.
When the obligation comes into force is determined per product category
There is no general entry date for "the product passport" — that date is only fixed once the delegated act for the product category in question has been adopted and published. Article 9 and Article 10 set the framework within which those acts must fit, but not the point at which a specific product category comes into play. Until such an act exists and comes into force, the existing rules (such as labelling, conformity and other product legislation) apply in full for that product category, without the additional obligation of a digital passport. Anyone wishing to proceed step by step is therefore well advised to monitor the status of their own product category via official publications, rather than relying on a fixed date that would be the same for all products.
This is how you do it, in the order that works
The first step is to check whether a delegated act under the ESPR has already been established or is in preparation for your own product group; without that act, there is no concrete obligation to comply yet. The second step is, once that act exists, to find out which data it requests — think of data on materials, origin, repair or recycling, depending on what has been established for that product group. The third step is to collect that data from your own production and supply chain, which often involves the most work because the data is then still dispersed among different departments or suppliers. The fourth step is to compile the product passport itself, such that it complies with the technical and accessibility requirements of Article 10 — including that the product passport is linked to a unique product or product model and that the correct parties (competent authorities, consumers, economic operators) can access it, each according to their own access rights. The fifth step is to apply the data carrier, in practice usually a QR code, to the product, packaging or accompanying documentation, so that the product passport is findable with the product for the period during which it must remain available.
This follows from Article 9 and Article 10 of the ESPR
Article 9 of the ESPR (Regulation (EU) 2024/1781) establishes what a digital product passport contains and which economic operator is responsible for providing and keeping it up to date. Article 10 sets out the technical and functional requirements that the product passport must meet, including the link to a unique product, accessibility for different users and the way in which data is disclosed via the data carrier. Both articles form the generic framework; the product-specific elaboration — which data, for which product group, from when — always follows from a separate delegated act based on this framework.
What to do now
Check whether a delegated act under the ESPR already exists or is in preparation for your own product group, and use Article 9 and Article 10 as a checklist for the role and technical requirements that in any case apply, regardless of which product group is involved. Start by mapping the data that is available in the chain on materials, origin and processing — that work is never wasted, because virtually every delegated act will rely on this type of data.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), article 9 (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
A digital product passport does not come about all at once. Article 9 and Article 10 of the ESPR (Regulation (EU) 2024/1781) describe what a digital product passport must contain and how it must be accessible, but those articles say nothing about the order in which a company organises this. That order is recognisable in practice, and breaks down into a few steps that follow each other logically.
Determining whether and when the passport applies to your products
The obligation applies per product category, and not every product category is yet subject to it. The first thing that must be clear is whether a product falls or will fall under a delegated regulation, and if so, which one. That is a research question in itself; does the digital product passport apply to my products? goes into this in more detail. For a company with multiple product categories in its assortment, this means that the status is investigated separately per category — one category may already be concrete, the other still in preparation.
Determining what data is required
Article 10 sets out the requirements that the passport must meet, and the delegated regulation for each product category specifies what data is concretely needed: materials, origin, repair data, conformity information, depending on the product category. For a company with 10 to 100 employees, this means an inventory: what data already exists (in procurement, quality control, engineering), what is missing, and from whom the missing data must be obtained — from a supplier, from a test report, or nowhere, because it still needs to be collected.
Organising who supplies and manages the data
In the case of imports, data often comes from a manufacturer outside the EU, and that supply must be organised before a passport can be compiled. In the case of own production, the data is spread internally across procurement, engineering and quality. In both cases, this means that someone is designated who is responsible for keeping the data complete and up to date, and that a fixed place is established where that data comes together before it goes to a passport.
Having the passport compiled and linked to a data carrier
Article 9 describes that the passport must be accessible via a data carrier, in practice a QR code on or with the product. For a company, this means a technical step: the data must be entered into a system that generates a passport and links it to that data carrier, and that system must fit in with the way products are already labelled or packaged.
Keeping the passport up to date over the product's lifetime
A passport is not a snapshot at the time of sale. Data on repair, maintenance or subsequent changes may remain relevant during the product's lifetime, and the host of the passport must keep this available over a longer period. For a company, this means that a process is put in place for updating passports, not just for creating them.
Where things go wrong in practice
A common mistake is that companies wait until the delegated regulation for their product category is final, and only then start collecting data — which makes the lead time much longer than expected, because data must be obtained from suppliers who are not prepared for it.
A second situation is that the data does exist, but is scattered across different departments and systems, without anyone having an overview. When compiling the passport, it then turns out that no one can say with certainty which version of a specification is the correct one.
A third is that companies set up a passport per product model without thinking about variants — colour, sizing, minor technical differences — which results in unnecessarily many passports or, conversely, one passport being incorrectly used for products that actually differ. Can I use a product passport for multiple variants of the same product? addresses how that issue plays out in practice.
A fourth situation: the technical side of the passport — the linking with the QR data carrier, the system that hosts the data — is only regulated when the deadline is already in sight, whereas this is precisely the component that takes time to properly set up and test.
A fifth: employees on the shop floor, for example in packaging or dispatch, do not know that a data carrier must be placed on the product and what may or may not be on it, as a result of which labels are applied incorrectly or forgotten.
What you can document
- An overview per product group of the status: does the obligation already apply, is there a draft regulation, or is nothing yet known — see what you can already do while the rules are not yet final how to structure that overview
- A list of required data per product group, together with who the source is (own department, supplier, testing institute)
- A designated person responsible for keeping passport data up to date, including a moment when that is periodically checked
- Agreements with suppliers on the delivery of data, including the moment when that must take place
- A test process before the obligation actually takes effect, so that bottlenecks in data provision and the linking with the data carrier become visible beforehand — can I make a test version of the product passport in advance describes what such a test could look like
- An instruction for employees who apply the data carrier to the product, so that labels are placed consistently and in the correct location — see also how do I prepare my staff for working with the product passport
- A decision on how to handle existing stock that was already produced before the passport became mandatory, recorded together with the rest of the planning
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.