What Is a Digital Product Passport? EU ESPR Explained

What the regulation actually says, and what it does not

The Ecodesign for Sustainable Products Regulation — Regulation (EU) 2024/1781, usually shortened to ESPR — entered into force in July 2024. It replaced and considerably broadened the earlier Ecodesign Directive, and it establishes the legal framework for the Digital Product Passport. That word 'framework' is doing a great deal of work in that sentence, and misreading it is the most common mistake teams make when they first encounter this.

ESPR does not, by itself, impose passport requirements on any specific product. It creates the mechanism through which such requirements are set, product group by product group, via delegated acts. The Commission's working plan identified priority categories including textiles, iron and steel, aluminium, furniture and tyres, with obligations phasing in from around 2027 onward. Batteries are governed separately and earlier, under Regulation (EU) 2023/1542, which establishes a battery passport obligation from February 2027.

The practical consequence is that there is no single universal DPP compliance date, and anyone who tells you otherwise has not read the instrument. What matters for your organisation is the delegated act covering your specific product category, which determines both the timing and the data requirements you will actually face.

What a passport has to do, in engineering terms

• Carry a persistent unique identifier at model, batch or item granularity depending on the product
• Expose that identifier through a physical data carrier, typically a QR code or Data Matrix
• Resolve to structured, machine-readable data rather than to a human-readable marketing page
• Differentiate access by actor: consumers, repairers, recyclers and market surveillance authorities
• Remain available for a defined period, surviving system migrations and supplier changes
• Support updates over the product lifecycle without losing the historical record
• Interoperate with other implementations, which in practice means using open standards

The identifier decision is the one that matters most

Of all the technical decisions in a passport programme, identifier granularity is the one that is genuinely expensive to reverse. You can identify at model level, meaning every unit of a product shares one identifier; at batch level, meaning a production run shares one; or at item level, meaning every physical unit is uniquely serialised.

Model level is cheap and gives you almost no traceability, because you cannot distinguish one unit from another when a defect or a recall arises. Item level gives you full traceability and imposes real cost: unique codes must be generated, printed, verified and tracked through manufacturing, which touches production line equipment and often the physical packaging process. Batch level is the usual compromise and is frequently what the delegated act effectively assumes.

The reason this matters so much is that changing it later means re-serialising, reprinting and reconciling everything already in the field. Making this decision deliberately, with the delegated act in front of you, is the highest-leverage hour a passport programme will spend.

Why supplier data is the real bottleneck

Teams consistently underestimate this, and it is worth stating plainly: the passport infrastructure is tractable engineering, and the supplier data is not. Building an identifier scheme, a resolver, a JSON-LD data model and a tiered access API is a few months of competent work with well-understood standards.

Obtaining accurate material composition data from a tier-two supplier who has never been asked for it in a structured form, who may consider it commercially sensitive, and who may themselves not know because their own supplier has not told them, is a different kind of problem entirely. It is a procurement and relationship problem wearing a data problem's clothing, and no amount of engineering elegance resolves it.

The programmes that succeed start the supplier data workstream first, in parallel with everything else, and design the passport to handle gaps explicitly — with documented proxy methodology and disclosed uncertainty rather than silent estimates. The programmes that struggle build beautiful infrastructure and then discover, six weeks before a deadline, that they have nothing accurate to put in it.

Part of the Circular Economy & Digital Product Passports cluster · Read the pillar page