The Digital Product Passport Is Not an ESG Project. It Is an Engineering Data Problem.

Most of the content published about the EU Digital Product Passport comes from sustainability platforms, and it shows. The DPP is framed as a reporting exercise: collect carbon footprints, run lifecycle assessments, publish a QR code, done. That framing is convenient for ESG software vendors. It is also wrong, or at least dangerously incomplete, for anyone who builds regulated hardware.

Read the actual legal texts and a different picture emerges. The DPP is, at its core, a mandate to expose structured, per-product engineering data to third parties: unique identifiers, material composition down to substances of concern, technical documentation, declarations of conformity, disassembly instructions, test results. Carbon footprint is one field among roughly ninety. The rest is data that lives, today, in your requirements tool, your BOM, your certification binders, and an uncomfortable number of spreadsheets.

For engineering organizations in robotics, energy storage, electric aviation, and industrial machinery, the DPP deadline is therefore not a question for the CSR department. It is a stress test of the engineering data architecture. This article walks through what the regulation actually requires, why conventional toolchains will struggle to produce it, and what a defensible data foundation looks like.

What the law actually says

Two legal instruments matter, on two different clocks.

The framework is the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781 (ESPR), in force since 18 July 2024. Articles 9 to 15 establish the Digital Product Passport as the EU's primary vehicle for product information requirements. The ESPR itself does not impose passports on any specific product. Instead, the Commission adopts product-specific delegated acts that define, category by category, which data must be published, in what format, and by when. The first Working Plan (COM(2025) 187, adopted 16 April 2025) prioritizes iron and steel (delegated act expected 2026), then textiles, tyres, and aluminium (2027), with furniture, mattresses, and horizontal repairability and recyclability measures following through 2030. Delegated acts typically leave 18 to 36 months between adoption and mandatory compliance, which puts the first ESPR-driven passports around 2028.

The hard deadline, however, comes from sector law that predates the ESPR rollout. Under Article 77 of the Battery Regulation, Regulation (EU) 2023/1542, every EV battery, every light means of transport battery, and every industrial battery above 2 kWh placed on the EU market must carry a digital battery passport from 18 February 2027. This is a fixed statutory date, directly applicable in all 27 member states, with no national transposition and no grace period. A battery without a compliant passport cannot legally be placed on the market after that date.

Two properties of the battery passport deserve close attention, because it is the explicit template for everything that follows under the ESPR.

First, the data model is deep. Annex XIII of the regulation, as elaborated by the Battery Pass consortium, translates into roughly 90 mandatory data attributes spanning product identity, material composition including critical raw materials, carbon footprint per manufacturing site and batch, performance and durability documentation, test results, certificates, declarations of conformity, disassembly instructions, and state-of-health data. This is not a marketing datasheet. It is a structured extract of the engineering and certification record.

Second, access is tiered. The passport must serve three audiences with different permissions: the general public (identification, carbon footprint, recyclability), market surveillance authorities and notified bodies (full technical documentation, test results, conformity evidence), and service and recycling operators (disassembly instructions, cycle history). The same underlying record must project three controlled views, and the economic operator placing the product on the market is legally responsible for keeping all of them accurate, complete, and up to date.

The ESPR generalizes this pattern. Annex III of Regulation 2024/1781 lists the categories of data that delegated acts may require in any DPP: unique product identifier, unique operator identifier, unique facility identifier, technical documentation, user manuals and safety information, substances of concern, performance parameters, repair and end-of-life information, and compliance documentation including the EU declaration of conformity and relevant certificates.

Scan that list again and ask a simple question: which of these fields originates in an ESG platform? Almost none. Which originate in engineering systems? Almost all of them.

Why this breaks conventional toolchains

The uncomfortable truth for most hardware organizations is that the data the DPP demands exists, but not in one place, not in one model, and not with a maintained link between the pieces.

Material composition sits in the mechanical BOM, in the ERP item master, and in supplier declarations scattered across email threads. Substances of concern live in REACH and RoHS assessment spreadsheets that were last reconciled with the BOM at the previous certification milestone. The declaration of conformity references a technical file whose contents are versioned in a document management system that has no structural link to the components it describes. Test results are attached to a quality system that identifies products by a different numbering scheme than engineering does. Disassembly instructions, where they exist at all, were written for a hardware revision that shipped two change orders ago.

Automotive-sector analysis of battery passport readiness reaches the same conclusion: the hard compliance question is no longer whether a passport is needed, but who owns each data field, where it lives, and how it stays current across PLM, ERP, MES, quality, and supplier systems. That is a data architecture question, and answering it with a manual consolidation project every time a delegated act lands is a strategy that does not scale past the first product category.

