The EU Digital Product Passport, and the deadline behind it

From 2027, a growing list of products sold in the European Union will have to carry a Digital Product Passport: a structured record of what the thing is made of, where it came from, and what should happen to it at the end of its life, reachable by scanning a code on the product itself.

It is easy to read that as a labelling exercise. It is not. The passport is a data problem wearing a compliance hat, and the companies that find it painful will be the ones who discover in late 2026 that nobody owns the answer to a simple question: what is actually in this product, and who told us so.

What the passport actually is

The Digital Product Passport is introduced by the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, which entered into force in July 2024 and replaced the earlier Ecodesign Directive. ESPR is a framework: it does not by itself say that your particular product needs a passport tomorrow. It creates the machinery, and delegated acts then switch it on for one product group at a time.

In practice a passport has three parts. There is a unique identifier for the item, batch or model. There is a data carrier on the product, in most cases a QR code, that resolves to the passport. And there is the data itself, which varies by product group but generally covers composition, origin, durability, repairability, recycled content, substances of concern and instructions for disposal or recycling.

A registry sits behind all of this, so that market surveillance authorities and customs can look products up rather than relying on whatever a manufacturer chooses to publish on a web page.

Who is affected, and when

The obligation falls on whoever places the product on the EU market. That is usually the manufacturer, and where the manufacturer sits outside the Union it lands on the importer or the authorised representative. Selling into Europe from elsewhere does not avoid it. It moves it to whoever brings the goods in.

Dates move. Delegated acts slip, transition periods get extended, and anyone who tells you the schedule is fixed is selling something. What does not move is the direction, and the fact that the first battery date is close enough that preparation has to start before the detail is final.

The part that takes longest is not the software

Generating codes and serving pages is a solved problem. What is not solved, in most companies, is knowing what to put in them.

Composition data usually lives with suppliers, sometimes several tiers down, in spreadsheets nobody validates. Recycled content percentages are often a claim rather than a measurement. Product records are spread across an ERP, a PLM system, a quality database and somebody’s laptop, and they disagree. None of that is visible until you try to publish it and discover the three systems give three answers.

So the honest order of work is: find out what you actually know, find out who would have to tell you the rest, agree which system is the source of truth for each field, and only then worry about how it reaches a phone in a shop. The companies that start with the code carrier are solving the last problem first.

Why permanence is the hard requirement

There is one property of this problem that makes it different from ordinary web work, and it is worth stating plainly: a code printed on a product cannot be recalled.

Once a passport is printed onto a sofa, a battery or a jacket, that code has to keep resolving for as long as the product exists. Not until the next replatforming. Not until the domain is changed for a rebrand. A passport that stops working takes a compliance obligation with it, and no amount of engineering afterwards puts the code back on the product.

That has consequences for how you choose a system. Ask what happens to codes already printed when the vendor changes their domain. Ask whether a passport can still be verified if the vendor disappears. Ask whether the signature over the data is checkable by a third party without asking the vendor anything at all. If the answer to the last one is no, what you have is a web page, not a passport.

Where to start

1. 1Work out which of your products fall into the first groups, and whether you are the one placing them on the market.
2. 2Pick one product and try to fill in a passport by hand. The gaps you hit are the real project plan.
3. 3Identify the source of truth for each field, and who has to be asked for the ones you do not hold.
4. 4Only then choose how codes are generated, carried and resolved, with permanence as the first question rather than the last.