Digital Product Passport Development

The problem this solves

The Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, entered into force in July 2024 and creates the legal framework for the Digital Product Passport. The regulation itself does not impose passport requirements on any specific product; those arrive through delegated acts adopted per product group, with the first working plan prioritising categories including textiles, iron and steel, aluminium, furniture and tyres. Batteries sit under a separate and earlier instrument, Regulation (EU) 2023/1542, which establishes a battery passport obligation from February 2027.

Read as engineering rather than as policy, this resolves into a fairly specific system. Products need persistent unique identifiers at the right granularity — model, batch or item — which is itself a decision with cost and traceability consequences. Those identifiers need a physical data carrier, typically a GS1 Digital Link encoded in a QR code or Data Matrix. Behind the identifier sits versioned, structured product data with access differentiated by actor. And all of it has to remain available and verifiable for a defined period, surviving system migrations and supplier changes.

In practice the hardest part is never the passport API. It is obtaining accurate material composition and lifecycle data from suppliers who have never been asked for it in a structured form, and who may be several tiers removed from you.

What we build

• Identifier strategy: choosing model, batch or item granularity and serialisation approach
• GS1 Digital Link URI design and resolver implementation
• Data carrier generation and print verification for QR and Data Matrix codes
• Passport data modelling in JSON-LD for genuine machine readability
• EPCIS 2.0 event capture for lifecycle and chain-of-custody events
• Tiered access control across public, repairer, recycler and authority roles
• Supplier data onboarding pipelines, including validation and gap handling
• Long-lived storage with versioning, immutability and defined retention

How we approach it

1. 01

   Establish the regulatory scope precisely

   We start with which delegated act applies to your product category and what it actually requires. This prevents both over-building and the more common failure of building the wrong thing confidently.

2. 02

   Decide identifier granularity

   Model, batch or item level is the foundational decision. It determines serialisation cost, printing requirements and how much traceability you can ever offer, and it is very expensive to change later.

3. 03

   Model the data before choosing tools

   Passport data must be interoperable, so we model it in JSON-LD against established vocabularies rather than inventing a schema that only your systems understand.

4. 04

   Solve supplier data early

   This is the critical path on almost every programme. We build the intake, validation and gap-handling pipeline first, because the passport is only as good as the data reaching it.

5. 05

   Implement access tiers explicitly

   Consumers, repairers, recyclers and market surveillance authorities see different views. Building this as an afterthought produces either data leakage or a passport authorities cannot use.