There is a second-order problem that the compliance guides mostly skip: change. A DPP is not a snapshot produced once at market entry. The operator must keep it accurate for the life of the product on the market. Every engineering change that touches a listed material, a performance parameter, or a certification claim potentially invalidates fields in every affected passport. For the battery passport, which is issued per individual unit rather than per model, the blast radius of a component substitution runs through serialized records. Organizations that cannot answer "which shipped configurations does this change affect, and which compliance claims does it touch" from their systems will be answering it from tribal knowledge, under regulatory exposure.

This is exactly the class of problem that document-centric PLM and requirements silos handle poorly. When composition, requirements, verification evidence, and certification claims live in separate systems joined by naming conventions and discipline, impact analysis is an archaeology exercise. When they live in one graph, it is a query.

The graph-shaped solution

Strip away the regulatory vocabulary and the DPP requirement reduces to this: maintain a persistent, queryable link from each product configuration to its components, from components to materials and substances, from the whole assembly to the requirements it must satisfy, and from those requirements to the evidence and certificates that prove satisfaction. Then expose controlled projections of that structure to defined audiences, and keep the projections consistent as the product evolves.

That is a graph, and it is worth being precise about why relational exports and document trees fall short. The value of the DPP data is entirely in the relationships. A carbon footprint number is meaningless without the manufacturing site and batch it attaches to. A declaration of conformity is meaningless without the exact configuration and test evidence it covers. Regulators designed the passport around traceability because traceability is what enables enforcement; an architecture that stores the fields but loses the links reproduces the compliance risk it was supposed to eliminate.

This is the design thesis behind Koddex's Engineering OS: requirements, BOMs, change impact, and certification evidence modeled as one connected graph rather than as federated documents. In that model, a DPP is not a new system to build. It is a filtered, access-controlled view over data the engineering organization already maintains for its own purposes, primarily certification in regulated sectors. The delegated act changes; the query changes; the underlying graph does not need to be rebuilt. When an engineering change order lands, the affected passport fields are identifiable by traversal, not by committee. The three-tier access model maps naturally onto attribute-level permissions rather than onto three separately maintained exports.

The alternative, which much of the DPP vendor ecosystem is implicitly selling, is a passport platform fed by manual collection: a compliance team chasing engineering for data, transforming it into the registry format, and repeating the exercise at every product change and every new delegated act. That works as a one-off for a company with three SKUs. It does not work for an engineering organization managing configurations, variants, and continuous change across a certified product line.

Who should be moving now

The February 2027 battery deadline puts a specific set of companies on the clock, and the overlap with regulated hardware is larger than the word "battery" suggests. Industrial batteries above 2 kWh are embedded in autonomous mobile robots, AGV fleets, exoskeletons, off-road machinery, forklifts, UPS systems, and grid-scale storage. Electric and hybrid aviation programs carry propulsion batteries squarely in scope. The economic operator placing the battery on the EU market carries the obligation, and OEMs integrating third-party packs will find that their suppliers' data readiness becomes their compliance problem.

The timing compounds with another deadline the same sector already has circled: the EU Machinery Regulation 2023/1230 applies from January 2027, one month before the battery passport. Two regulations, one message. The EU is converting market access for industrial hardware into a structured-data obligation, and the companies that treat 2026 as the year to consolidate their engineering data foundation will amortize that investment across every subsequent delegated act, from the machinery technical file to whatever the ESPR asks of their product category in 2028 and beyond.

Companies outside the first wave should resist the temptation to wait. The battery passport is explicitly the proof of concept whose technical architecture, identifiers, data carriers, structured formats, and access tiers will propagate to every ESPR category. The preparation sequence recommended across the compliance literature is consistent: determine which products fall in scope of adopted or pending acts, run a gap analysis between required fields and existing records, assign ownership per data field, and establish the integration path from source systems to the passport. Every one of those steps is faster, cheaper, and more durable when the source of truth is a single connected model rather than a federation of silos.

The DPP will be sold to your board as a sustainability initiative. Treat it as what it is: the first time a regulator will query your engineering data directly. The organizations that pass that query cleanly will be the ones that stopped treating traceability as documentation overhead and started treating it as infrastructure.

Sources

1. Regulation (EU) 2024/1781 (ESPR), Articles 9-15 and Annex III. EUR-Lex
2. Regulation (EU) 2023/1542 (Battery Regulation), Article 77 and Annex XIII. EUR-Lex
3. European Commission, Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030, COM(2025) 187, 16 April 2025. EUR-Lex
4. Regulation (EU) 2023/1230 (Machinery Regulation). EUR-Lex
5. Battery Pass Consortium, battery passport content guidance (approx. 90 data attributes, three access tiers). thebatterypass.eu
6. Automotive IQ, "The EU Battery Passport Explained: Requirements, Timeline and Compliance Steps" (May 2026).
7. 3R Sustainability, "Navigating the EU's Digital Product Passport" (January 2026).
8. Codibly, "The Battery Passport Is Coming: What EU BESS Operators Must Build by Feb 2027" (May 2026).