Versioning the Digital Product Passport: how to evolve the passport without losing the product’s history

Introduction: A Passport Is Not a Photograph

We are accustomed to thinking of a "passport" as a static document—issued once and remaining valid until its expiration date. The Digital Product Passport (DPP) works differently: it accompanies a product throughout its entire lifecycle and, precisely for this reason, it evolves.

An error in a technical specification sheet is corrected. The carbon footprint of a specific batch is recalculated using an updated methodology. An electronic device undergoes repairs or receives a software update. An electric vehicle battery, at the end of its initial life, is repurposed as a stationary energy storage system. In all these instances, the passport must reflect the product's new reality.

The key question is: what happens to the previous data? This is where versioning—the strategy for managing changes over time—comes into play. It is a design decision that must be addressed early on, for each product category, as it impacts data architecture, regulatory compliance, and the trust placed in the system by customers, authorities, and supply chain stakeholders.

---

Why Versioning Is a Strategic Decision

Regulation (EU) 2024/1781 (the ESPR, or Ecodesign for Sustainable Products Regulation) stipulates that a passport must remain accessible and up-to-date for the duration specified in the delegated act for the relevant product group. The same delegated act also defines who is authorized to modify specific data points, and the regulation requires that a backup copy of the passport be maintained by a third-party DPP service provider.

This framework gives rise to three requirements that versioning must address:

1. Updating — the passport must always display current and accurate information. 2. Traceability — it must be possible to reconstruct what was declared, when, by whom, and why it was changed.
2. Continuity — anyone scanning the data carrier (QR code, NFC, RFID) must always be directed to the correct location, even years later.

Superficial version management can lead to disputes that are difficult to defend: if an item of clothing was sold with a specific declared composition, or a construction product was installed with a particular declaration of performance, the company must be able to demonstrate exactly what was communicated at that time.

---

Potential Strategies

There are essentially three approaches, plus a "starting" state typical of projects still in their early stages.

1. Current Version Only

Every change overwrites the previous data, which can no longer be accessed.

• When it makes sense: for products where a "passport" is not mandatory, or for minor corrections to voluntary information sheets.
• Advantages: technical simplicity; no storage burden.
• Limitations: no historical record; in the event of an audit or dispute, it is impossible to prove what was declared in the past.

2. Version History

Every change generates a new, dated, and justified version; previous versions remain accessible.

• When it makes sense: for data that is recalculated (e.g., carbon footprint), new official declarations, dynamic data (such as the health status of a battery), or repair interventions.
• Advantages: full traceability and auditability.
• Limitations: requires a more structured data model and clear rules regarding who is authorized to create new versions. ### 3. History and linked passports

In addition to version history, there is the option to issue a new passport linked to the previous one when a product undergoes a substantial change—to the extent that it effectively becomes a "new" product.

• When it makes sense: remanufacturing, refurbishment, a change in intended use, or reconditioning followed by reintroduction to the market.
• A prime example: an electric vehicle (EV) battery repurposed for stationary energy storage.
• Benefits: It delineates responsibilities between the original manufacturer and the party placing the transformed product on the market, while preserving the historical chain.

4. Not yet defined

This is a common scenario for Digital Product Passport (DPP) projects in their early stages. While not a problem in itself, it is an open issue that must be resolved before selecting a platform or data model; changing strategy after passports have already been issued is significantly more costly.

Quick comparison

Strategy	Previous data	New passport	Typical use case
Current version only	Overwritten	No	Voluntary data correction
Version history	Retained and dated	No	Recalculation of carbon footprint
History + linked passports	Retained and dated	Yes, linked to the original	EV battery repurposed for storage
Not yet defined	—	—	Early-stage project

---

Golden rules, applicable to all categories

Regardless of the chosen strategy, certain rules should be considered non-negotiable:

• The passport address never changes. The URL encoded in the data carrier remains the same throughout the product's entire lifecycle and always points to the current version. Printing a new QR code for every update is neither sustainable nor reliable.
• Each version includes complete metadata: date of modification, author, and reason for the change.
• Previous versions are never deleted. Even when an error is corrected, the erroneous version remains documented as such.
• Linked passports point in both directions, allowing one to trace a remanufactured product back to the original, and vice versa.

---

Guidelines by product category

Versioning must be determined for each category, as data dynamics and regulatory requirements vary significantly from one sector to another.

