technology

DPP Service Provider Requirements: EU Rules for Platforms

What the EU delegated-act process means for DPP platforms: governance, portability, backup, access control, and certification.

3/29/2026 · 12 min read · InfoDPP

Editorial update, 22 July 2026: the production Registry, test environment, API access and initial implementation resources are available, but the published User Guide covers economic operators only. It does not provide a service-provider enrolment path, certification procedure or public certification list. Regulation (EU) 2026/1778 requires the Registry to include a list of verified DPP service providers, but that remains identity and access verification for Registry functions, not provider certification, accreditation or a transfer of product-law responsibility.

Why DPP Service Providers Matter

Many companies still think about Digital Product Passports in terms of what users see: product data, QR codes, consumer pages, and compliance statements.

But for the EU, that is only part of the picture. There is also an infrastructure layer: the systems and providers that store, manage, provide access to, back up, and control DPP records over time.

This is why the European Commission is preparing a delegated act specifically for DPP service providers.

For software platforms, this matters directly. It suggests that DPP providers may become more than ordinary SaaS vendors. They may become subject to specific DPP service-provider requirements, expected to support portability, governance, continuity, and reliable access to product data.

What the Commission Is Trying to Regulate

The Commission’s initiative on DPP service providers states that it wants feedback on how data should be stored and managed by service providers and on the need for a certification scheme.

That framing is important because it shows that the issue is not simply front-end usability or QR-code generation. The questions concern how the service works:

who controls the data
how it is stored
who can access it
how it remains available over time
whether providers need formal qualification or certification

The final act is not adopted yet, but the governance questions are already clearly defined.

The scope of the Commission’s delegated power

ESPR Article 11 expressly empowers the Commission to set three things in the delegated act:

requirements providers must meet to become DPP service providers;
where appropriate, a certification scheme to verify compliance with those entry requirements; and
requirements providers must meet when providing DPP services.

Article 11 sets the scope of the Commission’s delegated power. Recital 40 explains the intended allocation of roles in creating, authenticating, processing and storing DPP data, and potentially withdrawing identifiers or data carriers. It does not establish a separate checklist of binding provider duties.

The exact eligibility criteria, service obligations and any certification mechanics have not been published. Portability, continuity, cybersecurity, interoperability and role separation are well-supported implementation themes, but the consultation record is evidence of policy options, not the final rule.

ESPR already supplies part of the baseline: a DPP may be stored by the economic operator or a service provider; the design must provide high security and privacy; a provider may not sell, reuse or process DPP data beyond what is necessary for the service unless specifically agreed with the economic operator; and Article 10(4) requires a back-up copy through a DPP service provider. Recital 38 describes that back-up provider as an independent third party. The delegated act is expected to make provider governance more operational, not invent these duties from scratch.

The latest Commission DPP hub places the provider act in 2027, but currently lists it twice, once in Q2 and once in Q3. Until the Commission resolves that inconsistency or publishes the draft, the year is a useful planning signal and the quarter is not.

What the Registry Regulation Adds Now

The adopted Registry regulation does not settle the future provider regime, but it removes one source of ambiguity.

The Registry will hold a list of verified DPP service providers. It should not be described as an EU certification list: verification is about access to Registry functions, not a finding that a provider meets every future operational requirement.
An eligible service provider acting in the value chain must be verified to create or modify registrations. The Registry also checks the reference to a backup provider where it is relevant to a registration.
The Regulation creates a machine-readable semantic repository with documented APIs and common formats. This supports interoperability, while leaving the final provider-specific governance rules for the separate delegated act.
An economic operator remains responsible for the accuracy of DPP and registration data. A verified platform can perform technical work without taking over that legal responsibility.

This distinction is important for procurement: ask whether a provider can support verification, versioning, semantic interoperability and export, but do not accept a claim of “EU-certified DPP provider” unless a future legal certification scheme actually supports it.

What Is Already Visible from the Current Process

1. The provider role is being separated from the product-owner role

Manufacturers, importers, and other economic operators remain responsible for product compliance. The service provider role is different: it concerns the infrastructure that enables DPP records to function in practice.

That distinction matters because it suggests the EU wants clearer boundaries between:

compliance responsibility
data ownership
technical operation
long-term continuity of records

Battery passport note: the Battery Regulation uses a different legal arrangement from the future ESPR DPP service-provider role. The Commission confirmed in May 2026 that it refers to authorised operators acting on behalf of the responsible economic operator, so that label should not be automatically transferred to every platform model. In practice, the responsible economic operator remains responsible for the battery passport. An authorised operator may support technical or organisational handling on its behalf, but it does not take over that responsibility and is not the same concept as a future ESPR DPP service provider.

