Who is allowed to hold your passport data, and what they may do with it
The framework defines a class of company, requires you to use one, and restricts what it may do with your data. Then it adds four words that turn the restriction into a default you can contract out of. The registry does verify these companies, and that verification establishes who they are rather than whether they are any good at it. The scheme that would establish the second thing is a power the Commission holds and has not used.
On this page
The short answer
Four provisions decide this, and reading them together produces a different picture from reading any one of them.
You must use one. Article 10(4) of the Ecodesign for Sustainable Products Regulation requires the economic operator, when placing the product on the market, to make available a backup copy of the passport through a digital product passport service provider. This is not optional and it is not satisfied by hosting it yourself.
They are restricted in what they may do with your data. The second subparagraph of Article 11 says that where a passport is stored or otherwise processed by such providers, they "shall not sell, reuse or process such data, in whole or in part, beyond what is necessary for the provision of the relevant storing or processing services".
Except that the same sentence ends "unless specifically agreed with the economic operator placing the product on the market or putting it into service". The restriction is a default, not a prohibition. It can be switched off by agreement, and the party agreeing is you.
And they are verified, though not for the thing you would assume. The registry keeps a list of verified providers, and the verification behind that word is an identity check performed to an eIDAS standard. The separate power to set requirements for becoming one of these companies, and to certify them against those requirements, sits in the third subparagraph of Article 11 and has not been used.
So the practical answer to the question a business is actually asking is short. A provider on that list has proved who it is and nothing further, the only binding restriction on what it does with your data is one that your own contract can waive, and the thing to go and read this week is that contract.
What one actually is
Article 2(32) defines it, and two phrases in the definition do real work:
'digital product passport service provider' means a natural or legal person that is an independent third-party authorised by the economic operator which places the product on the market or puts it into service and that processes the digital product passport data for that product for the purpose of making such data available to economic operators and other relevant actors with a right to access those data under this Regulation or other Union law
Article 2(32), quoted verbatim."Independent third-party." On the face of it, a subsidiary inside your own group is not an independent third party. A business planning to satisfy Article 10(4) by pointing at its own hosting arrangement should test that reading with somebody qualified before relying on it. We have not found the point addressed anywhere, and how this estate handles a question in that state is set out at how we know.
"Authorised by the economic operator." The authorisation is private. It comes from you, in a contract. It does not come from a regulator, and we found nothing in either instrument that has a regulator review the terms of it.
The four words that matter most
Read the restriction twice, because the second half changes the first.
The prohibition on selling, reusing or processing your passport data beyond what the service requires is real, and it binds the provider directly rather than through your contract. It is also expressly subject to specific agreement with you. That means the protection you actually have is not a statutory floor. It is whatever your contract says, with the statute supplying the answer only where the contract is silent.
Three things follow, and they are all actionable this week.
- Somebody should read the data clauses in your provider agreement against that sentence. A clause permitting the provider to use aggregated, anonymised or derived data for product development, benchmarking or analytics is the clause that constitutes the specific agreement. It may be entirely reasonable. It should be a decision rather than a discovery.
- Silence favours you. If the contract says nothing, the default restriction applies. That is an unusual position in commercial contracting and it is worth not accidentally trading away.
- The restriction only binds the provider. It says nothing about who else may reach the data, which is a separate question decided per product group in the delegated act, and set out at what a delegated act will actually decide about your products.
Verified, and the question of verified for what
This is the part most likely to surprise a buyer, and an earlier draft of this page had it wrong. The correction is worth stating plainly, because the wrong version is the version most of the market is working from.
These companies are verified. Article 3(f) of Commission Implementing Regulation (EU) 2026/1778 makes a list of verified digital product passport service providers registered in the registry one of the registry's components. Recital 4 of the same instrument names a digital product passport service provider first among its examples of a value chain actor, and says that each economic operator and value chain actor should be identified through a verification process. Article 5 is that process. Article 8(7)(e) has the Commission confirm the link to the backup hosted by a provider at the point of registration, and Article 8(9)(c) stores a reference to the provider as registration data.
How this page reaches Article 5 is worth showing rather than asserting. The instrument contains no article that says in terms that a service provider is verified under Article 5. It contains a recital placing providers in the value chain actor class, an open definition of that class in Article 2(6) introduced by the words "such as", and an Article 5 that verifies that class. Reading those together is an interpretation, and a recital guides how an instrument is read rather than creating the obligation itself. What the instrument does not publish is the entry criteria for the Article 3(f) list as a list.
What that verification actually establishes
Read Article 5 slowly, because it decides what the word carries.
A provider that is a legal person obtains verified status by submitting evidence of its identity and of its establishment by means of a qualified electronic seal supported by a qualified certificate for electronic seal, issued by a qualified trust service provider, or by a qualified electronic attestation of attributes issued under Union law. Article 5(3) restricts registry access to verified value chain actors, and allows them to perform actions there only where the relevant Union law specifies. Article 5(4) makes the status expire when the electronic identification means expire and in any event within three years.
So verification establishes three things. That the company is who it says it is. That it legally exists. That, where applicable, it is established where it says it is. It is an identity check against a trust service, and it has to be repeated.
It establishes nothing about the service itself. Not competence. Not security practice. Not solvency. Not whether your passports remain readable for the period a delegated act sets, which is at least the expected lifetime of the product. A qualified electronic seal proves that a company exists. It does not predict that the company will continue to.
The check that would speak to any of that has been provided for and not made. The third subparagraph of Article 11 of the framework gives the Commission power to adopt delegated acts setting out the requirements that providers are to comply with in order to become such providers, and where appropriate a certification scheme to verify compliance with those requirements, and the requirements they are to comply with when providing the services. Recital 40 of the framework goes one step further back and contemplates an impact assessment into whether such a scheme is appropriate at all. We found no such act adopted as at the date on this page, and the Commission's own roadmap places one in 2027.
So the word "verified" is doing two jobs, and a buyer needs to know which one is in front of them. In the registry it means an identity was proved to an eIDAS standard and will need proving again. In sales material it is often used to suggest an assessment of the service, which is the assessment that has not been created. The useful question is not verified by whom. It is verified for what.
What does not move, whoever holds the data
The temptation with any hosting arrangement is to assume responsibility travels with the data. It does not.
Article 19(5) of the implementing regulation makes the verified economic operator the controller of the data it submits. Article 19(1) and 19(2) put accuracy and completeness on that operator at registration and continuously afterwards. Article 19(4) lets a third party act on your behalf, requires that third party to go through the Article 5 verification itself, and then says that you remain fully responsible for compliance regardless. That is the clearest statement in either instrument of what verification is and is not for. It admits somebody to the system. It does not move your liability onto them.
Changing who hosts your data is therefore a supplier decision rather than a change in who answers for the record, which is a distinction worked through at what happens to your passports when the business changes hands. And the questions that decide whether an arrangement survives the provider failing rather than merely changing are at when the link dies, which is the other half of this subject and deliberately not repeated here.
What to ask, and in what order
The existing questions about continuity, export and identifier ownership still apply and are on that page. These are the ones this page adds, and every one of them is answerable in a sentence by a provider who has thought about it.
- Show me the clause that constitutes specific agreement under the second subparagraph of Article 11. If there is none, say so in writing. If there is one, tell me what it permits.
- Are you an independent third party in relation to us, and are you relying on that status to satisfy Article 10(4)?
- What appears in the registry as the service provider reference against our registrations, and does it name you or us?
- Are you on the verified list held in the registry, when were you verified, and when does that verification expire? Article 5(4) caps it at three years, so a provider that cannot answer the second and third parts has not been through it.
- What happens to the data you hold about our products if we move to another provider, and what do you retain?
- When the service provider requirements are adopted, who bears the cost of meeting them? That is a question about a future act, and asking it now tells you whether the provider has read the framework or only the marketing.
What to do now
For most readers there is no obligation here yet, because the passport duty itself arrives with a product act that has not been adopted, and every date in that chain is kept on the status record rather than asserted here.
Two things are still worth doing, and neither needs a budget.
Read the contract you already have. Any business already using a product data platform may already have signed the specific agreement without anybody framing it as one.
Separate the verification that exists from the certification that does not. A provider describing itself as verified may be pointing at a real entry in the registry, which is worth having and is a statement about identity. A provider describing itself as certified or approved under this framework is describing a scheme the Commission has not yet created. Asking which of the two is meant is a fair question and the answer is short. What the registry actually holds, and what stays with you, is set out at where your passport data actually lives.
You might want to read next
Sources
-
Relevant provisions reviewed
Carries most of this page. Article 2(32), and the second and third subparagraphs of Article 11, obtained verbatim from the enacting terms. Also Articles 10(1), 10(4) and 11, first subparagraph, point (c), with recital 40. Article 11 has no numbered paragraphs, and an earlier draft of this page cited its subparagraphs as 11(1) and 11(2). That was wrong and the citations are corrected here. That the delegated act power has not been used is stated as an absence against the Commission's published roadmap.
-
Commission Implementing Regulation (EU) 2026/1778 establishing the Digital Product Passport registryRelevant provisions reviewed
Articles 2(6), 3(f), 5, 8(7)(e), 8(9)(c) and 19, together with recital 4, obtained verbatim. An earlier draft of this page stated that the instrument established no verification route for service providers. That was wrong. Recital 4 names a digital product passport service provider among its examples of a value chain actor, and Article 5 verifies that class, which is the route this page now sets out. The correction is recorded here rather than removed.
-
Official source confirmed, detailed review pending
The published roadmap placing a delegated act on service provider requirements in 2027, which is the basis for stating that the power has not yet been used rather than that no such act exists. Two retrievals returned slightly different renderings of the roadmap rows, so no quarter is stated here and no wording is quoted.
-
Reviewed in full
Used for one point and one absence: that the Commission acknowledges specialist service providers offering hosting including legally mandated backups, and that it does not address the verified list, how a provider joins it, or the restriction on what a provider may do with the data.
Help someone else make sense of product passports.