The Standards Framework Is in Place — Now Comes Implementation
With the adoption of ESPR Regulation (EU) 2024/1781, the Digital Product Passport (DPP) has become binding EU law. What was long considered a future project reached a decisive new stage in spring 2026: the technical standards that implementing regulations will rely on are now available.
In early June 2026, the DPP4EU Conference in Brussels presented the standards package developed under CEN/CENELEC JTC 24. The EN 18216 to EN 18223 series defines the core technical infrastructure: data carriers, unique identifiers, APIs, and the interoperability framework. Open-source test environments were also introduced, enabling implementations to be checked for conformance. Fraunhofer IPK, which was involved in developing the standards, commented: "The standards are here — now is the time to bring them to life."
That statement captures the situation precisely. The regulatory architecture is in place; what is still missing are sector-specific implementing regulations, stable registry operations, and widespread implementation practice across industry.
What Standards EN 18216–18223 Actually Cover
Identifiers and Data Carriers
The standards series specifies that every DPP must have a unique product identifier that is machine-readable and permanently resolvable. EN 18220 governs the permitted data carriers — including QR codes, DataMatrix, and RAIN RFID. Crucially, the standard is technology-neutral: it does not mandate a specific carrier, but defines minimum requirements for readability and persistence.
GS1 Digital Link is not a requirement in this context, but is in practice the dominant candidate for identifier strategy — because it connects existing GTIN infrastructure with web URI resolution. The CIRPASS-2 consortium explicitly recommended in its comments on the draft that standard EN 18219 be referenced in the implementing regulation to ensure interoperability with GS1 Digital Link and other existing identification systems.
Registry Architecture: Decentralized with a Central Index
A common misconception concerns the planned EU DPP Registry. It will not store product data — only unique identifiers and resolver URLs, i.e., pointers to passport data hosted in a decentralized manner. Responsibility for data storage remains with the manufacturer or a designated service provider.
CIRPASS-2 raises three main criticisms of this model: the governance structure of the registry (who operates it, and under what conditions?), the question of data sovereignty in cross-border supply chains, and the still-unresolved interoperability with national systems. These criticisms are well-founded — as of the time of writing, the implementing regulation for the registry is still in draft form.
The JRC Steel Draft as a Blueprint for Other Sectors
Why Iron and Steel Are Setting the Direction
The Joint Research Centre of the European Commission has published a draft DPP for semi-finished iron and steel products. This draft is relevant beyond the steel industry for several reasons: it is the first to systematically formalize the distinction between product-level data and batch-level data — a distinction that is fundamental to database architecture and identifier strategy.
Product vs. Batch Level: A Structural Fork in the Road
The JRC draft explicitly assigns data points to one of two levels:
Batch level (lot number):
- Recycled content share
- Alloy composition
- Product-specific carbon footprint (PCF)
Product level (serial number):
- Dimensions
- Certifications
- Declarations of conformity
Under the draft, the product-specific carbon footprint is calculated using rules compatible with the ISO 14067 standard. This is significant because it defines a minimum methodological requirement — not just a data obligation.
The Battery Regulation (EU) 2023/1542 — currently the only binding sector act with its own DPP obligations — already implies this distinction. The steel sector draft, however, formalizes it explicitly for the first time, and is likely to serve as a template for all subsequent sector acts.
For companies planning their DPP database architecture today, this has immediate consequences: a flat data model that stores all attributes at the product level will not meet regulatory requirements. If you are already working with bulk import workflows, you should check whether your import structure distinguishes between lot-level and serial-number-level data.
Related Developments: REACH Microplastics and RFID Encoding
ECHA Guidance on Synthetic Polymer Particles
In parallel with DPP developments, the ECHA published guidance in May 2026 on REACH reporting obligations for synthetic polymer microparticles. The first reporting deadline for manufacturers and industrial downstream users of polymer pellets, flakes, and powders took effect in May 2026.
This is not a DPP topic in the strict sense, but it illustrates the broader regulatory direction: the EU is systematically building reporting obligations for material properties that will, in the medium term, feed into DPP data requirements. Companies that collect REACH data today are laying the groundwork for future DPP attributes.
RAIN RFID and GS1 Digital Link: Encoding Standards in Practice
On the implementation side, TEKLYNX has updated its CODESOFT software to support GS1 "++" encoding schemes (EPC++ and ISO BD). This allows web URLs to be written directly into RAIN RFID tag memory — a requirement that follows from the combination of EN 18220 and the GS1 Digital Link standard.
This is a concrete example of how abstract standards requirements make their way into production software. For companies running RFID-based supply chain processes, this means: your identifier strategy must start at tag encoding, not just at resolver setup.
What Companies Should Do Now
The regulatory landscape can be broken down into three areas for action:
1. Check standards conformance: Standards EN 18216–18223 have been published. If you are building DPP systems today, make sure the data carriers, identifiers, and APIs you choose are compatible with these standards. The open-source test environments introduced at the DPP4EU Conference provide a first means of verification.
2. Structure your data model by level: The JRC steel draft shows where things are heading. You should build your data model so that batch-level and product-level data are cleanly separated and independently addressable. This applies to both internal data storage and the API interfaces to your DPP system.
3. Monitor registry development: The implementing regulation for the central DPP Registry is not yet final. The criticisms raised by CIRPASS-2 — particularly regarding governance and data sovereignty — are substantively valid and could still influence the final draft. You should treat the registry not as a finished piece of infrastructure, but as a variable in your system architecture.
The standards are here. The first sector-specific drafts are on the table. What matters now is building implementation expertise — before the deadlines in the implementing regulations set the pace.
