What a Digital Product Passport asks of your catalog
A Digital Product Passport is a structured data record, not a label. It has to be machine-readable, kept current and readable by other systems. Many catalogs aren’t built that way.
On this page
The EU Digital Product Passport (DPP) rules arrive category by category. As of September 2026, the battery passport is set to apply from February 2027 to EV and light-transport batteries, and to industrial batteries over 2 kWh. Textiles, steel, tires and furniture are next under the EU Ecodesign for Sustainable Products Regulation (ESPR), each on its own delegated act.
The passport reads as a sustainability rule. In practice it sets a shape for your product data. A product in a category the rules cover will carry a machine-readable identity record that regulators, consumers, recyclers, marketplaces, and AI systems can read. The record is meant to be structured, traceable, and kept current.
So this is not a compliance gap. It is a data gap. Closing it means changing how your product records are structured, who checks them, what history they keep, and how other systems read them. That is commerce infrastructure, not paperwork, and DPP readiness is the work of building it under a deadline.
A passport is a data record, not a label.
A Digital Product Passport is not a PDF. It isn’t a QR code. It isn’t a sustainability report reformatted for a product listing.
A DPP is a structured, machine-readable record, reached through a unique digital identifier. It states verified, lifecycle-aware information about a product model, batch or single item, depending on the category’s rules. Materials composition. Manufacturing origin. Carbon footprint. Repairability score. End-of-life instructions. Supply chain certifications.
A record like that changes five things:
- Products get machine-readable identities. Not a barcode, but a record software can query, check, and act on.
- Lifecycle data becomes an attribute like any other. It changes as the product moves through production, distribution, use, and disposal, so it is never finished.
- Traceability moves into the product record itself, from the day the record is created, instead of being reassembled during an audit.
- Other systems have to be able to read it. Regulators, marketplaces, recyclers, AI systems, and consumers all take DPP data through standardized schemas.
- Sustainability claims need checking on an ongoing basis, not one certificate at the start.
Together that changes how products are managed, how data moves between companies, how compliance is enforced, and how AI systems read product information. This is not sustainability reporting with extra fields. It is a different way of running the catalog.
The data isn’t in the right shape.
The gap is structural. The data isn’t held in the form the rules want, isn’t in the systems that would expose it, and has nobody assigned to check it.
Scroll sideways to see the whole table.
| What the DPP asks for | What that means in data | Where it sits today | Why that is a problem |
|---|---|---|---|
| Product identity | GTIN, model, manufacturer, facility of origin, each tied to a unique digital identifier for the product model, batch or item | ERP, in pieces. MDM, if there is one. Otherwise several spreadsheets. | Nothing holds the canonical identity record on its own. A DPP needs one place that does. |
| Materials and composition | Bill of materials, substance percentages, recycled content ratio, typed and machine-readable | Product lifecycle management (PLM) systems, supplier PDFs, consultant reports, Excel files | It sits in documents rather than databases. Nothing can query it, check it, or serve it over an API. |
| Carbon and environment | Product carbon footprint, energy class, water usage, per product rather than per company | Sustainability team spreadsheets, third-party calculators, annual reports | The per-product figure often does not exist, and a company-level average does not meet what the DPP asks for. |
| Durability and repairability | Expected lifetime, repair instructions, spare part availability, structured and version-controlled | Service manuals as PDFs, engineering documentation, or nowhere | Not held as product attributes. Not linked to the product record. Not kept current over the product’s life. |
| End-of-life | Disassembly instructions, recyclability score, collection point references | Often nowhere at all | The whole category often has to be created from scratch. |
| Supply chain traceability | Supplier names, certifications, due diligence results, origin verification | Procurement systems, with no link to the product catalog | The traceability data sits in a different system from the product data, and nothing joins the two. |
The pattern repeats down the table. DPP wants structured, traceable data per product, at a level of detail many organizations have never held. One record, queryable, checked as it changes, readable by outside systems. Many companies have no system that does this.
What makes DPP hard in practice.
Teams that see the gap still underestimate the work of closing it. The recurring snags fall into three groups.
The first is the supplier data itself. Suppliers tend to send sustainability information in their own formats: PDF certificates, Excel sheets, email attachments, portal uploads. Turning hundreds of those into one set of fields is not a one-off import, it is a standing job. Materials are classified differently across product lines, so “cotton blend” in one category is “52% cotton / 48% polyester” in another, and DPP wants one machine-readable composition, not free text. For complex products, tracing materials to their origin across 4-5 tiers of supply chain is brutal work. Past tier 1, the data often doesn’t exist. Inside the company it is split too: product identity lives in ERP, commercial attributes in PIM if you have one, engineering data in PLM, sustainability data in spreadsheets. DPP needs them in one record. Often nothing joins ERP, PIM and PLM together.
The second is history and checking. Product records are often snapshots, not timelines. When did the formulation change? When was a component supplier replaced? Many product systems never kept that trail, and without it you can’t show a value was right when it was published. Then there are claims nobody has checked. Who verifies that a supplier’s carbon footprint claim is accurate? What check catches an impossible recycled content percentage? DPP claims carry legal liability, so storing the number isn’t enough. Someone has to approve it.
The third is that the ground keeps moving. DPP requirements vary by product category and timeline, and national rules such as France’s add their own disclosures. All of it comes off the same product record. The same product sold on Amazon, on your own site, and in a shop needs the same DPP data in each place. Where the channels disagree, you are exposed. The technical standards are largely published, but what each category must disclose is still being set, one delegated act at a time. Attribute definitions will expand, and your setup has to absorb that without a migration project for each update.
This is a product data problem.
Many organizations treat DPP as a sustainability initiative. They give it to the CSR team, hire consultants, or build a one-off reporting tool. That puts the work in the wrong place.
DPP lands on the product record, for six reasons:
- Each product needs a unique digital identifier pointing at a structured record. That is product identity.
- The record holds typed, validated attributes across commercial, sustainability, regulatory and lifecycle domains. That is product information management.
- Data arrives from suppliers, ERP, PLM, people typing, and AI extraction, and it passes a check before it enters the record. That is the approval step.
- The record keeps going for the product’s whole life, including after the sale. That is lifecycle data management.
- Regulators, marketplaces, consumers, recyclers and AI systems all read the record through standard interfaces. That is interoperability.
- Changes are auditable, traceable and reversible. That is the audit trail.
A PIM is a natural home for most of the passport’s data. Not an ERP, not a sustainability reporting tool, not a spreadsheet with a QR code generator bolted on. The identifier, the data carrier and the hosting usually sit with a DPP service provider.
DPP work is also AI work.
The data work DPP compliance needs is the same data work AI systems need to read your catalog. You are not only buying compliance. You are building something you can use elsewhere.
Scroll sideways to see the whole table.
| What the DPP record needs | Where AI work needs the same thing |
|---|---|
| Structured, typed attributes per product | AI enrichment agents need a schema to write against if the output is to be reliable. Give them loose text and they invent. |
| Machine-readable product identity | AI shopping agents read the product data merchants expose to them, through feeds and store catalogs. A structured identity makes a product easier for them to find. |
| Lifecycle traceability | AI compliance checks can run as the data changes, rather than once a year in an audit. |
| Data other systems can read through an API or the Model Context Protocol (MCP) | Conversational commerce depends on AI systems reading rich, structured product context. DPP data is what makes a product explainable to them. |
| Checks that run every time, not once | Enrichment pipelines that run on their own need validation gates, the same kind of gate a sustainability claim in the passport needs. |
| Supply chain traceability data | AI-driven demand forecasting and risk work read the same supplier data the DPP asks for. |
| One schema across the catalog | Marketplaces may start checking product metadata automatically before a listing goes live, DPP completeness included. |
The overlap is not a coincidence. DPP wants structured, checked, traceable, machine-readable product data. So does an AI agent reading your catalog. Build the DPP record properly and you are building for AI at the same time, whether you planned it or not.
Treat DPP as the minimum that passes, with static values in the fields and QR codes pointing at PDFs, and none of that carries over. You comply now and rebuild later.
What DPP readiness actually needs.
A DPP-ready setup has five parts:
1. A typed product record.
One schema that holds commercial, sustainability, regulatory and lifecycle attributes together, each one typed and validated. Not a flat spreadsheet of free-text columns. In a typed record, “recycled_content_pct” is a numeric field with validation rules, a unit, and a note saying where the value came from.
2. Imports from everywhere.
DPP data comes from several places. Supplier portals hold material certifications. ERP holds manufacturing origin. PLM holds engineering specifications. Sustainability tools hold carbon calculations.
Each import maps its fields to the product schema, settles conflicts against what is already there, and writes into one record. Without that, DPP data stays in fragments nobody can assemble.
3. Checks before a value publishes.
Each sustainability claim in a DPP carries legal liability. “This product contains 40% recycled content” has to be verified, approved, and traceable back to a supplier certificate.
So the record carries its own rules. Which validation applies to each attribute. Who can approve a change. What evidence has to be attached. What the audit trail records. Without that, DPP claims can’t be verified, and an unverifiable claim is regulatory risk.
4. History, not snapshots.
Products are not static. Materials change. Suppliers change. Formulations improve. A DPP-ready record shows the product as it is now and keeps what it was before.
That means the record answers three questions. When did the composition change? What triggered the update? Who approved it? A change history is how you show a value was right when it was published.
5. Readable by other systems.
DPP data has to be readable by systems outside your company. Marketplace validation systems. Consumer-facing apps. Recycler databases. AI agents. And the EU DPP Registry, which holds each passport’s identifier while the data is served from your side.
That is not “export to CSV.” It is API access to the structured record, through interfaces that follow the harmonized DPP standards (the EN 18xxx series), with identifiers such as GS1 Digital Link where used. A system can query the metadata without a person reading it first.
Before and after.
CataZenta’s Digital Product Passport agent flags missing EU Digital Product Passport data on the products it checks and suggests only values your catalog already states. CataZenta covers part of the right-hand column below: typed attributes, range and format checks on each attribute in the editor, and product version history. It doesn’t read certificates, check values against a bill of materials, or create passports, passport identifiers, QR codes or registry records.
Scroll sideways to see the whole table.
| Scenario | Before, scattered | What a DPP-ready setup does |
|---|---|---|
| Supplier sustainability data collection | Email the suppliers. Get back PDFs and Excel files. Re-key the values into a spreadsheet by hand. Nothing checks them. Nothing standardizes them. Do it again next year. | Supplier templates that set out the required fields. Data enters a PIM through saved mappings and is checked on the way in. Certificates reviewed by people. It runs through the year, not once a year. |
| Material composition validation | Take the supplier claim at face value. Find the errors during a regulatory audit. Nothing compares the declared composition against the actual BOM. | Validation rules flag impossible values: percentages over 100%, compositions that do not add up. The declared composition is checked against the BOM. Exceptions go to a person to decide. |
| Marketplace DPP readiness check | “Does our catalog meet a marketplace’s DPP requirements, once it publishes them?” Then a manual audit. | Checked against those requirements, with the gaps listed per product. |
| Product reformulation impact | Materials change. The sustainability team hears weeks later. The DPP record is not updated. The exposure runs for months, until somebody remembers. | The new composition arrives with the PLM export. Material attributes are revised and reviewed, the passport data is updated, and the previous version stays in the history. No months of stale records. |
| Cross-border compliance | France asks for environmental disclosures on textiles that other markets don’t. Which products need what? Someone tracks it in a compliance spreadsheet. | The required attributes are set per product category and per market. The catalog is checked against them, and the gaps come out per market, per product. |
| Regulatory audit preparation | “Show auditors our passport data for every battery model we place on the EU market.” Then a long manual job of piecing the data back together by hand. | One report covering every product in the category and the markets in scope, each with its version history behind it. A report, not a project. |
The dates are close. The work compounds.
Battery passport rules are adopted. Textiles come next, on a later timetable.
If your catalog is large, this is a multi-quarter program at minimum. You build the data structure, collect the required attributes across your supply chain, then check the values across thousands of products.
The deadline is the smaller half of the argument.