Who can view which data from the product passport?

What you must concretely do

What is expected of you

The product passport is not a document with a single access level. The ESPR is based on layered access: some data is visible to everyone via the QR code on the product, other data only to parties with a specific role in the supply chain, and still other data only to supervisory authorities. Article 10 of the ESPR (Regulation (EU) 2024/1781) names this distinction as a requirement for the passport, and Article 11 elaborates how this is technically and organisationally implemented. For a company that processes or resells steel, this means that thought must be given to who gets to see which part of the data at which moment.

Distinguishing between public and restricted data

Part of the passport data is visible to everyone who scans the QR code: an end user, a buyer at a construction company, a supervisory authority on the move. Another part is intended only for parties with a justified interest, such as recycling companies that need material composition information, or certification bodies. For a mid-sized metal company, this means that the question "what may everyone see and what not" must be answered when compiling the passport, not afterwards. This directly touches on the question whether commercially sensitive data about steel must be made public: not everything in the product passport needs to be visible to everyone.

Link access to the role in the supply chain

Article 11 describes that the access level can depend on the role of the party requesting the data: manufacturer, importer, distributor, end-user, market surveillance authority or waste handler. For a steel trader who purchases and resells semi-finished products, this means that their own role in the supply chain determines which data are visible and which are not. A trader who resells material to a construction company thereby also passes on a degree of responsibility: the buyer must have access to the data that are relevant for application and processing, such as steel grade and composition.

Ensure that supervisory authorities always have access

In addition to the tiered access for market participants, there is a requirement that supervisory authorities (market surveillance authorities and customs) must have access to the full product passport, including parts that are not public. For a company with 10 to 100 employees, this means that no data in the passport may remain "hidden" from inspection, even if it is commercially sensitive. This distinction between non-public and non-auditable is essential: data can be restricted from the public, but never from the authorities that must be able to verify that the passport is correct.

Ensure that the access structure works technically

Article 11 sets requirements for the technical design: the product passport must be structured in such a way that different access levels can actually be applied, not only in theory. For a company that does not have its own IT department to build this, this means that the choice of hosting provider is relevant: the technology must ensure that an end user does not accidentally access data intended only for a recycler, and vice versa.

Where things go wrong in practice

A few situations that often cause confusion in practice:

A trader thinks that the product passport must be completely public, and therefore also publishes data intended only for the next party in the chain, such as internal process parameters. This often happens out of caution ("better to share too much than too little"), but without a distinction between access levels, information reaches parties who should not or cannot use it.

Another scenario: a company assumes that anything not explicitly "required to be public" can be restricted from everyone, including supervisory authorities. This distinction between public and auditable is then confused, resulting in an inspection stalling because the inspector cannot access the underlying data.

There are also situations where a manufacturer has the digital product passport created by a third party without establishing who gets what access rights. If a dispute later arises over who supplied or modified which data, there is no record of who had access when.

Furthermore, it happens that a company equates the access structure of the digital product passport with that of an inspection certificate 3.1, whereas that is a different document with a different function and different audience. This leads to confusion about what is precisely shared with whom; how an inspection certificate 3.1 relates to the digital product passport is therefore a question that often accompanies this one.

Finally: a company compiles the data without distinguishing between what is technically (composition, standard) and what is commercially (supplier prices, internal specifications) sensitive, with the result that afterwards it turns out that competition-sensitive information was visible to everyone.

What you can document

• An overview of which digital product passport data are publicly accessible and which are restricted, aligned with which data in the steel digital product passport must be included.
• An internal decision on which data are marked as business-sensitive, with justification for why, so that this can later be traced.
• Agreements with the hosting provider on which access roles are supported (end user, supply chain partner, regulatory authority) and how these are technically separated.
• A record of who within the company is responsible for granting and managing access rights to the digital product passport.
• An overview of which parties in the supply chain (supplier, buyer, recycler) need which data, linked to subjects such as the scrap content in the melt or the alloying elements that must be reported, so that it is clear which data are relevant for which role.
• A log of modifications and access requests, so that during an inspection it can be demonstrated that regulatory authorities always had access to the complete data set.