Most articles about the digital product passport explain the policy. The policy is the easy part. A digital product passport is a structured data record. It ties to a product through an identifier and a data carrier. It holds fields you almost certainly do not have, at a level of identity your PIM was probably not built for. That is the part that costs money, and it is the part nobody prices.
We have spent fifteen years moving catalogues between systems. The pattern here is familiar. The regulation is not asking you to buy software. It is asking you to hold different data, about different objects, to a different standard of accuracy. And to keep holding it for years after the sale.
The policy in ninety seconds
The Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, entered into force on 18 July 2024. It applies to any physical goods placed on the EU market, including components and intermediate products. The exclusion list is short. Food, feed, and human and veterinary medicines. Living plants, animals and micro-organisms. Products of human origin and reproductive material. Vehicles, where other sector law already covers them.
ESPR is a framework. It does not itself say what your product data must contain. That comes from delegated acts, one product group at a time. The Commission’s working plan was adopted on 16 April 2025. It puts steel and aluminium, textiles with a focus on apparel, furniture, tyres and mattresses at the front of the queue. Horizontal measures on repairability and recycled content for electrical and electronic equipment sit alongside them. A mid-term review is scheduled for 2028.
Two things are already real rather than pending. The EU’s Digital Product Passport Registry went live on 20 July 2026. And from 19 July 2026, large companies have been banned from destroying unsold clothes, clothing accessories and footwear, with medium-sized companies following in 2030.
That is the policy. The rest of this article is about what it does to your catalogue. If you want the regulatory background in more depth, we keep it on our digital product passport page and in DPP fundamentals.
What the digital product passport asks of your data model
Here is the honest summary. Five things change, and only one of them is a software purchase.
Identity: model, batch or item
This is the first and biggest decision, and most teams do not realise it is a decision.
A passport can be required at model level, batch level or individual item level. Which one applies is set in the delegated act for that product group, not by you. A tyre and a jacket will not be treated the same way.
Your PIM is a model-level system. It holds a SKU, its attributes, its relationships and its content. It is designed for tens or hundreds of thousands of rows that change slowly. It is not designed for tens of millions of rows. Rows created every time something comes off a line, then updated for the next decade.
So if your product group lands at item level, you are not extending a PIM. You are adding a serialised layer next to it and joining the two through the identifier. That architecture question is worth answering early, because the two designs cost very different amounts. We work through the split on our PIM solutions for DPP page.
The battery passport is the live worked example of this. It applies from 18 February 2027 and separates model-level information from information about the individual battery. Anyone selling energy storage, e-bike batteries or EV batteries is dealing with this now rather than later.
Identifiers: product, operator and facility
The passport hangs off a unique product identifier, issued in line with internationally recognised standards. It also brings in a unique operator identifier and a unique facility identifier.
That third one catches people. Facility means the place the thing was made. Most distributor catalogues have no concept of a manufacturing site at all. You hold a supplier, maybe a brand, and a part number. You do not hold “which of this supplier’s four plants made this batch”, and you have no field to put it in.
Adding manufacturer, operator and facility as governed entities with their own identifiers is a data model change, not a data entry task. It affects your supplier records, your product records and every integration between them.
Attributes you almost certainly do not hold
The information requirements vary by product group, but the shape repeats. Durability and reliability. Recycled content. Substances of concern. Repairability, spare part availability and disassembly information. Environmental footprint. Reuse and recycling instructions.
Look at any distributor schema we have audited and you will find rich commercial attributes and almost no lifecycle attributes. The catalogue was built to sell the product, so it holds dimensions, finish, compatibility and warranty. It does not hold what the product is made of, where the material came from or what happens to it afterwards.
Adding those fields properly means designing them: name, type, unit of measure, allowed values, and the categories they are scoped to. Bolt them on as free text and you get data that cannot be validated, cannot be machine-read and will fail at the registry. This is ordinary taxonomy and attribution work, done to a stricter standard than usual. It is the same discipline we set out in our guide to product attributes.
Access tiers turn one record into several views
A passport is not a single public page. Different information goes to different audiences. The general public. People with a legitimate interest, such as repairers and recyclers. Competent authorities, including market surveillance and customs.
That means every attribute needs a visibility rule attached to it. Not a document-level rule, an attribute-level one. Your PIM has to express “this field is public, this field is authority only, this field is visible to recyclers”. If it cannot, you will manage three parallel exports and reconcile them by hand. We have seen that pattern before with channel-specific feeds, and it does not age well.
The data carrier is the easy part
A data carrier, normally a QR code, links the physical product to its passport. Vendors love this bit because it demos well.
It is genuinely the smallest piece of work in the programme. Generating codes is trivial. The effort sits elsewhere. Deciding what the code resolves to. Keeping that resolution stable for the life of the product. Making sure the record behind it is accurate.
Who is responsible for the digital product passport
The economic operator that places the product on the EU market is responsible for the passport and for the accuracy of what is in it. Not the manufacturer by default. Not the software vendor. The operator.
For a UK or EU distributor importing goods, or selling own brand, that is frequently you. This is the single most expensive misunderstanding in the whole area. We have sat in rooms where everyone assumed the supplier would provide the data. The supplier assumed the brand owner would. The brand owner was a trading company with four staff.
Two practical consequences follow.
First, you need to know, line by line, who the responsible operator is. That is an attribute on the product record, and almost nobody has it today.
Second, if the answer is you, your supplier onboarding has to change. A once-a-year spreadsheet template will not produce recycled content percentages or substance declarations at the granularity a passport needs. Rewriting that request cycle, with validation and a rejection rule for data that fails it, is the longest lead time in the programme. It is why we treat supplier data onboarding as the critical path rather than a later phase.
The migration cost nobody prices
Vendors quote you for licences and configuration. Here is what actually consumes the budget, based on what we see on real programmes.
Schema design. Somebody has to decide the attributes, types, units, allowed values and category scoping for every affected group. This is expert work and it cannot be crowdsourced to category managers with a spreadsheet. On a mid-size catalogue it is weeks, not days, and it is the work that determines whether everything downstream is cheap or expensive.
Backfill. New fields arrive empty. Every existing SKU in an affected category needs values, and the values have to come from somewhere real. Extraction from supplier documents gets you part of the way. The rest is chasing. Backfill is usually the largest single line in the plan and the one most often left out of the business case.
Supplier data collection. New fields, new frequency, new validation, and a conversation with every supplier about why they now have to tell you where something was made. Some will refuse. Some will send rubbish. Budget for the exception handling, not just the happy path.
Serialisation and integration. If your product group lands at item or batch level, three things follow. A store for that data. A link from manufacturing or goods-in. A resolution service for the carrier. This is engineering work, not PIM configuration.
Persistence and governance. The passport has to stay available for a period set in the delegated act, and stay accurate as the product changes. That means someone owns it after go-live. Every programme we have rescued failed at exactly this point, on ordinary product data, long before regulation was involved.
The honest framing for a board is this. The software is the smallest number on the page. The schema, the backfill and the supplier work are the programme. Anyone quoting you a passport project without those three lines has quoted you a demo.
What the digital product passport standards now pin down
One reason to start now rather than wait is that the technical picture has stopped moving.
CEN and CENELEC’s joint technical committee JTC 24 has published eight European standards for the digital product passport system. They were developed under the Commission’s standardisation request M/604 to support ESPR. They cover:
- EN 18216, data exchange protocols.
- EN 18219, unique identifiers.
- EN 18220, data carriers.
- EN 18221, data storage, archiving and persistence.
- EN 18222, APIs for passport lifecycle management and searchability.
- EN 18223, system interoperability.
- EN 18239, access rights management, security and business confidentiality.
- EN 18246, data authentication, reliability and integrity.
Six of the eight had been cited in the Official Journal as of July 2026.
Alongside them, the DPP Registry is operational. Economic operators register unique identifiers and high-level metadata there before placing a product on the market. The passport data itself stays decentralised, held by the operator or a passport service provider.
What that means in practice: the plumbing is now specified. The question left on your desk is whether your product data can fill it. That is a catalogue question, and it is answerable today, without waiting for a delegated act.
What we would do first
If a distributor or manufacturer asked us where to start this quarter, we would say this.
- Work out which product groups touch you. Steel and aluminium, textiles and apparel, furniture, tyres and mattresses are first in the working plan. Batteries already have a date.
- Answer the identity question per group. Model, batch or item. Everything else follows from that answer.
- Add the responsible operator as an attribute. Line by line. You cannot plan an obligation you have not allocated.
- Run a gap analysis against a candidate field list. Which lifecycle attributes exist, which are free text, which are missing entirely. Count the SKUs behind each gap, because that number is your backfill cost.
- Fix units and types before you add fields. Adding new attributes to a schema that cannot validate the old ones just multiplies the problem.
- Start the supplier conversation now. It has the longest lead time and it does not depend on any delegated act being finalised.
None of this is wasted if the dates move again, and dates do move. Typed attributes, clean units, known provenance and a stable identifier make your catalogue better whether or not a passport ever asks for them.
Key takeaways
- A digital product passport is a data model problem. ESPR sets the framework, but the field list and the level of identity come from delegated acts per product group.
- The identity decision, model versus batch versus item, determines your architecture. PIMs handle model level well and item level badly.
- Unique product, operator and facility identifiers mean new governed entities in your data model, not just new columns.
- Responsibility sits with the economic operator placing the product on the EU market, which is often the distributor rather than the manufacturer.
- The real cost is schema design, backfill and supplier data collection. Licences and configuration are the small numbers.
- The technical standards and the EU registry are now in place, so the remaining variable is your catalogue.
We do this work for distributors and manufacturers across the UK, EU and Australia. It always starts the same way, with a look at the actual schema rather than the policy. Want an honest read on how far your product data sits from a digital product passport? Book a thirty minute call and we will go through one affected category in detail.