Keeping DPP Data Current: What the ESPR Actually Requires

The question sounds simple, but it isn't: how often does a Digital Product Passport need to be updated? If you search the ESPR Regulation (EU) 2024/1781 for a concrete number, you'll come away empty-handed. The text merely states that the DPP must contain "current and accurate information" — no frequency, no SLA, no technical specification. What that means in practice depends heavily on the product type, the supply chain, and the delegated acts that still need to be issued for each product category.

This article explains which data categories can change in the first place, which update patterns have proven themselves in early implementations, and where the regulatory pitfalls lie.

What Can Actually Change in a DPP

A product passport is not a static PDF. It consists of data points with very different lifecycles.

Static vs. Dynamic Data

DPP fields can be broadly divided into three classes:

Data category	Typical change frequency	Examples
Master data	Once (at product launch)	GTIN, material composition, manufacturer
Batch/lot data	Per production run	PCF value, raw material origin, certificates
Lifecycle data	Event-driven	Repair history, recall, end-of-life pathway

The JRC data draft for steel products makes this distinction particularly clear: the product-specific carbon footprint (PCF) is explicitly tracked at the batch level and must be calculated using ISO-14067-compliant methods. This means every new production batch can carry a different PCF value — the passport must reference that value correctly, not last year's average.

The Battery Passport as a Blueprint

The Digital Battery Passport, mandatory as of February 18, 2027, illustrates just how dynamic DPP data can be. The Minespider Implementation Report 2026 identifies data fragmentation and dynamic data updates as the two central practical challenges. Batteries accumulate data over their lifetime: State of Health (SoH), charge cycles, repair events. Working with a static dataset here means you are not meeting the regulation.

Update Patterns: How Implementations Work Today

Event-Driven Updates via Webhook

The most robust pattern in early DPP systems is the event-driven update: a backend system fires a webhook as soon as a relevant data point changes — for example, when a new inspection certificate is issued or a repair is completed.

// Example: Webhook handler for DPP update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Important: the ESPR implicitly requires audit-trail capability. Changes must remain traceable — simply overwriting data without versioning is regulatorily risky.

Batch Updates for Lot Information

When PCF values or certificates need to be updated for entire production batches at once, a bulk-import approach makes sense. A list of passport IDs is submitted together with the new field value:

# Example: Bulk PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Platforms like qr3.app with bulk import support this pattern so you don't have to update every batch manually.

GS1 Digital Link as a Resolver Layer

One often-overlooked aspect: the QR code on the product must not change — it's physically printed on the packaging. What must change is the content it points to. This is exactly where GS1 Digital Link provides the critical abstraction layer. The QR code encodes a stable URI (e.g., https://id.example.com/01/04012345678901/21/SN-00042), and the resolver redirects to the most current data source.

Driscoll's demonstrated at GS1 Connect 2026 how this principle works at scale: over a billion berry clamshells were given unique identities and are currently migrating to fully GS1 Digital Link-compliant QR codes. The code on the packaging stays the same; what changes is the dataset behind the resolver.

New technologies such as the partnership between Polytag and DataLase show that GS1-compliant QR codes can now be applied to difficult packaging substrates at production-line speed — the physical barrier is falling, while the resolver logic behind it stays the same.

Regulatory Pitfalls

The EmpCo Directive as Additional Pressure

If you think you only need to watch the ESPR, you're underestimating the full picture. In June 2026, the European Commission opened infringement proceedings against 20 member states for inadequate transposition of the EmpCo Directive (EU) 2024/825. This directive prohibits greenwashing and requires clear information on durability and repairability — information that is meant to feed directly into the DPP. Outdated repairability indices or invalid sustainability labels in the passport can therefore constitute not only an ESPR violation but an EmpCo violation as well.

No Explicit Update Deadline — But Implicit Obligations

The absence of a frequency requirement in the ESPR is not a free pass. Several implicit obligations can be derived from the phrase "current and accurate information":

Event-bound currency: As soon as a recall, repair, or certificate change occurs, the passport must be updated — without delay.
Batch-bound currency: PCF values and raw material documentation must not be carried over from an old batch to a new one if the values differ.
Market surveillance compliance: Authorities must be able to retrieve the passport throughout the entire product lifecycle. A passport that is never updated after the point of sale is worthless for repair and end-of-life information.

Ecommerce Europe explicitly recommends a phased rollout and flexible data granularity in its position paper — which indirectly means that update processes can be built iteratively, as long as the core requirements are met.

Practical Recommendations

Plan for an Audit Log from Day One

Every change to a DPP record should be logged with a timestamp, the actor responsible, and the reason for the change. This is not yet an explicit ESPR requirement, but it is expected in the delegated acts and is practically necessary for market surveillance.

Resolver Architecture Before Data Architecture

If you lock down your data structure first and then figure out how the QR code points to it, you're building things in the wrong order. The right sequence: define the resolver URI (GS1 Digital Link), then the data schema, then the update processes. The Digital Product Passport on qr3.app follows this principle: the QR code is stable, and the dataset behind it is versioned and patchable.

Use Batch IDs Consistently

If you manage PCF values or certificates at the product level rather than the batch level, you're setting yourself up for problems at the first market surveillance audit at the latest. The batch ID should be a required field in every DPP record — not an optional metadata field.

The regulatory landscape is complex, but the technical patterns are manageable. The key is to treat update capability not as an afterthought, but as an architectural principle from day one.