8 min read
Static or dynamic data? The choice that determines the lifespan of your Digital Product Passport
In the Digital Product Passport, not all data remains static: some is fixed at the time of production, while other data changes as a result of repairs, refurbishments, and transfers of ownership.
by Corrado Facchini, CTO & Innovation Manager
In this article
Why this question matters more than it seems
When designing a Digital Product Passport (DPP), it is easy to think of it as a "digital product sheet"—you fill it out at the time of production, generate a QR code, and the job is done. However, this approach only works for a certain subset of products.
Regulation (EU) 2024/1781 (ESPR) requires that the passport remain accessible and up-to-date throughout the product's intended lifespan. It delegates the task of defining who can update which data—not just the manufacturer, but also repairers, refurbishers, and other stakeholders throughout the product's life—to specific delegated acts for each product group.
For this reason, one of the first design decisions is to determine, category by category, whether the product data is static, dynamic, or a mix of both. This answer dictates the technical architecture, access permissions, version management, and maintenance costs.
The three possible answers
1. Static data
This refers to information defined at the time of production that does not change thereafter.
Typical examples:
- composition and materials;
- country of origin;
- technical specifications (as stated on the product label/nameplate);
- declared carbon footprint for the model;
- instructions for use and disassembly.
A passport consisting solely of static data is relatively simple: it is created once, published, and stored. The only subsequent interventions would be to correct errors or make updates required by new regulations.
2. Dynamic data
This refers to information that changes throughout the product's lifespan.
Typical examples:
- repairs performed and spare parts replaced;
- health status (e.g., of a battery);
- software updates. - changes in ownership or status (reused, remanufactured, end-of-life).
In this context, the passport becomes a living record: it requires a system capable of receiving updates from various parties, authenticating them, maintaining a historical log, and allowing access based on specific, differentiated user rights.
3. Both
This is the most common scenario for complex products: some data remains static, while other data evolves. A classic example is a product with an unchanging composition, accompanied by a repair history that grows over time.
The "both" approach is also the preferred choice when—even in the absence of a regulatory requirement—there is a desire to record post-sale events (such as repairs, resales, or reconditioning) to provide added value to customers and the second-hand market.
Category by Category
Batteries for electric vehicles, light means of transport, and industrial applications
This is the category where the mixed nature of the data is explicitly defined by regulation. Article 77 of Regulation (EU) 2023/1542 on batteries mandates a passport—effective from February 18, 2027—for electric vehicle batteries, all LMT (light means of transport) batteries (such as those for e-scooters and e-bikes), and industrial batteries with a capacity exceeding 2 kWh that are placed on the market or put into service within the EU. The content of the passport is defined in Annex XIII and includes both static elements—identification, chemical composition, critical raw materials, carbon footprint, and dismantling information—and dynamic elements, starting with the State of Health, which is linked to the information that the battery management system must make available pursuant to Article 14.
Two practical implications:
- Model-level data and individual battery data coexist. Batteries of the same model may share technical information, but each unit has its own unique identifier and usage data.
- Responsibility for updates is clearly defined. The economic operator who places the battery on the market is responsible for the accuracy, completeness, and up-to-date status of the passport (Art. 77, para. 4). When a battery is repurposed, remanufactured, or refurbished, this responsibility may shift to the operator who places it back on the market.
It should also be noted that the deferral of due diligence obligations—introduced for 2025—has not altered the deadline for the passport: February 18, 2027, remains the target date.
Electronics
Technical specifications and composition are static. However, the lifecycle of an electronic device involves various events: repairs, component replacements, and software updates. Each of these can alter significant characteristics—ranging from repairability and safety to energy efficiency.
For this category, the most realistic approach is almost always "both": a static core defined at the factory, combined with a dynamic section populated by service centers, authorized repairers, and, in some cases, the device itself.
Tires for commercial vehicles
The case of commercial tires is interesting because their dynamic nature stems from an established industrial practice: retreading. A retreaded tire undergoes changes to some of its characteristics and its history; the passport must be able to reflect this. In this instance, too, the preferred approach tends toward a mixed model.
Other categories
For many product categories, data is generally static: it is fixed at the time of production and does not change. In such cases, a "static" approach is appropriate and simplifies the project.
However, a strategic option remains: choosing a "hybrid" (both static and dynamic) approach—even when not strictly required by regulation—to record repairs, resales, or other events. While this entails additional costs, it can support circular business models (such as extended warranties, certified second-hand sales, or take-back programs).
What the regulations say about updates
| Aspect | ESPR – Reg. (EU) 2024/1781 | Batteries – Reg. (EU) 2023/1542 |
|---|---|---|
| Duration | The passport must remain available for the duration specified in the delegated act, which cannot be shorter than the product's expected lifespan | The passport accompanies the battery throughout its entire life cycle, up to the end-of-life stage |
| Who performs updates | The delegated act specifies which entities are authorized to enter or update data (e.g., repairers, remanufacturers) | The operator placing the battery on the market is responsible for updates |
| Dynamic data | Defined on a product-by-product basis within the delegated acts | Explicitly provided for—for example, "state of health" (Annex XIII) |
| Access | Access and modification rights are restricted in accordance with the provisions set out in the delegated acts | Differentiated access levels (public, legitimate stakeholders, authorities) |
| Granularity | Model, batch, or individual item, as per the delegated act | Model data and individual battery data |
Design implications: from requirements to architecture
Classifying data as static or dynamic is not merely a theoretical exercise. Here are the concrete consequences that must be anticipated.
1. Identifier granularity. Dynamic data almost always pertains to an individual unit, rather than a model. If a category includes dynamic data, a serialized, unit-specific identifier will likely be required—with corresponding implications for costs and production processes.
2. Separate data models. It is advisable to separate the static component (written once and then "frozen") from the dynamic component (which evolves over time) from the outset. For events—such as repairs, replacements, or changes in status—an append-only chronological log is more robust than simply overwriting values; it preserves the history and ensures that actions—who did what, and when—remain verifiable.
3. Versioning. Every modification must generate a traceable version of the passport. Version management is closely linked to this: the more dynamic data there is, the more critical it becomes to be able to reconstruct the state of the passport as it existed on a specific date.
4. Roles and permissions. If repairers, remanufacturers, or service centers are to write to the passport, it is necessary to define who is authorized to modify specific fields, the required authentication methods, and the necessary integrity checks.
5. Data sources. Dynamic data originates from systems outside the factory environment—such as a battery’s BMS (Battery Management System), service center management software, or resale platforms. Mapping these sources is the logical next step.
6. Privacy. Certain dynamic data—such as the owner—involve personal information. The ESPR (Ecodesign for Sustainable Products Regulation) framework precludes the storage of customers' personal data within the passport without their explicit consent, in accordance with the GDPR; it is preferable to record the event (e.g., "change of ownership") rather than the identity of the new owner.
7. Maintenance costs. A static passport entails costs concentrated at the outset. A dynamic passport involves recurring costs, such as hosting, integrations, verifications, and support for external stakeholders. These must be factored into the budget for the product's entire expected lifespan.
Quick Checklist
- Have I listed all the product categories involved?
- For each category, have I indicated whether the data is static, dynamic, or both?
- Have I checked whether a specific regulation (e.g., the Batteries Regulation) mandates dynamic data?
- Have I considered whether to record post-sale events, even where not strictly required?
- Have I determined the appropriate level of granularity (model, batch, or individual item)?
- Have I defined who is authorized to update the passport and how they are authenticated?
- Have I provided for version management and an event history?
- Have I excluded any unnecessary or impermissible personal data?
In brief
Static, dynamic, or both: the answer to this question determines whether a passport will be a document published once or a system that must be managed over the course of years. For batteries, the regulation has already made the choice—the passport is hybrid, and the "state of health" must be updated. For electronics and retreaded tires, the nature of the product points in the same direction. For many other categories, the data may remain static, but recording a product’s history can become a competitive advantage within the circular economy.
Sources
- DPP Designer – For each category, are product data static or dynamic?
- Regulation (EU) 2024/1781 (ESPR) – EUR-Lex
- Regulation (EU) 2023/1542 concerning batteries – EUR-Lex
- PMI.it – Digital Product Passport: obligations and deadlines
- osapiens – EU Battery Passport: scope and responsibilities
- EaseCert – EU Digital Battery Passport 2027
[Certivo – EU Battery Passport Data: the build behind the 18 February 2027] deadline](https://www.certivo.com/blog-details/eu-battery-passport-data-the-12-18-month-build-behind-the-february-18-2027-deadline)
- B.D. Emerson – Digital Product Passport: what it is and what the EU requires
- Renoon – Who is responsible for the Digital Product Passport
Related articles
- November 3, 2026Versioning the Digital Product Passport: how to evolve the passport without losing the product’s historyDiscover the three versioning strategies, the guidelines for batteries, electronics, textiles, construction, and metals, and the ESPR rules for ensuring data remains traceable, accessible, and verifiable over time.
- November 2, 2026Repairing, maintaining, tracking: how maintenance fits into the Digital Product PassportWe examine the requirements of the ESPR, the Right to Repair, and the Batteries Regulation—including how to respond on a sector-by-sector basis—as well as the information that must be provided regarding spare parts, instructions, maintenance/repairs, and the state of health throughout the product.
- October 20, 2026Digital Passport, who sees what: a date has finally been set for differentiated access.Who sees what in the Digital Product Passport? Differentiated access levels are becoming a reality: the EN 18239 standard has been published, an implementing act regarding batteries is expected by the end of 2026, and the first mandatory requirement will take effect on February 18, 2027. Here is wha