Why "register once" isn't enough
Many companies treat the Digital Product Passport (DPP) as a one-time compliance exercise: collect the data, create a registry entry, done. The ESPR Regulation (EU) 2024/1781 tells a different story. It requires that registry entries remain available and current for at least 10 years after the last time a product is placed on the market. If you discontinue a model today, you must maintain its entry until at least 2036 — including valid resolver endpoints and correct unique identifiers.
This article explains what updating a registry entry actually involves, which fields are affected, and how to secure the process on the technical side.
What the registry stores — and what it doesn't
On April 29, 2026, the European Commission published the draft implementing regulation for the central DPP registry. The document makes clear just how lean the central registry is designed to be: it stores only three data elements per entry:
| Field | Description | Update obligation |
|---|---|---|
| Unique Identifier (UID) | Unique identifier for the product/model | Immutable once assigned |
| Resolver endpoint | URL where the full DPP can be retrieved | Updatable; required upon migration |
| Commodity code | Product category code (e.g., HS or CN code) | Correctable in case of erroneous entry |
The actual product data — material composition, repairability index, carbon footprint — is not stored in the central registry. It is provided by the manufacturer or an authorized data trustee at the resolver endpoint. The registry is simply the address book. This separation matters architecturally: an update to the central entry is only necessary when the UID, resolver, or commodity code changes. Content-level data maintenance happens exclusively on the data provider's side.
The product-specific data requirements — what exactly must appear in the DPP — remain the domain of sector-specific regulation, such as the delegated regulations under ESPR or, for batteries, the Battery Regulation (EU) 2023/1542.
When a registry update is mandatory
The resolver endpoint has changed
This is the most common real-world scenario. Companies switch cloud providers, migrate to new DPP platforms, or consolidate domains. As soon as the previous resolver endpoint becomes unreachable, no scanner — whether a customs authority, market surveillance body, or end consumer — can retrieve the DPP. The regulation does not explicitly specify a response window, but the 10-year availability obligation effectively creates zero tolerance for permanently broken links.
Recommendation: Use a stable, company-owned subdomain resolver (e.g., dpp.yourcompany.com) as an indirection layer. That way, when you switch platforms, you only need to reconfigure internally — without touching the registry entry. This follows the principle of GS1 Digital Link, where the QR code points to a stable resolver that in turn redirects to changing backend systems.
An incorrect commodity code was entered
Commodity codes (CN or HS codes) determine which delegated regulations apply to a product. An incorrect code can result in the product being classified in the wrong category, or being misclassified during automated border checks — which the EU plans to introduce from 2028 under the proposed Circular Economy Act. Corrections are permitted under the draft implementing regulation, but require documented justification.
Corporate acquisition or license transfer
When a product changes economic ownership, you need to assess whether resolver responsibility is being transferred as well. The registry account is tied to the original registrant; a transfer requires a formal process through the competent national authority.
Technical process: updating an entry
The implementing regulation provides for an API-based interface to the registry. The exact endpoint will only be published once the regulation enters into force, but the expected workflow can be derived from the draft:
# Authentication via OAuth 2.0 Client Credentials
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X POST https://registry.dpp.ec.europa.eu/oauth/token \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_SECRET" \
-d "scope=registry:write"
# PATCH request to update the resolver endpoint
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X PATCH https://registry.dpp.ec.europa.eu/v1/entries/{uid} \
-H "Authorization: Bearer {ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/{uid}",
"updateReason": "platform_migration"
}'
The updateReason field is designated as mandatory in the draft for all changes other than the initial entry. Permitted values include platform_migration, domain_change, commodity_code_correction, and ownership_transfer. The audit history of all updates is retained by the registry for the full 10-year period.
Bulk updates for large product portfolios
Companies with thousands of SKUs cannot manage individual requests manually. The draft regulation provides for a batch endpoint:
{
"batchUpdate": [
{
"uid": "urn:epc:id:sgtin:0614141.107346.2017",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2017",
"updateReason": "platform_migration"
},
{
"uid": "urn:epc:id:sgtin:0614141.107346.2018",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2018",
"updateReason": "platform_migration"
}
]
}
Building and maintaining these bulk processes calls for structured data management, as required by a bulk import workflow for DPP entries.
International standardization as a stability anchor
An update process is only as robust as the standards it is built on. This is where the establishment of ISO/IEC JTC 5 comes in: the new Joint Technical Committee, whose secretariat is held by the German Institute for Standardization (DIN), is tasked with developing international standards for the global interoperability of DPP systems.
In practical terms for update processes: once ISO/IEC JTC 5 adopts standards for data formats, API schemas, and identifier structures, these are expected to feed into future revisions of the ESPR implementing regulations. Companies that already rely on GS1-compliant identifiers (GTIN, SGTIN) and GS1 Digital Link resolvers are well positioned: these standards are considered the reference implementation for JTC 5.
The WTO notification of the EU registry regulation (G/TBT/N/EU/1211) on May 21, 2026 also signals that the system is classified as a technical trade regulation — with implications for third-country manufacturers exporting products to the EU. They, too, must maintain and keep registry entries current.
Data maintenance as an ongoing process: organizational implications
The 10-year obligation is not solely an IT task. It requires organizational measures:
- Document accountability: Who in your organization is responsible for registry entries? This role must remain filled even through staff turnover and corporate restructuring.
- Set up resolver monitoring: Automated availability checks (HTTP status checks) for all active resolver endpoints are not a nice-to-have — they are an operational minimum.
- Maintain a change log: The audit history in the registry is accessible to authorities. Supplement it with an internal change log that includes justifications and approvals.
- Review contracts with platform providers: If you use an external DPP service provider, the contract must explicitly cover the 10-year availability requirement — including provisions for insolvency or business closure of the provider.
On May 27, 2026, the European Commission held a webinar on Battery DPP implementation that explicitly addressed the data maintenance challenges facing SMEs. The message was clear: long-term data availability is not a technical detail — it is a core obligation.
Conclusion
A DPP registry entry is not a static document. The April 2026 implementing regulation establishes a legal framework that requires manufacturers to actively and documentably maintain their data over a decade. The good news: the central registry is deliberately kept lean. If you design resolver endpoints for stability, use GS1-compliant identifiers, and embed change processes into your organization, the technical overhead for updates remains manageable — and you will be well prepared for the upcoming ISO/IEC JTC 5 standards.