Keeping DPP Data Current: How the Update Process Works

The Digital Product Passport (DPP) is not a static document. Create one and forget about it, and you risk compliance gaps — over a very long time horizon: the ESPR Regulation (EU) 2024/1781 requires that registry entries remain available and up to date for at least 10 years after the last time a product is placed on the market. This article explains what data layers exist, when each one needs to be updated, and how to implement the process cleanly from a technical standpoint.

The Three Layers of a DPP — and Who Maintains Them

A complete DPP consists of at least three logically separate layers, each with its own update cadence.

1. Registry Entry (Identifier + Resolver)

The central DPP registry — whose implementing regulation the European Commission published in draft form on April 29, 2026 — stores exclusively:

the Unique Identifier (UID) of the product — in practice a GS1 GTIN or an ISO/IEC 15459-compliant code,
the resolver endpoint, i.e., the URL at which the actual passport content can be retrieved,
the associated commodity code.

This layer changes infrequently. An update is primarily needed when the resolver endpoint changes — for example, because a company switches its DPP service provider or migrates a domain. Since the QR code on the physical product points to this entry, continuity of the resolver must be guaranteed without interruption.

2. Resolver Configuration (Link Routing)

The resolver translates an incoming scan into the appropriate destination URL — depending on context, language, or user role. Organizations using GS1 Digital Link can route to different datasets via structured link types (e.g., gs1:sustainabilityInfo, gs1:epcis).

Updates at this layer are needed when:

new mandatory fields are introduced by delegated acts (e.g., the Textile and Battery regulations expected from 2026/2027 onward),
destination URLs change,
new language versions or market regions are added.

3. Product Data (the Actual Passport Content)

This is where the real substance lives: material composition, repairability index, carbon footprint, hazardous substance declarations, warranty information. This layer has the highest update frequency because it depends on real events in the product lifecycle.

When Does DPP Data Need to Be Updated?

The ESPR regulation does not specify fixed update intervals. Instead, the principle of data currency applies: information must reflect the actual state of the product. This gives rise to several practically relevant triggers:

Regulatory Changes

As soon as a delegated act introduces new data obligations, existing passports must be updated accordingly. This is not a theoretical future concern: the first product-specific regulations for textiles and batteries are scheduled to take effect in 2026 and 2027 under the ESPR timeline.

For battery manufacturers, this means: starting August 2026, all batteries sold in the EU must carry visible QR codes and labeling covering capacity, chemistry, and hazardous substances — as a precursor to the full battery passport that becomes mandatory in 2027. The EU Battery Regulation is therefore one of the first real large-scale tests of the DPP update process.

Product Changes

If a product's material composition changes — even when the GTIN remains the same — the DPP must be updated. The same applies to:

new repair instructions or spare-part sources,
revised warranty terms,
updated safety data sheets.

Recalls or Safety Warnings

Safety-relevant information must be entered promptly. The DPP is not a replacement for the RAPEX rapid alert system, but it is a complementary channel that can be used by both consumers and regulatory authorities.

Technical Update Process: Step by Step

Step 1: Clarify Identifiers and Versioning

Every change to passport content should be versioned. A combination of the following is recommended:

Product UID (immutable, e.g., GTIN + serial number),
Passport version (semantic version number or timestamp),
Reason for change (regulatory, product-related, corrective).

{
  "uid": "urn:epc:id:sgtin:4012345.067890.1234567",
  "passVersion": "2.1.0",
  "lastModified": "2026-05-19T10:00:00Z",
  "changeReason": "battery-regulation-aug2026"
}

Step 2: Update Only the Affected Data Layer

A common mistake is to rewrite the entire passport record when a regulatory update occurs. This increases the risk of errors and makes changes harder to trace. A better approach: use a modular data structure in which individual data fields can be updated independently.

If you work via an API, use HTTP PATCH instead of PUT:

PATCH /api/v1/dpp/{uid}/sections/battery
Content-Type: application/json

{
  "capacityWh": 42.5,
  "chemistry": "LFP",
  "hazardousSubstances": ["Li", "P"],
  "carbonFootprintKgCO2e": 18.3
}

Step 3: Ensure Resolver Availability

An update that takes the resolver temporarily offline is critical from a compliance perspective. The ESPR's 10-year availability requirement leaves no room for downtime without a fallback. Recommended practices include:

Blue-green deployment for resolver updates,
monitoring of the resolver endpoint with alerting on HTTP error codes ≥ 400,
regular verification that the endpoint registered in the registry is actually reachable.

Step 4: Bulk Updates for Large Product Portfolios

Anyone managing hundreds or thousands of products cannot avoid a structured bulk import process. The key principle: changes should be processed as differential updates (delta imports) rather than full imports, in order to minimize error sources and preserve audit trails.

A typical CSV format for a delta update might look like this:

uid,field,newValue,effectiveDate,changeReason
urn:epc:...:001,capacityWh,42.5,2026-08-18,battery-reg-2026
urn:epc:...:002,chemistry,NMC,2026-08-18,battery-reg-2026

Special Considerations for Textiles and the Fair Trade Debate

For textile manufacturers, the ESPR timeline brings particular challenges. The Fair Trade Movement has called in its recommendations on the delegated act for textiles for the DPP data architecture to be manageable for SMEs and smallholder farmers in third countries as well. This has direct implications for the update process: when supply chain data originates from actors who have no direct API access, robust manual or semi-automated data entry pathways are essential.

This illustrates that the update process is not only a technical question but also an organizational one: Who is authorized to change which data? Who validates changes? How are suppliers integrated into the process?

GS1 Digital Link as an Update Enabler

The GS1 General Assembly 2026, focused in Warsaw on the global transition to 2D barcodes, underscores this point: GS1 Digital Link is the preferred mechanism for linking product identities to current content. The key advantage for the update process: the QR code on the product remains unchanged — only the content behind the resolver changes. This is precisely what makes retroactive updates to products already sold on the market possible at all.

With the Sunrise 2027 deadline for 2D barcodes in retail approaching, the point at which brands can no longer defer GS1 Digital Link QR codes is drawing near — both for retail compliance and for DPP requirements.

Conclusion: Update Capability Is Not a Feature — It's a Requirement

The ESPR regulation treats the DPP as a living document. Anyone planning an implementation today must build update processes in from the start: versioned data structures, modular APIs, stable resolvers, and clear governance rules for data changes. The first mandatory deadlines — batteries from August 2026, textiles expected in 2027 — are close enough that technical preparation should begin now.