Digital Product Passport: what manufacturers should prepare now

Somebody in your organization has been asked what the Digital Product Passport will mean for your catalog, and the honest answer so far has been "we are waiting for the delegated act for our product group". That is a reasonable answer about the rules — and a bad reason to wait on the data, because the part you control takes longer to fix than the part Brussels is still drafting.

What is settled, and what is not

The Ecodesign for Sustainable Products Regulation creates the framework for a digital passport: a structured, digitally accessible record about a product's composition, origin, conformity, repair and end of life, linked to the product through a data carrier such as a QR code. It does not switch passports on for all products at once. Which products, which fields, at which granularity and from when is set per product group in delegated acts, expected progressively. Batteries follow their own regulation on their own schedule.

So the field list for your products is genuinely unknown today. This article makes no claim about which date applies to you — check the current legal texts and guidance for your product group, and take legal advice.

What is knowable is the mechanism, and it is stable across every draft we have read:

• structured data, not PDFs
• a unique, resolvable identifier per model, batch or item
• a data carrier that points to it
• differentiated access — the public sees less than a recycler, who sees less than a market surveillance authority
• a history that shows what the record said on a given date

Each of those is a data-architecture problem you can start on Monday, independent of the final field list.

Step one: granularity and identifiers

The first question a passport profile asks is not "which fields" but "what is a passport of". Model, batch, or individual item.

This choice propagates everywhere. Batch-level passports require production or ERP batch identifiers that reach the passport record — so they must exist, be stable and be linkable to the article. Item-level means serial numbers on the label and a record per unit. Model-level is cheapest and may not satisfy the act for your group.

In our experience this is where projects lose the most time, because the answer usually differs per product line: a housing component can be model-level while anything with a declared recycled content or a safety certificate wants batch-level. Decide per product group now, and note whether the identifier you would need already exists or would have to be created.

Audit your identifiers before your fields

Passports are resolvable links. That puts unglamorous identifier hygiene on the critical path:

• GTINs. Are they complete, correct, and stored in one place your systems agree on? Passport links are built on them; a GTIN that lives in three systems with two spellings becomes three passports.
• A resolver domain you own. The passport URI should sit on your own domain, so links printed on packaging in 2027 still work when you replace a system in 2031. A GS1 Digital Link URI encodes the GTIN and, where relevant, the batch or serial — the resolver decides what the requester gets.
• Article-to-batch linkage. If you go batch-level, something must join the ERP batch to the PIM article without a spreadsheet.
• Document identity. Declarations of conformity and test reports need stable references, not filenames like DoC_final_v2_NEU.pdf.

None of this requires the regulation to be final. All of it takes months.

Step two: map the domains you hold — and the gaps you don't

Most passport content is not new. It is scattered. Working through the domains that recur across the drafts, a typical manufacturer finds:

• Identification — product, model, batch or item ID, GTIN, manufacturer and importer: mostly in PIM and ERP.
• Materials and composition — main materials, recycled content, substances of concern where required: partly in PIM, largely with suppliers.
• Origin and supply chain — country of origin, production site, supplier declarations: ERP and supplier correspondence.
• Conformity — declarations, certificates, test reports, applicable standards: document management, often as PDFs with no structured link to the article.
• Environmental performance, use and safety, repair and spare parts, end of life — spread between PIM, technical documentation and the service organization.

Do this as a written inventory with one column that matters more than the rest: expected source. Not "we probably have it" but "ERP field X" or "supplier declaration, not collected". The fields with no source are your actual project — in practice most often recycled content and country of origin, and supplier data collection is a quarters-long exercise, not a sprint.

A manufacturer with 12,000 articles finds that 79 % of them are passport-ready under a draft profile, and the remaining 21 % are held by four recurring fields — of which one has to be requested from suppliers.

That is the shape of the problem: not thousands of unique gaps, but a handful of fields missing across many products. It is tractable once you can see it per field rather than per product.

Step three: treat access levels as an entitlement problem

A passport is not a public dump. The same record serves a consumer scanning a code, a repairer, a recycler and an authority — and they are not entitled to the same fields. Substances-of-concern detail, supplier declarations and test reports are typical examples of fields that are not public.

This is worth naming early because it determines where the passport can live. A static file on a web server cannot express per-field access. What you need is the same mechanism a decent product portal already has: identity, role, and a rule that filters fields per requester. If you already operate customer or supplier portals with entitlements, that engine is reusable — which is one reason we build the passport module on the same entitlement layer as the customer portal, rather than as a separate publishing tool.

Step four: make history a property of the system

The awkward question is not "what does the passport say" but "what did it say in March, when that batch shipped". Answering it needs three things that are cheap to design in and painful to retrofit:

• Versioned records. A change to a passport field creates a new version; the carrier resolves to the current one while earlier versions stay retrievable for authorized users.
• An append-only audit log. Who changed what, when, and why — not editable after the fact.
• Open-format export. Passports may need to remain available for many years, which is longer than most software contracts. Being able to export the full record set in an open format is your insurance against that.

If you already run versioned exports and field-level comparison for your channels, you have most of this. If your current answer to "what did we publish on 14 March" is a backup tape, that is the gap.

What to do this quarter

Pick one product group. Write the granularity decision down. Inventory the domains with expected sources. Run a gap count per field. Start the supplier request for the one or two fields nobody holds internally. None of that is wasted under any version of the final act, because none of it depends on the field list.

The regulation will tell you what to publish. Nothing about it will make your identifiers cleaner or your supplier data arrive. See how the passport module assembles records from existing sources, or book a demo to walk through a gap report on your own product group.

Key takeaways

• Rules arrive per product group; the mechanism — identifiers, structured fields, carrier, access levels, history — is stable and can be prepared now.
• Granularity (model, batch, item) is the first and most expensive decision; it differs per product line.
• Identifier hygiene, especially GTINs and a resolver domain you own, is on the critical path and takes months.
• Inventory passport domains by expected source; the fields with no source — usually recycled content and origin — are the real project.
• Per-field access levels make a passport an entitlement problem, not a publishing problem.
• Versioning and an append-only audit log are cheap to design in and painful to retrofit.