Regulation
The Digital Product Passport for steel: what is decided, and what is not
Iron and steel is first in line for an ESPR delegated act, but none is adopted yet. What is settled, what is not, and what a processor should do meanwhile.
What the Digital Product Passport actually is
Start with the smaller claim, because the phrase invites bigger ones. A Digital Product Passport is a structured record about a product, reachable from a data carrier on or with that product, holding information that regulators, customers, recyclers and market surveillance authorities are entitled to see. Different parties see different subsets. It is a reporting obligation with an access-control model attached.
It arrives through the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, which has been in force since July 2024. ESPR replaced the old Ecodesign Directive and, more importantly, broke it out of energy-related products. Anything placed on the EU market is now in scope in principle, with the actual obligations set product group by product group through delegated acts.
That last sentence is the one that matters for steel. ESPR itself imposes almost nothing on a steel processor. The delegated act for iron and steel will.
Where the steel delegated act stands
Status as of September 2026. No delegated act covering iron and steel has been adopted. The preparatory work is running, and steel is widely expected to be among the first product groups to get one.
The sequence so far is short enough to state exactly. ESPR entered into force in July 2024. The first ESPR and Energy Labelling working plan was adopted in April 2025, covers 2025 to 2030, and carries a review in 2028. Iron and steel was named in it as a priority product group, alongside textiles, and the Joint Research Centre's preparatory study on iron and steel is under way.
What happens next is a draft delegated act, consultation, adoption, then entry into force. ESPR requires that a delegated act apply no earlier than 18 months after it enters into force, except where a shorter period is justified. Adoption during 2026 or 2027 therefore puts first application somewhere around 2028.
Treat any date more precise than that with suspicion. Preparatory studies slip, consultations extend, and the working plan itself is under review in 2028.
What the passport will probably have to contain
The specifics are not settled, but the direction is not mysterious either. The JRC work and the working plan point consistently at three families of data for steel:
- Embodied carbon. Carbon intensity per tonne, on a defined boundary. The preparatory study takes a cradle-to-gate view, which means the number follows the material from raw extraction to the factory gate.
- Recycled content. The recycled share of the product, which for steel means knowing the route and the charge, not estimating from a national average.
- Substances of concern. Presence and location of substances that affect reuse, recycling and safe handling.
Add the structural requirements that apply across product groups: a unique product identifier, a data carrier, and an access-rights model determining which party sees which field. The Commission is building a DPP registry and web portal to sit behind that.
Notice what every one of those data points has in common. Each is an attribute of a specific batch of material, and each has to be attached to that batch as it moves through your process. That is a traceability problem before it is a reporting problem.
Five things worth doing before the delegated act exists
- Get your incoming certificates machine-readable. Mill test certificates are where heat, grade, composition and mechanical properties enter your business. If they live as scans, everything downstream is manual.
- Establish batch-level identity. A passport describes a product, not a product line. If you cannot say which heat a given delivery came from, you cannot populate a passport for it.
- Ask your mills what they already publish. Several large producers report carbon intensity per tonne today. Where they do, capturing it costs you nothing beyond the pipeline to receive it.
- Write down the boundary you use. Cradle-to-gate carbon numbers are comparable only when the boundary is the same. Fix and document yours now rather than reconstructing it under deadline.
- Do not buy a passport platform yet. The fields are not final. What is final is that you will need the underlying data, in structured form, whatever the schema turns out to be.
The case for waiting, and the case against
There is a real argument for doing nothing until the rules are published, and it deserves to be stated properly rather than dismissed.
Preparing now
- The traceability work is needed regardless of the final schema
- The same data reduces certificate errors and customer complaints today
- Historical coverage cannot be created retroactively once the clock starts
- Customers with their own reporting obligations are already asking
- Spreading the work over two years costs less than compressing it into six months
Waiting for the delegated act
- The exact fields are genuinely not decided yet
- Tooling bought now may target a schema that changes
- Application is around 2028, which is a long time to carry a licence
- A 2028 review of the working plan could reorder priorities
- Nobody is enforcing anything today
Both columns are true. The resolution is that they are answers to different questions. Waiting is defensible for buying a passport platform. It is not defensible for capturing the data, because the data has value the moment it is structured, and no version of the regulation will ask for less of it.
My take
Most Digital Product Passport conversations I have sat in are backwards. They start with the passport, which is a format, and work towards the data, which is the actual problem. That order suits vendors selling a portal and suits nobody else.
Here is the uncomfortable version. If your mill test certificates are scanned PDFs in a shared folder, your constraint is not the delegated act. It is that you cannot answer a question about a specific delivery without a person opening files. A passport obligation does not create that problem, it exposes it, and it will expose it to a market surveillance authority rather than to a customer who might be forgiving.
So my advice to steel processors is unfashionably boring. Ignore the passport for another year. Spend that year making your certificate data structured, batch-level and queryable, which is work you can justify on error rates and audit time alone. When the delegated act lands, the passport becomes an export from a system you already run, and you will have spent nothing on a schema that moved.
The processors who will struggle in 2028 are not the ones who started late. They are the ones who bought a passport product in 2026 and still had the underlying data on paper.
If you want the mechanics of turning those certificates into structured data, the companion piece on why OCR alone fails on mill test certificates covers what breaks and why, and our page on EN 10204 certificate automation shows what the finished pipeline looks like. If you would rather just ask, book a discovery call and bring twenty of your own certificates.