in what format must I submit the data for the product passport
The file format has not yet been established
The ESPR does not prescribe a file format — no ".csv", no ".xml", no ".json". Article 11 of the ESPR (Regulation (EU) 2024/1781) does however stipulate that the digital product passport must operate according to open, interoperable technical standards, so that systems from different parties can read and process the data. Which standard exactly that will be follows from delegated acts that are drawn up per product group. For iron and steel, that act does not yet exist. Anyone who now asks "in what format must I submit", therefore rightly receives no concrete answer — that answer simply does not exist at this moment.
Who this applies to, and who it does not
This uncertainty applies to everyone who produces, imports or trades steel or iron semi-finished products and is preparing for the product passport: steel traders, metal processors, construction companies. It is not only an issue for steel — each product group falling under the ESPR receives its own delegated act with its own technical specifications. The format for batteries, textiles or furniture may therefore differ from what will apply to steel. It is also important to distinguish between the storage format and the exchange format: Article 11 concerns how systems must be able to read data from each other, not how a manufacturer organises its own administration. A company that currently maintains its data in an Excel file or in its ERP system does not need to change anything for this — the translation to the final format is something that happens when the passport is compiled, not with the company's own source data.
When this will be established
No date can be given for when the file format for steel will be known, because that date does not exist in the sources currently available. What is established is the route: the European Commission works out the technical requirements in a delegated act per product group, as Article 4 and Article 11 of the ESPR prescribe. As long as that act for iron and steel has not been published, there is also no format to adhere to. Until that time, nothing changes in the way companies currently maintain their product data — there is no preliminary format that should already be applied. As soon as the delegated act for steel is published, the specific technical details will be posted here.
What to do while the format is still being established
For anyone who wants to get ahead now, the most practical step is to put their own source data in order, regardless of the final file format. This starts with establishing which data are available per product — composition, origin, certificates — and how that data is stored internally. After that, it makes sense to look at how that data can later be linked to a system that compiles the passport; link to your own ERP or inventory system is a question that can be answered independently of the file format. The question of how each product or batch is identified also stands apart from the format and can be explored now — see how each product receives a unique identification codeOnce the delegated act for steel is in place, it will likely also clarify how the link with a standard such as GS1 Digital Link is precisely implemented; anyone wishing to build knowledge on this now can start with what GS1 Digital Link means for the product passportTherefore, the file format itself is the last step in a sequence — preparation for it begins with the data itself, not with the technical specification still to come.
The legal basis: articles 10 and 11 of the ESPR
Article 10 of the ESPR (Regulation (EU) 2024/1781) describes the general requirements that the digital product passport must meet, including accessibility and reliability of the data. Article 11 elaborates on this for the technical design and operation of the passport: it requires that the underlying technology must follow open standards, must be interoperable between market actors, and must be machine-readable. Neither of these articles specifies a particular file format, a particular encoding or a particular technical standard — that specification is expressly delegated to later acts per product group. This is also why this answer cannot now go further than stating the principle: the law establishes the requirement for interoperability, but not the technical standard by which that requirement is met.
What needs to be done now
At this time there is nothing to choose or install with regard to file format — that choice lies with the delegated act that has yet to be published. What does make sense is to put your own product data in order and to clarify the identification and linking issues mentioned above, so that the transition to the final format later becomes a matter of integration rather than a restart from scratch.
What this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 11 (technical design and operation of the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
The regulation itself can be found on EUR-Lex. We provide references for each statement; you do not have to take our word for it.
What you must concretely do
What is expected of you
Use open, standardised data formats
Article 10 of the ESPR (Regulation (EU) 2024/1781) stipulates that the data in a digital product passport must comply with open, interoperable standards. This means that a file format that can only be read by one specific software package does not align with the intent of the regulation. For a steel trader or metal processor with between 10 and 100 employees, this practically means that the data from their own ERP or inventory system is exported to a format that can be read by other parties — customers, supervisory authorities, recycling companies — without additional licence or special software. An export to a closed, proprietary file type does not fit this, even if that export format has been used internally for years.
Provide machine-readable data
Article 11 of the ESPR (Regulation (EU) 2024/1781) describes that the passport must be machine-readable and can be automatically read out via the carrier (usually a QR code). This effectively rules out a scanned PDF of a paper certificate as the sole data source: it is readable by humans, but not reliably processed automatically. For a company accustomed to sending material certificates as PDFs, this means a conversion to structured data is needed — think of fields with a fixed meaning (steel type, batch, composition) instead of free text in a document layout.
A structure that fits with the rest of the system
Both articles point towards a data structure that is not self-contained, but integrates with the broader infrastructure of the product passport: the unique identification number, the link with the register, and the way the passport remains accessible for years after the product is sold. For a mid-sized metal company, this means that the choice of file format cannot be viewed in isolation from how each product receives a unique identification code: see How do I give each product a unique identification code?. The format of the data and the identification of the product belong together; a standalone Excel file without consistent linking to a product code does not meet the idea of interoperability described in Article 10.
Where things go wrong in practice
A first situation that often comes up: a steel trader has been supplying material certificates (for example 3.1 certificates) as PDFs to customers for years, and assumes that this will also suffice for the product passport. The PDF contains the correct data, but not in a form that is automatically readable — which means it does not align with what Article 11 describes.
A second situation: a company uses an internal Excel file with custom column names and custom abbreviations for steel types. This works fine within the company itself, but as soon as a customer, supervisor or the registry needs to interpret that data, the shared meaning that a standardised format provides is missing.
A third situation arises when companies only convert to a structured format at the moment the product leaves the door. When that conversion happens manually, per sales order, the risk of errors and inconsistencies between product passports is considerable — especially with an assortment containing many variants in alloy, thickness or heat treatment.
A fourth situation: the file format is chosen correctly, but the link with the company's own inventory system is missing, causing data to be entered twice and to become out of sync with what the product passport states after an ERP system update. See also on this subject Can I link the product passport to my ERP or inventory system?.
A fifth, less visible situation: a company assumes that the file format is a one-off choice at first delivery, while the product passport must remain available for years. A format that is common now does not have to be so in years to come — a risk that is related to how long the product passport actually needs to exist, see How long must a product passport remain available?.
What you can document
- An overview of the current export formats from the company's own ERP or inventory system, with a note on which of these are machine-readable and which are not (for example PDF versus CSV or XML).
- A fixed list of fields per product group (steel type, batch, dimensions, composition) so that internal data is always structured in the same way, regardless of who enters the data.
- An agreement with suppliers or manufacturers on the format in which they supply their data, so that data does not need to be manually retyped from certificates or PDFs.
- A reference to the link with the unique identification code of each product, so that the file format and the identification together form one whole — see How do I give each product a unique identification code?.
- A note on readability without internet connection, to the extent that it is relevant to the company's own work processes on the shop floor or during transport, see must the product passport also work without internet connection.
- A file with the selected data formats per product line, including the date of change, so that when standards are later updated, it can be checked which older product passports are still in an outdated format.
The precise technical specifications of the file format to be used will be further detailed in delegated acts per product group; at present, Article 10 and Article 11 of the ESPR (Regulation (EU) 2024/1781) describe the framework within which those choices will be made. Once the delegated act for iron and steel has been published, it will be supplemented here with which format is concretely prescribed.
This is not legal advice. This page provides general information about the legislation that this platform deals with. 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 based on the sources above, verified by a human on 2026-09-05. Is anything incorrect? Let us know — corrections are given priority.