Iron and steel DPP readiness is not a reason to buy software before the final rules exist. For producers, processors, service centres, traders and component makers in Thailand and ASEAN, the useful task now is to define who supplies which evidence, at what product identity and effective time, then test the contract with real transformation exceptions. The iron-and-steel delegated act and final data list have not been adopted. This guide separates adopted ESPR requirements, current Commission platform information and the 2026 JRC working proposal, then turns them into a source map, identifier/version rules, RFP clauses and acceptance tests.
What changed in 2026—and what is still open
The Commission’s current indicative DPP timeline places iron and steel in 2026 and indicates Q4 2026 for adoption of a sector delegated act, followed by at least an 18-month transition. These dates may change. Scope, final fields, carrier placement, access and model/batch/item granularity will be set by the product-specific act.
ESPR Regulation (EU) 2024/1781 is adopted. Articles 9–11 and Annex III establish a persistent unique product identifier and open, interoperable, machine-readable structures. They do not settle one universal steel granularity. The Commission’s steel page describes possible classes—identity/classification, technical/material, circularity/recycled content, sustainability and compliance/traceability documents. The March–April 2026 JRC/Product Bureau submission is a structured proposal for intermediate steel products, not binding law. For the cross-product overview, see our EU DPP manufacturing guide; this article begins with the steel data contract.
Map responsibility across the steel chain
The economic operator placing the product on the EU market carries the principal DPP responsibility. It may not operate the melt shop, rolling mill, service centre and export channel. A Thai supplier that does not register the DPP may still be contractually responsible for reliable source data.
| Role | Activity | Candidate contribution | Contract question |
|---|---|---|---|
| Steel producer | Melt, cast, roll, test | heat/cast, chemistry, process, test evidence | Final fields remain open |
| Processor/service centre | Cut, slit, treat, combine | input/output IDs, genealogy, inspection | Preserve parent-child links |
| Trader/importer | Contract, export, EU placement | product ID, supplier evidence, registration | Name the EU operator |
| Downstream customer | Convert and approve | receipt unit, use, requested evidence | Define access scope |
The contract should name the EU operator, DPP host, Registry registrant, source approver and correction notifier. “DPP-ready material” is not an accountable division of work.
Keep four layers separate
- Factory genealogy/events: MES, WMS and traceability records for receipt, production, split, merge, rework, test and shipment, including time, quantity, unit and parent/child IDs.
- Material/test certificates: mill certificates and LIMS/QMS values, with certificate number, revision, approval, correction status and covered product IDs.
- Sustainability/circularity evidence: candidate recycled-content and environmental values plus method, boundary, factor version, period and verification. Disclosure remains subject to final rules.
- External DPP/Registry interface: carrier/resolver, access control, API and identifiers, registration data and high-level metadata submitted to the Registry.

