The Digital Product Passport: what to build before the rules are final

The Digital Product Passport arrives under the Ecodesign for Sustainable Products Regulation, which replaced the old Ecodesign Directive and widened its scope from energy-related products towards almost everything physical sold in the EU. The passport itself is simple to describe: a data carrier on the product, its packaging or its documentation, pointing at a structured record about that item.

What it contains, for your product, is set by a delegated act specific to your product group — and for most groups that act is not published yet. Which is exactly why so many teams have decided to wait, and exactly why waiting is the expensive choice.

Timelines and product-group requirements are still moving. Nothing here is legal advice, and the working plans and delegated acts in force for your category are the authority — not this page. What follows is an engineering read of what is stable enough to build against.

What is already settled

The framework does not change per product group, and it is enough to design against.

• Every item needs a unique product identifier, and the economic operator and the facility behind it need identifiers too. These are relationships, not fields — one product links to an operator, a facility, and often a specific batch.
• The record is reached through a data carrier — a QR code, NFC tag or similar — physically attached to the product, its packaging or its documents.
• Access is tiered. Some data is public, some is for market surveillance authorities, some for actors along the value chain. The same passport shows different things to different readers.
• A registry sits in the middle. Passports are not just files you host; they are registered and discoverable.
• The passport has to survive the product. It stays available for the product's lifetime, which is longer than most of the systems currently holding your product data.

Every one of those is a data modelling decision. None of them is a decision about what your delegated act will eventually require you to disclose.

The first hard date most people miss

ESPR is the framework everyone discusses, but the first passport obligation to bite is not under ESPR at all. The EU Batteries Regulation carries its own battery passport requirement, with a date in early 2027 that has been fixed for some time.

If your product contains an industrial or EV battery, that date is your date, and it is closer than the ESPR conversation implies. If it does not, the battery passport is still worth watching, because it is the working prototype of everything ESPR will generalise: identifiers, carrier, tiered access, registry.

Why waiting costs more than starting

Sort the work by how long it takes and the argument for waiting disappears.

The only row that genuinely depends on the delegated act is the cheapest one. Everything expensive — identity, lineage, supplier data — is required no matter what the act says, because the act can only change which fields you must publish, not whether you are able to answer for a given item at all.

The part nobody costs correctly: supplier data

A passport asserts things about materials, origin, composition and repairability. Most of that is not in your systems. It is in a supplier's spreadsheet, a PDF certificate, or an email from two years ago.

Collecting it once is a project. Keeping it current as suppliers, batches and formulations change is an operating process, and it is the thing that takes quarters rather than weeks. Teams that start when the delegated act lands discover this after the clock has already started.

What to build now

Four things are safe to build before the rules are final, because they are prerequisites under every plausible version of them.

• Stable item identity. Every unit or batch you sell needs an identifier that never changes and never gets reused, held somewhere that is not the storefront. Most catalogues today identify a listing, not a physical item — those are different things and only one of them can carry a passport.
• A separate passport record. Do not extend the product table. Passport data has a different lifecycle, different access rules and a longer retention period than commerce data, and it will outlive the platform the shop runs on.
• Versioning from the first row. Passports are read years after they are issued, and the reader is entitled to what was true at the time. That means append-only history, not an updated row.
• Access control at the record level. Public, authority and value-chain tiers are in the framework already. Retrofitting that onto a record designed as public is more work than building it in.

Do those, and the delegated act becomes what it should be: a mapping exercise. Skip them, and it becomes a data programme running against a legal deadline.

Where this lands in a commerce stack

For most sellers the product data lives in a store platform that was never designed to be a system of record for regulatory claims. WooCommerce and Shopify identify listings, mutate rows in place, and treat product data as presentation. All three assumptions are wrong for a passport.

That does not mean replacing the platform. It means the passport record lives beside it with its own identity and history, and the store links to it rather than owning it. We build it that way in our own products, and it is the difference between a passport you can still answer for in 2031 and one that broke the first time a supplier changed.

We run EU Digital Product Passport compliance in commercial software, alongside ZATCA Phase 2 and UAE EIS. If you are working out what your product group will require, or you have a battery date already, send us the system and we will tell you what actually has to change.