Digital Product Passport Development: DPP and Battery Passport Implementation for ESPR

Most companies discover the Digital Product Passport the same way: someone forwards a customer questionnaire, or a retailer asks which identifier will be printed on the label next year, and it becomes clear that a regulation everyone filed under "sustainability" is actually a software project with a date attached.

We build that software. Data models, identifiers, the API behind the QR code, the integration into whatever PLM or ERP already holds your product data, and the registration record the EU registry expects. Not the legal opinion on scope (your compliance team or counsel handles that), but everything downstream of it.

What the Digital Product Passport actually requires

The Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781) replaced the old Ecodesign Directive and extended it from energy-related products to almost everything sold in the EU. Its central mechanism is the Digital Product Passport: a structured, machine-readable record attached to a product, a batch or an item, reachable from a data carrier on the product itself.

Stripped of the policy language, a DPP is four engineering problems:

A unique identifier for the product, model, batch or item, issued under a recognised scheme and stable for the product's whole life.
A data carrier (in practice a QR code, sometimes NFC or an RFID tag), that resolves to that identifier. GS1 Digital Link is the syntax most supply chains are converging on, because it lets one QR code serve the consumer, the retailer's scanner and the recycler with different responses.
A data set defined by the delegated act for your product group: material composition, substances of concern, durability and repairability information, recycled content, carbon footprint, spare parts availability, end-of-life instructions. Different fields are visible to different audiences, and access control is part of the specification rather than a nice-to-have.
A registration in the central EU registry, plus the obligation to keep the passport available for a defined period, including after your company stops selling the product, which is a hosting and continuity problem more than a coding one.

The framework became fully applicable on 19 July 2026, and the EU's central DPP registry went live with it. That switched on the machinery. What binds any individual company is the delegated act for its own product group.

The dates that matter

The first hard obligation is not textiles or furniture. It is batteries, and it arrives under the Battery Regulation rather than ESPR itself.

18 February 2027: the battery passport becomes mandatory under Regulation (EU) 2023/1542 for electric vehicle batteries, industrial batteries above 2 kWh, and LMT (light means of transport) batteries. Every such battery placed on the EU market from that date needs a passport, accessible through a QR code, with carbon footprint, material composition, recycled content, state of health and due diligence information.
2026 onward: the ESPR first working plan (COM(2025) 187) puts iron and steel first among the priority groups, with textiles, tyres and aluminium following, then furniture and mattresses. Each product group gets its own delegated act, and each act sets its own transition period: typically eighteen months to two years between adoption and application.

If you make batteries or put them into vehicles, machinery or e-bikes, the clock is measured in months. If you make textiles, steel, tyres or furniture, the clock is measured in delegated acts, and the useful move now is building the data foundation rather than waiting for the field list.

What we build

Product data model and gap analysis

We start from your existing data, not from a blank schema. Most manufacturers already hold seventy per cent of what a passport needs, scattered across PLM, ERP, supplier declarations, test reports and spreadsheets nobody has touched since the last audit. We map what exists against the requirements for your product group, and the output is a gap list naming the specific fields you cannot currently produce and where each one would have to come from: usually a supplier who has never been asked for it.

That document is often more valuable than the software that follows, because it turns a vague compliance worry into a procurement task with names against it.

Identifier and data carrier implementation

We implement the identifier scheme (GS1 GTIN plus serial or batch qualifiers, or an alternative issuing scheme where your sector uses one), and generate the resolvable links behind it. Where a single QR code has to serve several audiences, we build the resolver so that a consumer's phone, a retailer's system and a recycler's scanner each land on the response appropriate to them, with the restricted fields gated behind authenticated access.

The passport service itself

A DPP is an API and a public-facing view, not a PDF. We build both: a service that holds the passport data, versions it, serves it under the identifier, and renders a human-readable page in the languages your markets require. It has to stay online and stay correct for years, so we build it as a small, boring, well-monitored service rather than a feature inside something larger that might be retired.

Integration with the systems you already run

Passport data has to be fed, not typed. We build the integrations into SAP, Dynamics, Odoo, Infor, custom ERPs, PLM systems such as Siemens Teamcenter or PTC Windchill, and the supplier portals and quality systems that hold the rest. Where suppliers submit data by email and spreadsheet (which is most of the time, at first), we build the intake and validation layer that turns that into structured records without a person retyping them.

Registry registration and reporting

We handle the technical side of registering passports with the EU registry, keeping the registration in step with product changes, and producing the evidence trail that shows what was published when. Where your customers run their own supply-chain data requests, we build the export paths so answering them is not a project each time.

What this is not

