how do I ensure that the data in the product passport is secure

What you must concretely do

What is expected of you

The ESPR sets requirements for the product passport that concern not only which data it contains, but also how that data is managed and protected. Article 10 and Article 11 of the ESPR (Regulation (EU) 2024/1781) together form the basis for this: Article 10 describes the requirements the passport must meet, Article 11 specifically addresses technical design and functioning. For a steel trader or metal processor organizing this for the first time, this breaks down into a number of practical considerations.

Controlling access to data according to role

Not everyone consulting the passport needs to see the same data. A purchaser at a construction company needs different information than a supervisory authority or a recycler at end of life. Article 10 of the ESPR is based on differentiated access: some data is public, other data is visible only to certain parties such as market actors or authorities. For a company with 10 to 100 employees, this means that before the passport goes live, a decision must be made about who sees which data layer — and that decision must actually be implemented technically, not only on paper.

Securing the origin and accuracy of data

A product passport is only valuable if the data in it is correct and traceable to its source. This relates to the reliability of the entire system: if a recipient cannot verify where a data point comes from, the passport loses its function. In practice, this means it must be documented who supplied which data — the manufacturer, the importer, or an intermediary — and when this occurred. For companies that do not enter data themselves but pass it on, it is important to know how the data was supplied in the correct format, because incorrect submission is reflected further down the chain in an unreliable passport.

Protection against modification after publication

Article 11 of the ESPR stipulates that the digital product passport must function technically in such a way that data cannot be altered undetectably after it has been recorded. For a metal processor who does not host the passport themselves but has it hosted elsewhere — such as via a platform like this one — this means that the choice of a hosting partner is also a choice about how that partner registers, logs and secures changes. This is not a theoretical point: if a customer or supervisor disputes a piece of data in the passport, it must be demonstrable when that data was recorded and by whom.

Integration with existing business systems

Many companies do not want to manage the product passport as an isolated system, but to connect it with the administration they already have in place. This is possible, but the security of the passport then cannot be separated from the security of that underlying system. Anyone considering connecting the passport to their own ERP or inventory systemis well advised to look at who has access to that connection and whether a breach in one system has consequences for the other.

Where things go wrong in practice

A number of situations recur regularly in practice.

At companies that have the QR code applied to the product itself, it is sometimes overlooked that the code in itself provides no security — the question is what happens behind that code. Those asking themselves how the QR code ends up on the steelmust also ask themselves who manages the underlying data and whether that separation between carrier and content is clearly documented.

Another situation arises when multiple parties in the chain supply data for the same passport without prior agreement on who may modify which part. This leads to confusion about which version is valid, and sometimes to the inadvertent overwriting of correct data by another party.

Even with small components things sometimes go wrong: if a QR code on a small piece of steel is technically limited, sometimes a simplified link or an intermediate page is chosen — without always having given thought to whether that intermediate step follows the same security agreements as the main passport.

A fourth situation: companies that maintain their own offline copy of passport data for use in locations without a connection forget to synchronize or secure that copy in the same way as the online version. This is a real issue, because not every workplace has a stable connection, and the question of whether the passport also needs to work offline is particularly relevant for this kind of practical implementation.

Finally: companies that cease operations or divest a business unit sometimes forget that the passport data continues to exist and that access to and management of it must be transferred — something that relates to the question what happens to the passport when the company stops operating.

What you can document

A number of agreements and documents help to make the security of passport data demonstrable:

• An overview of who has which role in the supply and management of data, including a contact person per party in the chain.
• A record of the source of each piece of data: which manufacturer, importer or intermediary it comes from and at what point it was supplied.
• Agreements with the hosting partner on logging of changes, so that it is demonstrable when a piece of data was recorded and whether it was modified afterwards.
• A description of the access levels that have been set: which data are public and which are only visible to specific parties.
• If applicable, an overview of the connection to your own ERP or inventory system, including who has access to that connection.
• A plan for the situation in which the company ceases operations or a division is transferred, so that management of and access to existing passports does not fall through the cracks.

This documentation is not only useful for regulatory oversight, but also practical: it prevents internal knowledge about who manages what from being lost through staff changes or business acquisition.