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

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.

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

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.

The Four Core Requirements Platforms Should Already Expect

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

The safest assumption is that future EU governance will reward platforms that reduce lock-in rather than deepen it.

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