We do not sell a DPP platform with a per-product licence. There is a growing field of those, and for a company with a simple catalogue and standard data one of them may well be the right answer. We will say so.

What we do is the case those platforms handle badly: products with complicated bills of materials, data spread across systems that were never meant to talk, identifier schemes that have to coexist with an existing labelling system, or a manufacturer who needs the passport service to live inside their own infrastructure for data-sovereignty reasons.

We also do not give legal advice on scope, classification or conformity. We work alongside the people who do.

Sectors we work with

Battery and e-mobility manufacturers facing the February 2027 date, including vehicle, e-bike, scooter, and industrial storage producers, and the cell suppliers feeding them.

Textile and apparel brands preparing for the textile delegated act, where the hard part is nearly always the supply chain data rather than the passport itself.

Steel, aluminium and construction products, where environmental product declarations and material passports already exist in some form and the work is reconciling them with the ESPR data model.

Electronics and appliances, which sit at the intersection of ESPR, the Cyber Resilience Act and existing energy labelling, and generally want one data programme rather than three.

Furniture, tyres and consumer goods, where the delegated acts are further out and the sensible investment now is the identifier scheme and the data pipeline.

How an engagement usually runs

The first step is short and fixed-price: a product passport readiness assessment, typically two to three weeks. We work through your product structure, your data sources and the applicable requirements, and deliver a gap analysis, a proposed data model, an identifier and carrier recommendation, and a build plan with costs.

Most clients then run a pilot on one product line: a single SKU family, end to end, from data ingestion through to a scannable QR code and a registry entry. A pilot proves the model against reality, which is when you find out that a supplier cannot provide recycled content percentages and that a decision has to be made about it.

Rollout follows, product group by product group, with the integrations widened and the manual intake progressively replaced. Then we either hand over to your team with documentation, or keep running the service under a support agreement: passports have to stay available long after the project ends, and someone has to own that.

Standards and frameworks we work to

ESPR, Regulation (EU) 2024/1781, and the delegated acts adopted under it
Battery Regulation (EU) 2023/1542, Article 77 and Annex XIII
GS1 Digital Link, GTIN, and the GS1 EPCIS event standard where traceability is required
CIRPASS reference architecture and the emerging CEN/CENELEC JTC 24 standards
ISO/IEC 15459 identifiers, ISO 14040/14044 where carbon footprint data enters the passport
W3C Verifiable Credentials, where data authenticity between supply chain partners matters

Technology

Node.js, Python, Go and Java services; PostgreSQL and event-sourced stores where passport history has to be reconstructible; REST and GraphQL APIs; AWS, Azure and European sovereign hosting including on-premise deployment where required. We build to run in your cloud account, not ours, unless you would rather we host it.

Frequently asked questions

When does the Digital Product Passport become mandatory?

There is no single date. ESPR became fully applicable on 19 July 2026 and the EU registry is live, but the obligation for a given product only starts when the delegated act covering that product group applies. The first mandatory passport is the battery passport, on 18 February 2027, under the Battery Regulation. Iron and steel, textiles, tyres and aluminium follow through the ESPR working plan, each with its own transition period.

Does the Digital Product Passport apply to us if we are not an EU company?

If you place products on the EU market, yes. The obligation attaches to the economic operator putting the product into circulation in the EU, which may be your importer or authorised representative, but the data has to come from you, and in practice the manufacturer builds the passport.

Can we not just put a QR code on the label linking to our product page?

No. The passport has to carry a defined data set in a machine-readable form, use an identifier from a recognised scheme, be registered with the EU registry, remain available for a set period, and expose different fields to different audiences. A marketing page behind a QR code satisfies none of that.

We already publish environmental product declarations. Is that enough?

It is a strong start, and it usually means the hardest data is already collected. The work is mapping it to the passport data model, giving products stable identifiers, and building the service that serves the data on demand rather than as a PDF download.

How long does an implementation take?

A single-product-line pilot generally runs six to ten weeks from a completed readiness assessment. Full rollout across a catalogue depends far more on data availability than on engineering, and the supplier data collection is almost always the critical path.

Where does the passport data live?

Wherever you need it to. We build the service to deploy into your own AWS or Azure account, into European sovereign infrastructure, or on-premise. The EU registry holds registration records, not your product data.

Get started

Send us your product range and the group you think you fall under, and we will tell you whether a passport obligation is likely to reach you, when, and what your data would need to look like. If the honest answer is that an off-the-shelf platform serves you better, we will say that too.

Related services

EU Market Entry Development: the wider compliance stack for companies selling into Europe
Legacy System Code Maintenance: where the product data is trapped in a system nobody wants to touch
Staff Augmentation & Outsourcing: engineers who join your team for the duration of the programme