2. Data governance is a central part of the initiative

The initiative does not ask whether platforms should care about governance. It assumes governance matters and asks what kind of governance model should apply.

3. Interoperability already has a legal basis

ESPR Articles 10 and 11 already address open standards, interoperability and the avoidance of vendor lock-in. These existing provisions are a firmer basis for procurement decisions than predictions about which consultation argument will shape the future provider act.

4. Backup and continuity are not secondary issues

Long-term availability of DPP data is central to the debate. Platforms that focus only on active product display may miss an important regulatory expectation if backup continuity becomes more formalized.

Four Design Areas Platforms Should Prepare For

Even before the delegated act is final, a useful preparation model is already visible.

1. Clear data ownership and governance boundaries

Define control, access and permitted uses of product data in the contract. Regulatory responsibility does not automatically settle every intellectual-property or data-ownership question.

A provider should be able to explain:

who owns the data
who may edit it
how changes are tracked
how records are exported
what happens if the service relationship ends

Unclear answers make it harder to assess control of the data and the risks of changing provider.

2. Interoperability and avoiding lock-in

Interoperability is an existing ESPR requirement, not merely a forecast based on consultation responses.

For platforms, interoperability should not be treated as a nice extra. It should shape the underlying model:

identifiers should remain portable
records should be exportable in a usable structured format
systems should avoid proprietary dependencies that make migration painful
provider switching should not force companies to rebuild their product-data foundation from scratch

A portable design can reduce the cost of later changes, but the exact provider-switching duties remain for the delegated act.

3. Backup logic and continuity planning

The DPP service-provider debate repeatedly returns to backup copies, continuity, and the question of what happens if the original operator or provider disappears.

That means platforms should already think in terms of:

active hosting versus backup-only service
snapshots and copies maintained for continuity
conditions for data release
traceable retention of the latest valid product record

Not every final detail is known, but the requirement to think seriously about continuity already exists.

4. Access control and restricted data handling

DPP is not just a public webpage for consumers. Many DPP records will contain layers of data with different access rights.

Platforms should therefore expect to support:

public-facing information
restricted B2B data
authority-access layers
auditability of access and changes

These functions require more than publishing a public product page.

What the Commission’s Consultation Report Shows

The Commission’s factual report covers 275 valid responses to the public consultation held from 8 April to 1 July 2025. It summarises participants’ views, not a representative sample of the EU population or the Commission’s final position. This is separate from the November–December 2024 call for evidence.

Certification: support for the principle, different models

Certification was rated rather or extremely important by 64 of 81 economic operators, 71 of 89 other value-chain actors and 70 of 92 prospective providers.

The preferred models included:

a hybrid of self-declaration and accredited certification: 76 of 275 respondents (27.6%)
assessment bodies accredited by the Commission: 62 of 275 (22.5%)
assessment bodies accredited through national accreditation bodies: 53 of 275 (19.3%)

No model obtained a majority. These are preferences, not an adopted certification scheme.

Turn the policy questions into procurement checks

Ask a prospective provider to demonstrate:

a structured export that another system can read
restoration from a backup and the contractual continuity arrangements
separation of public and restricted data
the cost and process for changing provider

These checks help assess a service today; they are not a prediction of every future legal requirement.

What Platforms Should Build in 2026 Even Before the Final Act

The most useful preparation steps are those that remain valuable under multiple possible final legal outcomes.

1. Structured exports

If a customer leaves, changes providers, or needs to satisfy new governance requirements, the record must be portable in practice, not only in theory.

2. Traceable audit history

Platforms should assume that the ability to show who changed what, when, and under what authority will become more important, not less.

3. Role-based access

Even if the final delegated act refines the model, differentiated access is already a reasonable baseline requirement.

4. Clear continuity policy

Platforms should define what happens to records if a customer account closes, the provider relationship ends, or continuity obligations are triggered.

5. Open architecture choices

Systems designed around open identifiers, structured records, and clear migration procedures are better positioned than systems designed around dependency and opacity.

What Companies Buying Access to a DPP Platform Should Ask

This article is not only for software builders. It is also for manufacturers, importers, and brand owners evaluating providers.

Useful questions include:

How do you handle data ownership?
Can records be exported in a structured format?
What is your approach to backup and continuity?
How do you separate public and restricted-access data?
How do you design around interoperability?
What happens if we want to change provider later?

The answers help establish whether the service can support your data, access and continuity needs.

Practical Criteria for Choosing a Provider

Base the decision on the ESPR duties already adopted and on evidence of how the service works. Treat future certification details as an open issue, and put data access, export, backup, continuity and switching terms in the contract.

Official Sources

Start with one product: create its digital product passport on OriginPass.eu.

Continue Reading

Related guides