What Is a Digital Product Passport?

For thirty years, the data that describes a physical product has been thrown away at every handoff. A smelter knows the exact alloy composition of the aluminium it ships. The component maker who buys it does not. The brand who buys the component knows even less. By the time the finished product reaches a recycler, the only way to find out what is inside is to shred it and analyse the pieces.

The Digital Product Passport exists to stop that loss. It is the European Union's answer to a simple question: if we want products to be repaired, resold and recycled rather than discarded, what does someone at the end of the chain need to know — and how do we make sure they still know it years later?

¿Qué es un pasaporte digital de producto?

Three things in that definition do the work, and each rules out something a passport is often mistaken for.

• Structured and machine-readable. A PDF datasheet is not a passport. The data must be queryable by a machine — a recycler's sorting system, a regulator's surveillance tool, a marketplace's listing check — without a human transcribing it.
• Attached to the physical product. The link between the atoms and the data is the point. A database of product information that you cannot reach by scanning the object in your hand solves nothing at end-of-life.
• Persistent across the lifecycle. The passport must still resolve when the product is resold in 2034. That is an obligation about hosting and identity, not about file formats.

Why does the EU require one?

The policy logic runs backwards from a target. The EU wants far more material kept in circulation. Circulating material requires that someone can identify, sort and recover it economically. That requires knowing what is in the product. And that information only exists at the moment of manufacture — so it has to be captured there and carried forward.

The Ecodesign for Sustainable Products Regulation (EU) 2024/1781 is the framework that makes this mandatory. It replaces the older Ecodesign Directive, which applied mainly to energy-related products, and extends the same logic — set requirements at the design stage — to almost every physical product sold in the EU.

Critically, the ESPR itself does not list the data your product needs. It creates the power to require it. The actual requirements arrive later, product group by product group, in delegated acts.

What data does a Digital Product Passport contain?

The exact fields are set per product group, but the ESPR names the categories every passport draws from. In practice these break into five families.

The first family is easy — you already have it. The second is where every programme stalls, and we will come back to it.

Who can see what? The five-view problem

A passport has to serve audiences with irreconcilable needs. A consumer wants to know how to wash the jacket. A recycler wants to know whether the coating is a PFAS. A regulator wants the evidence chain behind every claim. The brand wants none of its supplier pricing visible to any of them.

The resolution is one identity with role-scoped views: the same scan returns different data depending on who is asking and what they can prove about themselves.

How is a passport actually built?

A working passport is four decisions, in this order. Getting the order wrong is the most common cause of expensive rework.

The bottom layer is the one that separates a passport from a product page. If your passport says "38% recycled aluminium" and the only basis is that you typed it, a regulator has no more reason to believe it than a marketing claim. Signing that assertion as a W3C Verifiable Credential, issued by the party who actually knows it, is what makes it evidence.

What standards does a passport use?

There is no need to invent anything here, and inventing is actively harmful — a proprietary passport format is a passport that stops working the moment the customer changes vendor.

What actually goes wrong?

Every DPP programme discovers the same three problems, usually in the same order, and usually later than it should have.

The data does not exist yet

Teams budget for a platform and discover the platform was the cheap part. The expensive part is that your tier-2 supplier has never been asked for recycled content, does not measure it, and is not contractually obliged to tell you. Start supplier engagement before you start procurement.

Every supplier sends a different spreadsheet

You will receive the same field named Country of Origin, COO, Herkunftsland and Made In in the same week. Mapping this is genuinely tedious work, and it is where most programmes quietly lose their first year. It is also the part most amenable to automation, because the mapping problem is repetitive and checkable.

The requirements change after you build

If you model your data against a specific regulatory form, the next delegated act is a rewrite. If you model it against a standards-based product model and map to each regulation, the next act is a mapping change. This single architectural decision is the difference between a programme that scales across product groups and one that is rebuilt for each.

What should you do now?

1. Find out whether your product group is named in the ESPR working plan, and when its delegated act is indicatively expected.
2. Inventory what data you already hold against the five families above. Most organisations are stronger on identity and weaker on composition than they expect.
3. Identify the suppliers who hold the rest, and how far down the chain they sit. This determines your timeline more than anything else.
4. Get supplier data obligations into contracts at the next renewal. Retrofitting them later is much harder.
5. Choose a standards-based data model before choosing a vendor, so the vendor decision stays reversible.
6. Build one passport end to end for a single product before scaling. It will surface every problem above at 1% of the cost.

The organisations that will find this easy in 2028 are the ones treating it as a data-supply problem in 2026. The ones that will find it painful are the ones treating it as a document-production problem three months before their delegated act bites.