can I already have a test version of my product passport made

What you must concretely do

What is expected of you

The literal question — can I already have a test version made — has no legal answer, because there is yet no obligation to comply with. The delegated act for iron and steel does not yet exist, and Article 18 of the ESPR (Regulation (EU) 2024/1781) is precisely the article that governs how the European Commission prioritises product categories and prepares the content of those acts. As long as that act is not published, there is no mandatory dataset, no mandatory format and no mandatory QR-carrier to test against. What there is: the articles that describe the general form of the digital product passport, and that form will not change substantially, even though the content per product category remains open.

Article 9: understanding what a passport must be able to do

Article 9 of the ESPR describes what a digital product passport means in general terms and must be able to do: link data to a specific product or product model, make it accessible via a data carrier, and keep it available for a certain period. For a company with 10 to 100 employees, this means above all that a test version can focus on the structure — which data is attached to which product, who is allowed to see it, how is the link made with a physical coil, sheet or profile — without the exact content yet being determined. That is precisely the kind of preparation you can do while the rules are still not final.

Article 10: understanding what requirements apply to the carrier and the data

Article 10 of the ESPR covers the technical requirements: interoperability, accessibility, and the way in which data must be accessible without the person viewing it being dependent on one supplier. For a test trajectory, this is the article that determines whether a pilot 'feels future-proof': a test version based on a closed, non-transferable carrier runs the risk of having to be rebuilt when the final act is published. A test version based on open, transferable data aligns better with what Article 10 intends, even though the exact standard is not yet set.

Article 38: understanding who in the chain supplies which data

Article 38 of the ESPR describes the requirements for actors in the supply chain: who must pass what information to whom, and in what form. For a steel trader or metal processor this is relevant because a test version of a passport without reliable source data from the manufacturer or importer is of little value. A pilot can certainly be tested on the basis of the data that currently comes in with procurement — certificates, material specifications, certificates of origin — to see whether that data flow is already suitable to land in a passport later on.

Where things go wrong in practice

A common first situation where things go wrong: a company has a test passport built around a template copied from another sector, such as textiles or electronics, without checking whether it aligns with what is relevant for steel. The result works technically, but must be largely rebuilt when the sector-specific delegated act is published.

A second situation: the test version is built on the basis of data that has long been outdated internally, such as an old supplier list or outdated certification status. The pilot then looks good, but says little about whether the company will actually be ready later, because the underlying data has not been cleaned up.

A third situation: companies test only the QR code and the display, but not the process behind it — who in the organisation keeps the data current, who is responsible if something goes wrong, and what happens if a customer asks for additional information. A test version that simulates only the "front" of the passport says little about the question how do I train my staff to work with the product passport, and that question will inevitably come back as soon as the passport becomes mandatory.

A fourth situation: a company with multiple locations has a test version built at one location and assumes that it can later be scaled up automatically. Whether that works depends on how centrally the data processing is organised; that is a question that deserves separate attention, see how do I arrange the product passport if I have multiple locations.

A fifth situation: the test trajectory is seen as an end point rather than practice. A demo is built, presented to management, and then that demo is left lying around until the rules are final — after which it turns out that the dataset has already become outdated.

What you can document

• An overview of which product data are available today per material type or product line, and which of these come from the manufacturer or importer as intended in article 38 of the ESPR.
• A description of the current data flow: where certificates and origin information come in, who manages them, and in which system they are stored.
• A note on which test version has been chosen (which platform, which standard) and why, so that when the final delegated act is published, it can be quickly assessed what can remain in place.
• A list of assumptions made in the test version about data field structure and accessibility, to be tested against article 9 and article 10 of the ESPR once the sector-specific delegated act appears.
• Agreements on who in the organisation manages the pilot and who is responsible for keeping the underlying data current.

For an overview of the steps that fit here, also separate from a concrete test version, the question is relevant how do I approach the steel product passport step by step. And for companies wondering whether such a test trajectory can already connect to a shared standard, it is relevant whether there is already a common line within the sector, see is there already an industry standard for the steel product passport.