Who is allowed to view which data from the product passport?
Access to the passport varies by user and by data
Not everyone who scans the QR code of a digital product passport sees the same data. The ESPR (Regulation (EU) 2024/1781) is based on differentiated access: part of the information in the passport is visible to everyone — think of basic information about the product and the key sustainability characteristics — and another part is reserved for specific parties, such as market surveillance authorities, customs or market participants further down the supply chain. This distinction exists, among other things, to protect confidential business information, while consumers and supervisory authorities still have access to the data that is relevant to them. Article 10 of the ESPR describes this principle; article 11 regulates that the technical system in which the passport operates must also be able to enforce this distinction.
Which data this applies to, and what falls outside it
This distinction in access rights concerns the content of the digital product passport itself: who may view which data field once the passport is active. It is not about the question of who may create or modify the passport — that remains the responsibility of the manufacturer, the importer or a party authorised by them. It is also not about the general protection of personal data; that is covered by existing privacy legislation and is separate from the ESPR. And it does not determine which product groups will have a passport in any case or when — that is determined separately for each product group in a delegated act. Articles 10 and 11 ESPR outline the general framework for access; the precise specification per data field — which field is public and which field has restricted access — is part of that product-specific regulation.
When this distinction will apply in practice
The rules on differentiated access in articles 10 and 11 ESPR form the framework within which product groups are developed, but only become concrete once a product group actually falls under a delegated act. For most product groups, it is not yet clear when that moment will come. Until then, there is no mandatory passport for those products and therefore no applicable access regime. What is established, however, is the principle itself: the passport is not a single indivisible whole that is equally accessible to everyone, but a dataset within which differentiation can be made per user group. Once it becomes clear for a product group which data are mandatory, it should also include which parties have access to it.
What this means for anyone having a passport drawn up
In practice, it is advisable to take this distinction into account early in the process, in this order. First: check whether, and if so when, your own product group falls under a delegated act — it specifies which data are mandatory in the passport and who has access to it. Next: distinguish between data that can easily be public, such as general product information for the consumer, and data that is more sensitive, such as technical specifications that say something about the production process or the supply chain. Then: record which of that sensitive data is considered confidential business information, so that this can be taken into account when compiling the passport. Finally, it is important to know that supervisory authorities and customs, when necessary for their task, may have a broader access level than the ordinary consumer — this is not a choice of the manufacturer, but a given that the system must take into account. The platform or system in which the passport is hosted must be able to technically support this difference in access rights; this follows from the requirements for technical design in article 11 ESPR.
Where this is set out: articles 10 and 11 ESPR
The principle of differentiated access to the content of the digital product passport is set out in Article 10 of the ESPR (Regulation (EU) 2024/1781), which describes the requirements for the passport, including the handling of confidential information and the different categories of users. Article 11 of the same regulation governs the technical design and operation of the passport, and stipulates that the system in which the passport operates must also technically guarantee these access rights.
What you can do now
Check whether a delegated act is already in sight for your own product category, and when compiling the passport, already review which data are likely to become public and which are more sensitive. For the official, up-to-date text of Articles 10 and 11, the EUR-Lex page of the ESPR is the source to rely on.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 11 (technical design and operation of the digital product passport)
The regulation itself is on EUR-Lex. We provide references for each claim; you do not have to take our word for it.
What you must do concretely
What is expected of you
The digital product passport is not a document with a single access level. The ESPR is based on layered access: some data is accessible to everyone who scans the QR code, other data is intended only for specific parties such as market operators, authorities or repairers. This distinction must be reflected in the way the passport is technically configured.
Distinguishing between public and restricted data
Article 10 of the ESPR (Regulation (EU) 2024/1781) specifies which categories of data belong in a product passport, but not every category is visible to every visitor. For a company with 10 to 100 employees, this means that when compiling the passport, a choice is made: which data is suitable for the consumer standing at the shelf, and which data is actually intended for an assembler, a recycler or a market inspector. This distinction is separate from the question which data goes into the product passport of products — that question concerns the content, this question concerns who gets to see which part of that content.
Link access to the user's role
Article 11 of the ESPR (Regulation (EU) 2024/1781) describes the technical design and operation of the digital product passport, and it shows that access to data can be differentiated according to user category. For a company, this means in practice that the platform on which the passport is hosted must be able to distinguish between a consumer looking for general product information, a market operator who needs further supply chain data, and a supervisory authority that has access to a broader set of data. Those who have to set this up technically themselves face a considerable task; those who have their passport hosted by a platform that already supports this layered access do not need to build this part themselves.
Shielding commercially sensitive information without evading the obligation
Not all data that belongs in a passport is suitable for full public disclosure. The ESPR provides room to restrict certain data to specific user groups, but that is not a free pass to omit sensitive information entirely. What can and cannot be done in this regard is described in more detail under do I have to make commercially sensitive data about my products public. For the question of who may see what, the relevant point is that restriction is a matter of access level, not of removing data from the passport.
Ensuring the right party can access the right data
A third element is more practical in nature: the passport must be designed so that a supervisory authority, a market operator further along the chain or a repairer can actually access the data that is relevant to them, without being dependent on the manufacturer having to look something up and send it on. This also touches on the question do I need to include information about repair and parts in the product passport — repair information only has value if the party carrying out the repair can actually access it, at the time it is needed.
Where things go wrong in practice
A number of situations come up regularly in practice.
A company puts all data on one publicly accessible level, including information that was actually only intended for supervisory authorities. This solves the technical task of layered access by simply avoiding it, but in doing so also puts commercially sensitive or otherwise sensitive data on display.
Another company does the opposite: out of caution, as much as possible is put behind a login or restricted access, including data that is actually intended for the consumer. The result is a passport that, when scanning the QR code, shows little more than a reference "get in touch", whereas the intention was that basic information is directly visible.
A third situation arises when a company works with multiple product groups and uses a different platform or a different approach for each group. Access levels configured for one passport do not automatically apply to the other, and supervisory authorities or supply chain partners who consult different products from the same company encounter inconsistent access.
A fourth situation: a company assumes that access to the passport is a one-time setting, while data and the users associated with it change over time. This raises the question how often must I update the data in the digital product passport — a modified parts list or a new recycling method has little value if the party that needs this information does not have access to the updated version.
A fifth situation occurs with companies that export within the EU and think that access levels differ by language or by member state. Access is linked to the user's role, not to the language in which the data is displayed — a distinction that is also relevant to the question must I offer the product passport in multiple languages.
What you can document
- An overview of which data categories in the passport are publicly accessible and which are restricted to specific user groups, including the reason for that choice.
- A description of which roles have access to which level: consumer, market participant, supervisory authority, repairer or recycler.
- Agreements with the hosting platform on how access levels are technically enforced, and who is responsible if that access needs to be adjusted.
- An established procedure for updating access rights when data changes or when new user groups become relevant.
- Documentation of which data have been designated as business-sensitive and at which access level they have been placed.
- An internal point of contact for questions from supervisory authorities or supply chain partners about access to specific data in the passport.
For companies working with multiple product groups, it is advisable to establish these agreements once centrally, so that the same choices do not have to be made for each passport again. Anyone who is uncertain whether a particular product group already falls under these obligations will find a first point of reference at does the digital product passport apply to my products.
This is not legal advice. This page provides general information about the regulations that this platform concerns. We do not know your situation. If you are in doubt about your own case, consult a lawyer or the competent supervisory authority.
Written with AI on the basis of the sources above, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections are given priority.