Digital product passport: stop treating it as an ESG topic, it's an engineering data problem

In February 2027, the European Battery Regulation will impose the first mandatory digital product passport (DPP) at scale: every industrial and electric vehicle (EV) battery above 2 kWh placed on the European market will have to carry an individual digital record, accessible through a unique identifier, describing its composition, carbon footprint, recycled content, performance, and durability. Behind batteries, the Ecodesign for Sustainable Products Regulation (ESPR) is preparing to extend the DPP to entire product families: textiles, steel, aluminum, electronics, and progressively the majority of manufactured products sold in the Union.

The 2026 Digital Omnibus package, which streamlines the European digital regulatory corpus, has not called this trajectory into question: the simplification concerns the modalities, not the principle. The DPP is coming, and February 2027 is seven months away.

Yet almost all public discourse on the DPP files it under "sustainability." The CSR department handles it, with help from legal, and everyone produces slides about transparency, the circular economy, and consumer trust. This article defends a simple thesis: this classification is a diagnostic error that will cost a great deal to the manufacturers who make it. The digital product passport is not an ESG problem. It is an engineering data problem. And it can only be solved at the engineering level.

What the DPP really asks for

Let's look at what the Battery Regulation concretely requires the passport to contain: the identity of the manufacturer and of the battery, its detailed chemical composition including critical raw materials; the share of cobalt, lithium, nickel, and lead sourced from recycling; the carbon footprint calculated according to an imposed methodology, broken down by life-cycle stage; performance and durability (capacity, power, efficiency, expected lifetime); disassembly and safety information for recyclers; and, for certain categories, the state of the battery throughout its life.

Now let's ask the uncomfortable question: in your organization, where is this information today?

The honest answer, for most manufacturers, looks like this. Composition sits somewhere between the PLM bill of materials (BOM), supplier datasheets, and the material declarations collected by purchasing, with gaps. Recycled content sits with tier 2 or tier 3 suppliers, who do not report it systematically. The carbon footprint was calculated once, by a consultancy, on a reference configuration that has evolved since. Performance figures are in the engineering department's test reports. Disassembly information is in the technical documentation, not always updated to reflect the latest design change.

In other words: the data exists, but it is scattered across systems that do not talk to each other, attached to different product versions, and with no formalized link between them. The DPP requires them to be brought together, per individual product or per batch, in a way that is accurate, up to date, and enforceable. This is why it is not a reporting project: it is an engineering data integration project.

The snapshot trap

The natural temptation, faced with the deadline, is to treat the DPP as a one-off exercise: set up a task force, collect the data once, fill in the passport, tick the box. This approach fails for a structural reason: the DPP is indexed on the real product, and the real product changes all the time.

An industrial battery undergoes constant evolutions: a change of cell supplier for cost or availability reasons, a change in chemistry, a modification of the BMS and its software, a new assembly site, per-customer variants. Each of these changes potentially modifies the passport content: composition changes, carbon footprint changes, performance changes, recycled content changes.

If the passport was filled in through a one-off manual collection, every product evolution desynchronizes the passport from reality. And a desynchronized passport is not an administrative detail: it is an inaccurate declaration in the sense of the regulation, enforceable by market surveillance authorities, and verifiable by any customer or competitor who scans the QR code.

The only viable architecture is one where the passport is generated from the engineering repository, rather than maintained alongside it. The bill of materials, the material declarations, the test results, and the supplier data must be linked, versioned objects, of which the DPP is a published view. When the BOM changes, the impact on the passport is identified automatically, because the link exists in the system.

The cascade effect on the supply chain

The DPP has a second consequence that is rarely discussed: it turns data requirements into contractual requirements all along the value chain.

The battery manufacturer is responsible for the passport, but a large part of the data comes from its suppliers: recycled content comes from the material producer, the carbon footprint of the cells comes from the cell manufacturer, and the traceability of critical raw materials comes from the entire upstream chain. To meet its obligation, the manufacturer must therefore obtain structured, up-to-date, and binding data from its suppliers, and attach it to the right components in the right versions of its BOM.

This means that tier 1 and tier 2 suppliers in the battery sector, and then progressively in all the sectors covered by the ESPR, will receive from their customers data requirements that look very much like engineering requirements: format, granularity, update frequency, attachment to product references. Suppliers able to respond to them in an industrial way will become preferred suppliers. The others will become compliance risks that their customers will seek to eliminate.

