Keeping DPP Data Current: What ESPR Actually Requires

Since the adoption of ESPR Regulation (EU) 2024/1781, the Digital Product Passport (DPP) has been binding EU law. What many companies underestimate: the DPP is not a static document created once at market launch. It must be kept current throughout the entire product lifecycle — and the requirements for doing so are becoming increasingly precise.

This article explains which data must be updated when, how the registry architecture shapes the update model, and which technical patterns have proven effective in practice.

What the Regulation Says About the Update Cycle

Static vs. Dynamic Data Fields

The ESPR itself does not specify an explicit update frequency, but it does require that the DPP contain "current and accurate information." The details are defined at the sector level — and here the JRC draft for semi-finished iron and steel products provides the clearest picture to date.

The draft systematically distinguishes between two levels of data granularity:

Level	Identifier	Example Data	Update Trigger
Lot level	Lot number	Recycled content, alloy composition, PCF per ISO 14067	On production change, new lot
Item level	Serial number	Dimensions, certifications, declarations of conformity	On recertification, recall, repair

This distinction is critical for database architecture: lot-level data is typically written once per production run and remains stable thereafter — unless a recalculation of the carbon footprint yields a corrected value. Item-level data, on the other hand, can change throughout the entire service life, for example when a device is repaired or a certification is renewed.

The Battery Regulation (EU) 2023/1542 already implies this distinction: capacity data that changes through degradation must be kept current — a requirement that is nearly impossible to meet without a clear architecture.

The Registry as a Directory, Not a Data Store

A common misconception concerns the role of the central DPP registry. The draft implementing regulation on the DPP registry makes it clear: the registry stores only the unique identifier, the resolver endpoint, and the commodity code — not the actual passport data.

For update management, this means: passport content and registry are separate systems. When you update product data, you generally do not need to touch the registry — unless the resolver endpoint changes (for example, during a system migration). The CIRPASS-2 consortium explicitly highlighted this architectural pattern in its comments on the registry draft and recommends incorporating standard EN 18219 as a binding reference in the implementing regulation — in part to ensure interoperability with GS1 Digital Link.

Update Scenarios in Practice

Scenario 1: New Carbon Footprint Due to Supplier Change

The product-specific carbon footprint (PCF) is maintained at the lot level under the JRC steel draft and must be calculated using ISO-14067-compliant methods. If a steel producer changes its energy source or scrap supplier, the PCF of the new lot changes — but the PCF of already-delivered lots does not.

Technically, this means: the DPP record for the old lot remains unchanged. For the new lot, a new record is created that can use the same resolver endpoint but carries a new lot number as its identifier.

# Example: Create a new lot record via API
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scenario 2: Expiring Certification at the Item Level

Declarations of conformity and certifications have expiration dates. Once a new certification is issued, the DPP must be updated at the item level. Since the resolver endpoint remains unchanged, no registry update is required — only the record behind the endpoint changes.

// TypeScript example: update a certification
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scenario 3: Resolver Migration During a System Change

When a company switches its DPP service provider, the resolver endpoint changes. In this case, the registry must be updated — for every affected identifier. This is the most labor-intensive update type because it requires a registry write.

Recommendation: use a stable, company-owned resolver (e.g., dpp.yourcompany.com) as an intermediary layer that internally redirects to the respective service provider. This keeps the endpoint registered in the registry permanently stable.

Technical Requirements for the Update System

Versioning and Audit Trail

The ESPR does not explicitly require versioning, but the combination of product liability and customs controls makes an audit trail practically unavoidable. If a customs officer in 2030 checks the DPP of a steel beam produced in 2027, it must be possible to trace which data was valid at the time of import.

Minimal schema for a versioned DPP table:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = currently valid
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link as a Stable Identifier Anchor

GS1 Digital Link cleanly separates identifier and resolver: the QR code on the product encodes a URL such as https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, which points — via the GS1 resolver or a company-owned resolver — to the current DPP record. Updates to the record require no re-labeling; the physical data carrier remains unchanged.

TEKLYNX has updated its CODESOFT software to support GS1 "++" encoding schemes, enabling web URLs to be written directly into RAIN RFID tag memory — a requirement that follows from the combination of EN 18220 and the GS1 Digital Link standard.

Governance: Who Can Update What?

Beyond the technical question, there is a governance question: which actors in the supply chain are permitted to write which fields of the DPP? The CIRPASS-2 consortium has identified critical issues around data sovereignty in cross-border supply chains.

A practical model distinguishes three roles:

Manufacturer (Creator): Writes all fields at creation; may update all fields.
Authorized actor (Editor): May update defined fields (e.g., repair history, new certifications) — documented with their own identifier.
Reader: Can read all public fields; no write access.

Ecommerce Europe has called for "partial DPPs" to be possible for second-hand products as well — meaning records that update only a subset of the original fields. This is technically feasible today, but it has yet to be established as a formal category in the implementing regulations.

Conclusion

Keeping DPP data current is not a one-time effort — it is an ongoing operational process. The key takeaways from the current regulatory landscape:

Separate lot and item — your identifier strategy determines which data must be updated when.
The registry is not a data store — updates to passport content generally do not require a registry write.
Versioning is effectively mandatory — even if the regulation does not explicitly require it.
GS1 Digital Link decouples the physical data carrier from the data record — this significantly reduces the effort involved in data updates.
Governance roles must be defined upfront — who is allowed to write what, and how is it logged?

The standards are becoming more precise and the first pilots are underway — organizations that get the architecture right now will avoid costly corrections once the sector-specific implementing regulations enter into force.