This separation prevents a correction from overwriting historical evidence and permits a DPP service change without relocating factory master data. For cross-company event exchange, connect this work with our chain traceability and EPCIS guide.
Provisional source matrix—candidates pending final rules
| Candidate | Owner | Source | Identity/granularity example | Version/effective time | Evidence |
|---|---|---|---|---|---|
| Product ID/grade | Quality/sales | ERP/spec master | product/batch/coil candidate | order/production master version | approval |
| Heat/cast | Steelmaking | MES/cast record | heat, cast, slab/billet | event/final time | production record |
| Chemistry | Laboratory | LIMS/certificate | sample/heat/batch | analysis/reanalysis | lab approval |
| Mechanical properties | Quality | LIMS/QMS | coil/plate/batch candidate | test/approval time | test report |
| Dimensions/mass | Production/logistics | MES/WMS/scale | coil/plate/bundle | measurement/correction | calibrated record |
| Split/merge | Processor | MES/WMS | parents/children | event time | operation record |
| Recycled-content candidate | Procurement/environment | supplier evidence/ledger | site/period/product candidate | method/period version | supplier verification |
| Environmental candidate | Environment | EMS/verification | site/route/product candidate | reporting/correction version | method/report |
| Compliance certificate | Quality/legal | DMS/QMS | certificate→product IDs | issue/correction | approval trail |
| Registration | EU operator | DPP service/Registry | persistent ID | registration/update | API response/log |
This is not the final legal field list. Its purpose is to establish an owner, authoritative source, identifier, effective time and approval evidence for each candidate. “It is in ERP” is insufficient without the table/document, version, correction owner and historical retention rule.
Design identities and versions for real steel transformations
Steel genealogy is not one-to-one. A heat may yield several slabs; one coil can become multiple slit coils or sheets; materials can be combined or reprocessed. Do not declare a universal hierarchy. Document the transformations used by your business—for example heat → slab → hot-rolled coil → slit coil → shipment batch, or billet → bar batch → bundle.
Each unit needs a persistent ID. A split event records parent, children, input/output quantity, unit, yield, time and process. A merge records every parent and the rule by which evidence is inherited. Fix kg/tonne and mm/m conversions, rounding, source unit and rule version. Never reuse IDs.
A correction must not erase a prior certificate. Retain old/new revision IDs, reason, approver, effective time and affected products. Show the current revision to users while retaining the version shown at an earlier audit or shipment.
Understand the DPP Registry boundary
The Commission describes the Registry as an index containing identifiers, registration data and high-level metadata. The complete detailed DPP dataset remains decentralised with the economic operator or service provider; it is not simply uploaded into one EU central database.
The test environment, UI and API can support preparation, but final steel registration content follows the delegated act. A proof should test temporary identifiers, submission, response, update/cancellation, retry and audit evidence through an adapter that can absorb API change. Preserve request, response, timestamp, actor, API version and failure reason. Separate public, customer and authority access and require proof of registration that can be reproduced for a third party.
Put evidence and change into the RFP
| Clause | Requirement |
|---|---|
| Scope/roles | Products, sites, EU operator, approver, host and registrant |
| Data contract | Candidate fields, types, units, quality and configurable final-rule change |
| Identity/granularity | Persistent IDs, granularity candidates, genealogy and no reuse |
| Provenance/version | Source, supplier, acquisition, approval, transaction/effective time |
| Correction | Late data, certificate revision, impact, notification and re-registration |
| Access/retention | Roles, revocation, evidence, event/API logs and history |
| API/export | Registry and ERP/MES/QMS/LIMS interfaces; portable CSV/JSON |
| Security | Authentication, authorization, encryption, keys, audit and incident response |
| Supplier onboarding | Templates, validation, rejection feedback, training and SLA |
| Exit | Complete data, evidence, ID map and logs; deletion proof and migration support |
Evaluate exception behaviour, not a perfect demonstration. Ask vendors to process split/merge, late supplier data, certificate correction and Registry failure. Require a priced statement of what is configurable and what requires development after the final rules.
A supplier data contract must cover evidence, not just values
Steel evidence arrives from raw-material suppliers, mills, processors, laboratories and logistics providers at different times and in different formats. A usable contract names the party asserting accuracy, delivery deadline, status when evidence is missing, correction notice, right to use supporting documents and duty to reproduce evidence during an audit.
If an environmental candidate value has not arrived at shipment, the system must not silently insert zero or reuse the previous value. Keep “not received,” “provisional” and “approved” distinct, and assign the person who decides whether publication is allowed. When the value arrives, retain receipt time, reporting period, supplier revision, approval and the DPP versions affected.
Conflicts between structured values and source PDFs need a defined precedence and discrepancy workflow. Automated validation can check range, unit, precision, grade compatibility, duplicate certificate numbers and existence of the covered product ID. Human approval should record the exception reason and affected products. Small suppliers without APIs can use controlled CSV or portal entry, provided actor, upload time, source document and validation result remain traceable.
Model correction, cancellation and late arrival as state transitions
A DPP is not a static page. Product data may be drafting, awaiting evidence, under validation, approved, registered, under correction, revoked/cancelled or archived. Define who can view and ship in each state and whether a Registry update is required.
A certificate correction should execute source correction, impact calculation, approval, new DPP revision, external notification and any required re-registration as one controlled case. If the API fails mid-process, keep internal approval separate from external publication and use idempotency so recovery does not create duplicate updates. Cancellation should preserve reason and time under retention/access rules rather than delete the audit trail.
Keep effective time separate from transaction time. If a result became effective on 1 September but entered the system on 3 September, both times are needed to reproduce what a customer saw on 2 September and still show the corrected current view.
Make security and portability acceptance criteria
External DPP access must not expose confidential recipes, process settings or customer identities simply because they share an MES source. Require least privilege, public/customer/authority roles, time-limited access, service-account controls, key rotation, audit logging, anomaly detection and an incident stop/recovery process.
Test expired tokens, authentication failure, role revocation, leaver accounts and supplier termination—not only the QR landing page. Verify that a former customer loses restricted access, authority access is logged, and an external service outage does not create an unsafe inbound path to the plant network.
At exit, require export of all product IDs, genealogy, revisions, evidence files, access configuration, Registry responses and audit logs in documented formats. A file dump is not portable if evidence links break or revision order cannot be rebuilt. Import a sample into another environment and reproduce current and historical views as an acceptance test.
Assess the delta when the final steel delegated act arrives
Project readiness is the ability to absorb change, not the number of provisional fields configured. Compare the final scope, granularity, mandatory data, carrier, access, Registry registration and retention with the provisional contract. Classify each delta as available from an existing source, supplier-contract change, master/genealogy change, new evidence, configuration, development or legal decision.
Then assess affected products, suppliers, historical backfill and tests to repeat, and update the plan backwards from the actual application date. If a JRC candidate is absent from the final act, decide whether it still has business value. If a new field appears, the shared pattern—authoritative source, owner, version, effective time and approval—should allow controlled change rather than an ungoverned column addition.
TOMAS TECH’s proposed 90-day readiness assessment
This is not an EU deadline or a guaranteed implementation duration. It is a planning frame for evidence-based decisions before final rules; scope and timing vary.
- Inventory: choose one EU-bound flow and map roles, sources, IDs, versions, gaps and manual steps.
- Provisional contract: define types, units, candidate granularity, genealogy, effective time, evidence, approval and access without freezing the JRC proposal as law.
- One-flow proof: connect a real heat or incoming material through processing, shipment, certificate and external DPP; use Registry test functions where available.
- Exception tests: exercise split, merge, correction, delay, unit conversion, access change, API outage and history reconstruction.
- Acceptance decision: assess data gaps, operational load, regulatory-change tolerance, supplier participation, security and portability, then decide whether to scale, correct data, revise the RFP or wait.