For a mid-sized industrial company, there are therefore two ways to encounter the DPP: as a manufacturer liable for the passport, or as a supplier required to feed its customers' passports. In both cases, the answer relies on the same capability: having a repository where every component, every material, every version is an identified object, linked to its composition, performance, and origin data.

Why the graph is the right structure

We must insist on a technical point that conditions everything else: the relational nature of the problem.

The DPP of a given battery depends on its exact configuration (which cells, which BMS, which software version), which depends on the BOM applicable at its production date, which depends on the design changes and supplier substitutions, which themselves depend on decisions traced (or not) in the change management process. The carbon footprint depends on the composition, the production site, and the supplier data applicable to the period. Compliance with recycled content thresholds depends on the material batches actually used.

These are not tables, they are dependency chains. The natural data structure to represent dependency chains is a graph: nodes (products, components, materials, requirements, evidence, suppliers) and edges (composition, version, provenance, satisfaction, verification). In a graph, the question "what should the passport of battery serial number X contain?" is a traversal. So is the question "which already-delivered batteries are affected by the update to supplier Y's material declaration?"

This is precisely the architecture of Koddex: a graph-based engineering repository where bills of materials, requirements, compliance data, and traceability live as linked objects. For the manufacturers concerned by the DPP, this architecture turns a dreaded regulatory obligation into a by-product of well-structured engineering.

Seven months: where to start

For manufacturers directly concerned by the February 2027 deadline, the realistic sequence comes down to four steps.

One, the inventory of required data: start from the regulatory list of passport fields and map, for each field, the current source of the data, its owner, its freshness, and its attachment to product versions. This inventory always reveals surprises, usually on the supplier data side.

Two, consolidating the repository: attach all the identified data to a controlled and versioned BOM, treating the highest-volume products first. This is the stage where the tooling choice is decided: a graph-based repository capitalizes on this work, a spreadsheet condemns it to being redone.

Three, upstream contractualization: build data supply obligations (format, deadlines, updates) into supplier agreements, leaning on the regulatory argument that makes the discussion much simpler than before.

Four, automating publication: put in place the generation of the passport from the repository, with versioning, so that every product evolution propagates without manual intervention.

For manufacturers in the later ESPR waves, the deadline is further off but the reasoning is identical, with an advantage: they can learn from the battery sector and structure their repository before the obligation arrives, rather than doing it under pressure.

Conclusion: give engineering back what belongs to it

The digital product passport will be presented for years to come as an instrument of environmental transparency, and it is one. But for the manufacturer who has to produce it, its true nature lies elsewhere: it is the first text that forces the quality of a company's engineering data to be exposed publicly. An accurate, up-to-date, and consistent DPP is impossible to produce durably without a structured product repository. An approximate DPP is a non-compliance that documents itself.

Organizations that hand the topic to their CSR department with an Excel sheet will discover this problem in 2027, under pressure. Those that hand it to their engineering department with a real repository will turn it into an advantage: the same data structure that feeds the passport also feeds impact analysis, certification traceability, and configuration control. The DPP is not one more burden. It is the opportunity to carry out, with a regulatory sponsor, the structuring project that engineering has been putting off for ten years.

Sources

- Regulation (EU) 2023/1542 concerning batteries and waste batteries (Batteries Regulation) (EUR-Lex, Official Journal of the EU, 28 July 2023)
- Regulation (EU) 2024/1781 establishing a framework for ecodesign requirements for sustainable products (ESPR) (EUR-Lex, Official Journal of the EU, 28 June 2024)
- Battery Passport Content Guidance (Battery Pass consortium, December 2023)
- Battery Passport Content Guidance / DIN DKE SPEC 99100 (acatech / Battery Pass consortium, January 2025)
- Implementing the EU Digital Battery Passport (CEPS In-Depth Analysis) (CEPS, via European Commission Circular Economy Platform, 2024)
- Digital Omnibus Regulation Proposal (European Commission, 19 November 2025)

Koddex centralizes bills of materials, requirements, supplier data, and traceability in a graph-based repository. To assess your readiness for the battery and ESPR digital product passport, contact our team.