Skip to content
InfoDPP Logo
InfoDPP
ESPR knowledge hub
technology

Who Can Operate a DPP? EU Rules for Service Providers

What the EU is preparing for DPP service providers: certification, interoperability, backup rules, and platform governance.

· 9 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 is expressly for economic operators. It does not publish a service-provider enrolment route, provider certification procedure or public certification list. Regulation (EU) 2026/1778 still requires a Registry list of verified providers and a semantic repository, but “verified” means Registry identity and access verification, not certification under the future ESPR delegated act.

Why This Topic Matters Now

The European Commission is no longer discussing Digital Product Passports only as a product-level compliance tool. It is now also preparing rules for the companies that will operate the infrastructure around them.

That matters because a DPP service provider is not just a software vendor. In practice, such a provider may host product records, manage access rights, maintain backup copies, support interoperability, provide APIs, and make sure passport data remains available when products move through the market.

For companies choosing a DPP platform, this shifts the question from “Can this vendor generate a QR code?” to “Is this architecture likely to remain workable as EU governance rules become more specific?”

What the Commission Is Actually Preparing

The European Commission has opened a dedicated initiative on Digital product passport: rules for service providers under the ESPR framework. The initiative states clearly that the Commission intends to adopt a delegated act laying down rules on the operation of DPP service providers as an essential part of wider DPP governance.

The process has followed this timetable:

  • call for evidence: 12 November to 10 December 2024
  • public consultation: 8 April to 1 July 2025
  • draft act: still upcoming
  • Commission adoption: currently signalled for 2027. The Commission’s new DPP timeline contains duplicate entries pointing to Q2 and Q3 2027, so a precise quarter should not be treated as settled until the page is corrected or the draft act is published.

The final rules have not been published. The Commission has already asked the market specific questions about data storage, data management, and the possible need for a certification scheme for service providers.

What the Future Act Is Legally Empowered to Contain

ESPR Article 11 defines the Commission’s authority to adopt these rules. The delegated act may set:

  1. entry requirements a DPP service provider must meet in order to become such a provider;
  2. a certification scheme, where appropriate, if the Commission decides to establish one; this does not mean participation would necessarily be voluntary; and
  3. ongoing requirements that providers must meet while supplying 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 published empowerment does not yet specify capital thresholds, mandatory ISO certificates, a licensing authority, a particular cloud architecture or a single certification route. Portability, continuity, cybersecurity, role separation and interoperability are credible subjects because they appear in the existing ESPR duties and consultation record, but they remain expected design topics rather than final legal requirements until a draft or adopted act says so.

ESPR already sets several requirements: DPP data may be stored by the economic operator or a provider; the system must maintain a high level of security and privacy; providers may not sell, reuse or process DPP data beyond what is necessary for the service unless the economic operator specifically agrees; and Article 10(4) requires the economic operator to make a back-up copy available through a DPP service provider. Recital 38 describes that back-up provider as an independent third party. The future act can add detail to these existing requirements.

What the Adopted Registry Regulation Changes

Regulation 2026/1778 is not the promised service-provider delegated act, but it makes the infrastructure role more concrete.

  • The Registry must keep a list of verified DPP service providers. This is not a quality mark, accreditation or proof that a provider is certified under future service-provider rules.
  • Where a service provider acts as an eligible value-chain actor, it must be verified before it can create or modify registry registrations. The registration check also validates a backup-provider reference where that reference is relevant.
  • The Commission must operate a machine-readable semantic repository with documented APIs and common formats. That creates a horizontal interoperability component, but it does not dictate one commercial platform architecture or publish a complete integration contract.
  • The economic operator remains responsible for the accuracy of its DPP and registration data. A verified provider may operate technical functions, but registry verification does not transfer product-law responsibility.

The separate delegated act remains the place to watch for provider-operation requirements, any certification scheme and fuller backup/continuity rules.

Battery caveat: this ESPR initiative should not be read as if it already rewrote the Battery Regulation. In its May 2026 answer to Parliament, the Commission clarified that Regulation (EU) 2023/1542 refers to authorised operators acting on behalf of the responsible economic operator, not ESPR-defined DPP service providers. In practice, the responsible economic operator remains responsible for the battery passport. It may authorise an operator to handle technical or organisational tasks on its behalf, but that does not transfer responsibility or automatically turn every SaaS platform into a future ESPR “DPP service provider”.

Existing Requirements and Issues Raised in Consultation

Even before the final delegated act is published, several points are already clear from the initiative text and from the consultation record.

1. DPP service providers will be treated as a distinct governance role

The initiative treats the operation of DPP infrastructure as a distinct function connecting economic operators, consumers, regulators, customs systems and market surveillance authorities.

2. The debate is not about whether governance rules are needed

The debate is about what those rules should look like. That is an important distinction. The need to define responsibilities is already recognised. The open questions concern certification, role separation, data ownership, and technical expectations.

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 will matter

The ESPR framework already contains the idea that DPP data must remain available even if the original operator or economic actor disappears. The provider debate now makes this operational: who stores backup copies, when they are released, and whether backup should be a separate role.

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 Is Still Open

The final provider-specific requirements, assessment arrangements and application dates remain to be settled.

1. The final certification model is not published

We do not yet know whether the delegated act will require full ex-ante certification, a lighter conformity assessment, voluntary certification, or a hybrid model.

2. The boundary between primary hosting and backup is not fixed

The legal and operational distinction between a platform that actively serves a DPP and a provider that only preserves a continuity copy is still under discussion.

3. The final technical expectations are not yet codified

The policy direction is clearly pro-interoperability, but the delegated act has not yet defined the exact standards stack, system obligations, or verification mechanics for providers.

4. Financial and organizational barriers are not settled

Ask providers to separate hosting, backup, migration and any future certification costs in their offers. Consultation preferences do not determine the final fee structure or exemptions.

What Companies Can Safely Do Now

Companies can prepare before the final delegated act is published by choosing systems that can adapt as the requirements develop.

1. Favor open and portable product records

Do not build your workflow around a platform that makes exports difficult, identifiers opaque, or migration painful. Even without the final act, portability is one of the safest assumptions a company can make.

2. Ask about data rights and the terms for leaving a service

Ask prospective DPP providers:

  • who owns the product data
  • how it can be exported
  • what happens if the service ends
  • how backup and continuity are handled

Clarify these terms before signing a contract.

3. Treat governance as part of product selection

Do not assess providers only by front-end features. Ask for evidence of how they handle access rights, audit records, distinct user roles, structured data and long-term maintenance.

4. Avoid architectures that are hard to adapt later

Compare export formats, migration terms and change-management procedures before signing. These checks can reduce switching costs without assuming that the future act will require one particular architecture.

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.

OriginPass

Prepare Your Product Data for ESPR

Start building your Digital Product Passport — structure product data, map identifiers, and get ready before delegated acts arrive. Free plan available.

No credit card required · Free plan available · Start at your own pace