EV, LMT, and industrial batteries

The state of health is a dynamic data point that evolves with use, as stipulated in Annex XIII of Regulation (EU) 2023/1542. Consequently, a version history is required. Furthermore, Article 77 of the same regulation mandates that a battery prepared for re-use, repurposing, or remanufacturing must be issued a new passport linked to that of the original battery.

👉 Recommended strategy: version history + linked passports.

Portable and SLI (starting, lighting, and ignition) batteries

The regulation does not mandate a passport for these types of batteries. If a company chooses to adopt one voluntarily, the current version is generally sufficient; a version history becomes useful if there is a need to document declarations over time. 👉 Recommended strategy: current version (or version history, for greater protection).

Electronics

Repairs, component replacements, and software updates modify a product after its initial sale. Maintaining a version history allows for the reconstruction of a device’s lifecycle. For products that are refurbished and reintroduced to the market, it is advisable to implement a linked passport.

👉 Recommended strategy: version history, with linked passports for refurbished items.

Commercial vehicle tires

A retreaded tire returns to the market as a new product. A passport linked to the original item preserves its history.

👉 Recommended strategy: version history + linked passports.

Passenger car tires

Data is defined by batch and tends to be stable; updates are rare. Nevertheless, any corrections must remain traceable.

👉 Recommended strategy: version history.

Construction products

Under Regulation (EU) 2024/3110, the passport is linked to the declaration of performance and conformity. Each new declaration corresponds to a new version, and previous versions must remain accessible: since installed products often remain in place for decades, anyone performing work on a building needs to know what was declared at the time of the original installation.

👉 Recommended strategy: version history.

Textiles and fashion

The passport is often issued by model, while suppliers and material composition may vary between production runs. A version history makes it possible to verify what was declared at the time a specific garment was sold.

👉 Recommended strategy: version history. ### Furniture

Production data remains stable, but over time, repairs, replacement of coverings, and changes in ownership may occur. A version history documents this evolution.

👉 Recommended strategy: version history.

Steel and Aluminum

Data is determined by heat or batch and rarely changes. However, if the carbon footprint is recalculated or a data point is corrected, the change must be tracked—never overwrite existing data.

👉 Recommended strategy: version history.

Other Categories

In the absence of specific guidance from the delegated act relevant to your product group, a version history is the most prudent choice; it is always possible to simplify later, whereas reconstructing a history that was never recorded is far more difficult.

---

The Role of Technical Standards

Alongside regulations, the joint technical committee CEN-CENELEC JTC 24 is developing European standards that define the Digital Product Passport (DPP) infrastructure—including unique identifiers, access rights management, and interfaces for managing the passport’s lifecycle. Monitoring the evolution of these standards is essential for designing an interoperable versioning system and avoiding the need for rework in the future.

---

Checklist for Defining Your Strategy

1. Map the product categories involved in the DPP project.
2. Verify requirements: Is the passport mandatory or voluntary? Is there already a delegated act in place?
3. Classify data into static (defined at the time of production) and dynamic (changing during use).
4. Identify transformative events: repair, reconditioning, remanufacturing, or a change in intended use.
5. Choose a strategy for each category (current version only, full history, or history plus linked passports).
6. Define roles: determine who is authorized to create new versions or new, linked passports.
7. Ensure a stable URL within the data carrier, along with complete metadata for every version.
8. Arrange for data backup via a DPP service provider, as required by the ESPR (Ecodesign for Sustainable Products Regulation).

---

Pitfalls to Avoid

• Overwriting mandatory data: This results in the loss of evidence regarding what was originally declared.
• Generating a new URL for every update: This breaks the link between the physical product and its passport.
• Treating a remanufactured product merely as a "new version": This creates ambiguity regarding the responsibilities of different economic operators.
• Postponing decisions: Transitioning to a historical record system after thousands of passports have already been issued is costly and often results in incomplete data.

---

Conclusion

Versioning is what transforms a Digital Product Passport from a simple digital datasheet into a reliable record of a product’s lifecycle. Selecting the right strategy for each category means balancing three objectives: keeping data up-to-date, ensuring full traceability, and maintaining continuous access. In most cases, the best approach is to retain the product's history; when a product undergoes a substantial transformation, the appropriate path is to issue a new passport that remains linked to the previous one. Making decisions early—and consistently—avoids costs and risks when regulatory deadlines come into effect.