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 the Service Provider Layer Matters

Many companies still think about Digital Product Passports at the visible layer: 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, expose, back up, and govern 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 a regulated or semi-regulated part of the DPP ecosystem, 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 real questions are architectural:

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 legal envelope is narrower than the policy debate

ESPR Article 11(2) 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.

This is what can safely be described as the act’s guaranteed scope. Recital 40 adds a non-operative but relevant clue: it anticipates clearer roles and responsibilities for issuing agencies and service providers in the creation, authentication, processing and storage of DPP data and, possibly, the withdrawal of important DPP elements such as identifiers and data carriers. It does not itself impose those detailed duties or guarantee that every item will appear in the final act.

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 construction 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. Governance is becoming a first-class requirement

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. Portability is emerging as a core design expectation

The consultation record strongly suggests that DPP systems should not be designed around permanent dependency on one vendor. This points toward open structures, exportability, and provider-switching logic as core platform concerns.

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

The most defensible architecture is one in which the economic operator remains the owner of the product data and the provider supplies the technical service layer around it.

This means a serious platform 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

If a platform cannot explain that clearly, it is already weak from a governance perspective.

2. Interoperability and anti lock-in

This is the strongest consensus point in the consultation record.

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 is the lower-regret preparation choice, 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
snapshot or continuity-copy logic
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

This is one of the clearest signs that DPP platforms are closer to regulated infrastructure than to ordinary content-management tools.

Certification: What Is Known and What Is Not

Certification is one of the biggest open questions in the provider debate.

What is already known

the Commission explicitly asked whether a certification scheme is needed
some stakeholders strongly support independent ex-ante certification
others support lighter or more flexible models
security and governance maturity are already visible as major expectations

What is not yet known

whether certification will be mandatory for all providers
what body or process would assess providers
whether the final model will distinguish between different provider roles
how burdensome the process may be for smaller software companies

The practical takeaway for platforms is straightforward: build as if you may eventually need to demonstrate structured governance, auditability, reliability, and security maturity.

Why Decentralized Architecture Keeps Coming Up

One of the strongest design signals in the feedback is support for decentralized governance.

This does not mean every DPP must be self-hosted or fully distributed in a technical sense. It means stakeholders want to avoid a model where one provider becomes the unavoidable, opaque owner of a company’s product information.

For platforms, that suggests a more resilient approach:

the customer owns the product data
the provider operates the service layer
exports and portability are normal, not exceptional
backup continuity does not imply provider dominance over the full data ecosystem

This aligns well with the broader EU preference for open standards and interoperable digital infrastructure.

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 logic

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 migration logic 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?

These are not edge-case procurement questions anymore. They go to the heart of how credible a provider’s DPP architecture really is.

Strategic Takeaway

The final delegated act for DPP service providers is still ahead. But the design direction is already visible enough to support practical decision-making.

The most resilient DPP platform model is unlikely to be one built around opacity, proprietary exit barriers, and weak continuity logic. The stronger model is one built around:

clear governance
exportable structured records
interoperability
role-based access
backup and continuity discipline

Companies do not need to wait for every technical detail to be final before using those criteria.

Official Sources

If DPP platforms are moving toward stronger governance, portability, and continuity requirements, it makes sense to work with an operator that already follows those questions closely. OriginPass approaches product records as structured, portable infrastructure, not just front-end passport pages.

Continue Reading

Related guides