From 18 February 2027, the first stage of the EU-wide Digital Product Passport obligation takes effect: batteries -- electric vehicle, light means of transport and industrial batteries above 2 kWh -- may then only be placed on the market with a digital battery passport (European Commission). Textiles, electronics, furniture and further product groups follow step by step. The basis is the Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781), which has been in force since 18 July 2024 and sets the framework for virtually all physical products (European Commission). The Digital Product Passport is a digital product identity card that makes information on material, repairability, origin and recycling accessible via a QR code or another data carrier (European Commission). For merchants and manufacturers this means: provide structured product data -- and this data already lives in ERP and PIM. This article shows what the data model per CIRPASS and GS1 looks like, what role the unique identifier plays and how a middleware layer feeds the passport from existing systems instead of maintaining data twice.
What the Digital Product Passport Is -- and When It Becomes Mandatory
At its core, the Digital Product Passport (DPP) is a structured dataset that links a physical product to its sustainability and lifecycle information. The European Commission describes it as a digital identity card for products, components and materials that stores relevant sustainability information and makes it electronically accessible (European Commission). The passport is reached via a data carrier on the product -- usually a QR code -- that points to an online dataset. Different audiences access it with different rights: consumers see care and repair notes, recyclers the material composition, market surveillance authorities the conformity records.
The ESPR extends the former ecodesign approach from energy-related products to practically all physical product groups -- exempt are essentially food, feed and medicinal products (European Commission). The Commission sets the concrete requirements per product group in delegated acts. The opening move, however, comes not from the ESPR itself but from the EU Battery Regulation (Regulation (EU) 2023/1542): from 18 February 2027, the battery passport is mandatory for EV, light means of transport and industrial batteries above 2 kWh (European Commission). In April 2025 the Commission also adopted the first ESPR working plan 2025 to 2030, naming six priority product groups: steel and aluminium, textiles with a focus on apparel, furniture, tyres and mattresses (European Commission).
| Product group | Time horizon | Basis |
|---|---|---|
| Batteries (EV, light transport, industrial above 2 kWh) | from 18 February 2027 | Battery Regulation (EU) 2023/1542 |
| Iron and steel | delegated act indicatively from 2026 | ESPR working plan 2025-2030 |
| Textiles (focus on apparel) | delegated act indicatively from 2027 | ESPR working plan 2025-2030 |
| Tyres and aluminium | delegated act indicatively from 2027 | ESPR working plan 2025-2030 |
| Furniture and mattresses | listed as a priority in the working plan | ESPR working plan 2025-2030 |
| Mid-term review of the working plan | 2028 | European Commission |
Batteries are only the beginning
Which Data the Passport Requires
The exact data scope is set per product group in the delegated act, but the categories are already staked out by the regulation. The Digital Product Passport is to contain information on technical performance, on the materials used and their origin, on repair and maintenance activities, on recyclability and on the environmental impacts across the lifecycle (European Commission). From a systems integration perspective the decisive point is: almost all of this information already exists in the company -- spread across ERP, PIM and adjacent systems.
Materials and Composition
Material composition, recycled content and, where relevant, critical raw materials per component or batch.
Repairability
Availability of spare parts, repair instructions and -- where provided -- a repairability index.
Origin and Supply Chain
Origin, place of manufacture and stations along the supply chain for traceability.
Circularity
Guidance on disassembly, recycling and proper disposal at the end of use.
Environmental Impact
CO2 footprint, energy consumption and information on contained chemicals across the lifecycle.
Conformity
Conformity records and declarations that market surveillance authorities can check electronically.
This is exactly where the lever for integration lies: material records, batches and origin details are typically held as master data in the ERP, while attributes, variants, media and descriptive texts are maintained in the PIM. The passport is not created through a new, separate data capture, but by consolidating and enriching existing data holdings.
The Data Model: CIRPASS, GS1 Digital Link and Unique Identifiers
For a passport to remain readable across industries and systems, a common data model is needed. This foundation is created by the EU-funded consortium CIRPASS. Its successor project CIRPASS-2 started in May 2024, brings together 49 partners and pilots the passport over three years in 13 large-scale pilot cases across the textile, electronics, tyre and construction value chains (CIRPASS). Six of these pilots alone concern textiles and five concern electronics (CIRPASS). From the first project phase comes the EU DPP Core Ontology (March 2025), which serves as the de-facto interoperability reference for the sectoral pilots (CIRPASS).
The second building block is the unique identifier. A passport must be linked to a unique product identifier through which the dataset is found. This is where the GS1 Digital Link comes in: it embeds established GS1 identifiers such as the GTIN into a web address, so that a QR code per ISO/IEC 18004 resolves directly to the passport dataset (GS1 Germany). The data carrier itself must comply with an ISO/IEC standard under the ESPR (European Commission); besides the QR code, GS1 DataMatrix, RFID tags or NFC chips are also eligible (GS1 Germany).
| Data carrier | Property | Typical use |
|---|---|---|
| QR code (ISO/IEC 18004) | Scannable with any smartphone, cheap to print | De-facto standard for the DPP on the product |
| GS1 DataMatrix | High data density on a small area | Small parts and heavily printed products |
| RFID tag | Reading without line of sight, several items at once | Logistics and inventory management |
| NFC chip | Tap with the smartphone | Higher-value individual products |
The identifier is the anchor of the passport
Where the Data Comes From: ERP and PIM as Sources
The core question of every DPP project is not which new data must be collected, but where the required information already resides. In practice it splits across two main sources. The ERP holds the commercial and logistical master data: item records, batches, serial numbers, suppliers and origin details. The PIM holds the descriptive product information: attributes, material details, variants, media and multilingual texts.
- From the ERP: unique item identifier and GTIN, batch and serial numbers, supplier and origin data, bills of material as the basis for the material composition.
- From the PIM: material attributes and composition, care and repair notes, documents such as manuals and conformity declarations, multilingual descriptions.
- From adjacent systems: CO2 and lifecycle data from sustainability or supplier systems, plus test and conformity records from quality management.
The problem: maintaining this information twice -- once in the specialist system and once in a separate passport solution -- leads to contradictory states and high effort. If a formulation changes or a supplier is switched, the change would have to be tracked in two places. It is exactly this duplicate data holding that must be avoided. How to map product data cleanly between the systems is covered in depth by the article on data mapping between ERP and store; building an end-to-end product data pipeline is described in the article on PIM integration.
The Middleware: Aggregating Product Data DPP-Compliant
The answer to duplicate data holding is a middleware that mediates between the existing systems and the passport. It reads the relevant fields from ERP and PIM, consolidates them into a consistent dataset, maps them to the DPP data model and provides them via an API -- retrievable through the identifier in the data carrier. The leading data holding stays in the specialist systems; the middleware is the aggregation and delivery layer, not yet another data silo.
- Read fields from ERP and PIM: via the respective APIs, item identifier, materials, origin, documents and conformity details are collected.
- Map to the DPP model: the fields are mapped to the structure per CIRPASS core ontology and the requirements of the delegated act.
- Validate and enrich: mandatory fields are checked, units normalized and missing details filled in from adjacent systems.
- Anchor the identifier: each dataset receives its GS1 Digital Link, which is stored in the QR code on the product.
- Provide via API: the passport is delivered as a versioned dataset and made accessible on scan of the data carrier depending on role.
Because the passport is delivered via a publicly reachable interface, access control and versioning belong in the architecture from the start. Not every piece of information is intended for every audience: consumers, recyclers and authorities receive different views of the same dataset. How to secure such interfaces cleanly is covered by the article on OAuth 2.0 and token security for ERP interfaces. And because the passport is carried forward over years, the interface must represent changes in a version-safe way -- an aspect the article on API versioning explores.
The passport is carried forward, not generated once
Typical Pitfalls in Implementation
Recurring stumbling blocks can be derived from integration projects with product data (project experience). Most of them lie not in the technology of the interface, but in the data quality of the source systems and in the clean mapping to the required model.
- Incomplete master data: missing material or origin details only surface when the mandatory dataset is to be generated. An early data check reveals gaps while there is still time to fill them.
- Ambiguous identifiers: without a consistent GTIN or stable item identifier the passport cannot be reliably found. The identifier must be the same across all systems.
- Duplicate data holding: if the passport is maintained manually in a separate solution, the states drift apart. The leading source stays in the specialist system.
- Data carrier without a standard basis: a QR code that is not built as a GS1 Digital Link complicates cross-industry resolution (GS1 Germany).
- Product group checked too late: anyone starting only when the delegated act appears comes under time pressure. The affected product group and its time horizon should be clarified early (European Commission).
- Access control added afterwards: if roles and views are only added retroactively, the API has to be rebuilt at great effort. The permissions belong in the design.
The Digital Product Passport is not a new data silo, but a view onto existing product data. Whoever feeds it from ERP and PIM meets the obligation and at the same time improves the quality of their master data.
Project Approach: Build Early from the Existing Systems
A DPP project can be approached in a structured way when the data base is the early focus. The first step is not a software selection, but a stocktake: which of the required details already exist, where, and in what quality? Only then does the technical implementation follow.
1. Product group and data check
Clarify the time horizon for your own product group and reconcile the required fields with the existing data holdings in ERP and PIM.
2. Data model and mapping
Map the fields to the DPP model per CIRPASS and define the identifier strategy with GTIN and GS1 Digital Link.
3. Middleware and API
Build the aggregation layer that consolidates ERP and PIM data, validates it and provides it via a role-based API.
4. Data carrier and test
Generate the QR codes, verify resolution to the dataset and run in parallel before the respective deadline.
Anyone wanting to embed the passport interface in a larger integration strategy will find further approaches in the article on connecting the inventory system to the store as well as in the overview of our integration services. The Digital Product Passport thus fits into the same logic as other compliance topics -- such as the e-invoice mandate from 2027, where structured data is likewise generated from the existing systems.
Sources and Studies