Acceptance tests before software purchase
| Test | Action | Pass outcome |
|---|---|---|
| Duplicate ID | Register same ID for another product | Reject/quarantine with reason |
| Split | Coil to multiple slit coils | Reproduce parents, quantities, evidence |
| Merge/mix | Multiple parents to output | Preserve all parents and allocation rule |
| Alternative material | Change to approved grade | Record approval/effective time |
| Certificate revision | Issue corrected certificate | Retain old; present current |
| Late supplier data | Receive required value after shipment | Controlled provisional state and republication |
| Unit conversion | Mix kg/tonne or mm/m | Repeatable rule and rounding |
| Offline/retry | Disconnect external service | Retry without duplicate |
| Historical correction | Correct prior value | Reproduce original and corrected views |
| Role change | Revoke customer role | Immediate effect and audit log |
| API failure | Simulate timeout/4xx/5xx | Queue, alert, retry and manual recovery |
| Evidence request | Simulate customs/authority request | Return authorized evidence and registration proof |
| Archive/export | Export all | Reconstruct IDs, versions and evidence links |

Business, quality, IT/OT, sustainability and the EU-side owner must accept together. Technical success is insufficient if no one approves corrections, suppliers miss evidence deadlines or usage rights are unclear.
Management decisions and staged next steps
- Identify EU-bound products and the EU market-placing operator.
- Budget for change because the steel delegated act is not adopted.
- Define your heat/cast, slab/billet, coil/plate and shipment genealogy.
- Assign owner, source, version, effective time, evidence and approval to each candidate.
- Contract supplier quality, correction, timing and evidence handover.
- Separate Registry indexing from decentralised details and require full export.
- Make exception tests contractual acceptance criteria.
- Name the owner of the final-rule gap assessment.
Start with one product-flow inventory and provisional data contract, not a platform purchase. Reproduce one DPP and use the exception results to shape the RFP and investment scope.
Divide the investment decision into three gates
Management does not need to approve an enterprise-wide DPP rollout in one decision. Gate one is data readiness, gate two is verification of one real product flow, and gate three is rollout investment. Naming the deliverables and stop conditions at each gate allows progress without treating the unadopted final steel rules as certain.
At the data-readiness gate, the EU-bound commercial flow and accountable parties must be agreed. For every candidate field, the authoritative source, owner, revision and effective time are listed. Each material gap is classified: obtain it through the supplier contract, create a new factory record, or defer the decision until the final rule. Passing does not mean that every field is complete; it means the gaps and acquisition responsibilities are visible and owned.
At the one-product verification gate, use a real heat or incoming material and reproduce processing, shipment, certificate, external presentation and Registry registration evidence. Run split, merge, correction, late arrival, access change and API-failure cases, not only the happy path. Trace each failure to data, operating process, supplier or product function, then estimate the cost of configuration, contract change, development or scope reduction.
At the rollout-investment gate, assess the operational volume created by adding products, sites and suppliers. Look beyond monthly registration count to evidence queues, correction rate, manual approval time, retries, queries, access requests and supplier training. Expansion conditions should include an exception-handling SLA, accountable-team capacity and the ability to reproduce sampled audit records.
| Gate | Management deliverable | Condition to proceed | Hold or return condition |
|---|---|---|---|
| Data readiness | Role map, provisional contract, source and gap register | Owners and acquisition paths agreed for critical data | EU responsibility or evidence usage rights unresolved |
| One-product verification | Genealogy, DPP view, registration proof, exception results | Material exceptions processed with complete history | Correction erases history, IDs are reused or export fails |
| Rollout investment | Scope, operating volume, cost and change plan | Staffing, SLA, migration and exit terms approved | No budget or architecture for final-rule deltas |
Regulatory monitoring belongs inside the programme. Assign who checks the Commission, EUR-Lex and JRC/Product Bureau, how often, where decisions occur and how changes enter the change register. When Q4 2026 or the 18-month transition is used for planning, label it “indicative,” record the retrieval date and do not treat it as a fixed production or contractual deadline.
Final applicability and legal interpretation belong to regulatory/legal specialists and the EU-side economic operator. IT/OT and quality teams provide reproducible evidence, version history and test results; they do not substitute a system configuration for a legal determination.
Stage expansion by data quality and operating accountability, not by product count. Stabilise approval for one site and one flow, add processors and suppliers next, and expand EU registration/access operations last. Converting every product while requirements remain provisional magnifies rework. A sound genealogy and evidence base can instead be reused when final fields are added or removed.
FAQ
Does iron and steel DPP readiness apply to Thai companies?
Location alone does not decide it. Assess whether the product is placed on the EU market, the chain role and the future steel delegated act. Even when an EU operator carries principal responsibility, a Thai supplier may contractually need to provide reliable material, process and certificate data.
Are the iron-and-steel DPP fields final?
No. ESPR is adopted, but the steel delegated act and final data list are not. Commission categories and the JRC proposal are preparation inputs, not a binding field list.
Is all detailed data uploaded through the DPP Registry API?
No. The Registry indexes identifiers, registration data and high-level metadata, while detailed data remains decentralised. Final steel registration requirements follow the sector rules.
Will steel DPP operate at model, batch or item level?
That granularity remains to be set. Prepare your transformation genealogy so heat/cast, slab/billet, coil/plate and shipment units can be mapped to whichever level is required.
How should an SME begin?
Select one representative EU-bound flow. Map roles, IDs, certificates, owners and correction steps using current ERP, spreadsheets and PDFs, then address gaps through a supplier data contract.
What should be tested before buying DPP software?
Test duplicate IDs, split/merge, certificate revision, late data, unit conversion, access change, API outage, non-destructive history and complete export. Also test how final-rule changes can be configured.
Conclusion: build evidence that can change with the final rules
Current iron and steel DPP readiness is about separating EU responsibility from supplier evidence, then connecting factory genealogy, material certificates, sustainability evidence and the external DPP/Registry layer. Persistent identities, effective-time versions, supplier clauses and exception tests create a defensible base without pretending provisional fields are law.
TOMAS TECH supports Thailand and ASEAN steel producers, processors, traders and component makers with discovery, source mapping, RFP design, DPP/Registry proofs and acceptance testing. We do not promise regulatory compliance, but we can help turn open questions into evidence for an investment decision. Contact TOMAS TECH.
Sources
- https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en
- https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/iron-steel_en
- https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/dpp-registry_en
- https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/economic-operators_en
- https://single-market-economy.ec.europa.eu/news/digital-product-passport-registry-now-live-2026-07-20_en
- https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781
- https://susproc.jrc.ec.europa.eu/product-bureau/sites/default/files/2026-03/Submission_ESPR%20Steel%20DPP%20Content%20Proposal_0.pdf
- https://susproc.jrc.ec.europa.eu/product-bureau/mt/product-groups/642/documents