Digital Product Passport: What It Requires and the Data Behind It

The EU’s Digital Product Passport registry went live on 20 July 2026. The first mandatory passports arrive on 18 February 2027, covering electric vehicle, industrial and light means of transport batteries. Most coverage of the digital product passport stops at those dates. The harder problem sits underneath them: a passport is a structured data object, and most catalogues cannot currently populate one.

What a digital product passport actually is

A digital product passport is a structured, machine-readable record of a product, linked to the physical item through a data carrier such as a QR code, an RFID tag or an NFC chip. Scanning the carrier resolves to the passport, which holds information about the product’s composition, origin, repairability, environmental performance and end-of-life handling.

The European Commission describes it as a digital container for products, components and materials. The operative word is container. A passport does not generate information about a product. It carries information that someone has already collected, structured and verified.

That distinction decides how much work a DPP programme is. Buying a platform that serves passports is a procurement decision that takes weeks. Producing forty structured, unit-consistent, category-appropriate attributes for every SKU in a catalogue is a data programme that takes considerably longer.

The regulation behind it: ESPR and the timeline

The legal basis is the Ecodesign for Sustainable Products Regulation, (EU) 2024/1781, usually shortened to ESPR. ESPR is a framework regulation. On its own it imposes no passport obligation on any specific product. The obligations arrive through product-specific delegated acts, each covering one product group and setting its own information requirements and dates.

The ESPR First Working Plan, COM(2025) 187, was adopted on 16 April 2025 and names six priority product groups. Expected delegated act dates and the earliest resulting compliance windows:

• Iron and steel: delegated act expected 2026, earliest compliance around 2028.
• Textiles and apparel: delegated act expected 2027, earliest compliance around 2029.
• Tyres: delegated act expected 2027, earliest compliance around 2029.
• Aluminium: delegated act expected 2027, earliest compliance around 2029.
• Furniture: delegated act expected 2028, earliest compliance around 2030.
• Mattresses: delegated act expected 2029, earliest compliance around 2031.

The gap between those two columns is Article 4(4) of ESPR, which says requirements cannot apply earlier than 18 months after the delegated act enters into force. That 18 month floor is the planning window. It sounds generous until it is measured against the time needed to re-specify an attribute schema and collect the missing values from several hundred suppliers.

Batteries sit on a separate track. The battery passport is mandated by the Batteries Regulation, (EU) 2023/1542, not by an ESPR delegated act, and it is the first hard date in the calendar: 18 February 2027. A mid-term review of the working plan is scheduled for 2028, at which point the Commission may adjust timings or add product groups.

What data a digital product passport has to carry

The exact fields are set per product group by the relevant delegated act, so no complete list exists yet for groups whose act has not been adopted. The categories of information, however, are consistent across ESPR and the batteries regime:

• Product identity: unique identifiers at model, batch or item level, plus identifiers for the economic operator and the facility.
• Composition and materials: what the product is made of, including substances of concern.
• Origin and supply chain: where components and materials came from.
• Environmental performance: carbon footprint, recycled content, and similar measured values.
• Repairability and durability: spare part availability, repair documentation, expected lifetime.
• End of life: disassembly guidance and recycling routes.
• Compliance documentation: declarations, certificates and test reports.

Read that list as a product data specification rather than a policy summary. Every item on it is an attribute. Not a document filed against a product record, but a named field with a defined type, a unit where one applies, and a controlled list of permitted values. A carbon footprint that lives in a supplier PDF is not a passport field. The same number, extracted, converted to the required unit and stored against the SKU, is.

The standards that decide how a passport works

On 25 June 2026, CEN and CENELEC published the first six European standards for the digital product passport. They matter because they turn a policy concept into implementable requirements:

• EN 18216:2026: protocols and machine-readable formats for exchanging passport data securely and interoperably.
• EN 18219:2026: unique identifiers for products, operators and facilities, at different levels of granularity.
• EN 18220:2026: data carriers, covering the physical-to-digital link through optical codes, RFID and NFC, including encoding and durability.
• EN 18221:2026: storage, archiving, historical versions and long-term accessibility.
• EN 18222:2026: application programming interfaces for locating, retrieving and managing passport data across the product lifecycle.
• EN 18223:2026: semantic, technical and organisational rules so product information can be understood and reused.

Two further standards covering access rights and information system security (prEN 18239) and data authentication and integrity (prEN 18246) were still in formal review at the time of publication.

For a product data team, EN 18219 and EN 18223 are the two that bite hardest. The first makes product, operator and facility identifiers foundational rather than administrative. The second requires that an attribute means the same thing wherever it appears. Catalogues that carry the same SKU under three different internal references, or that use one attribute name for two different measurements across categories, fail both tests before any sustainability data is even considered.

Where the passport sits alongside systems already in place

A digital product passport is not a new system category so much as a new output from systems most organisations already run.

PIM

A PIM stores and governs product data. The passport is an output of it. This is also the clearest predictor of how hard a DPP programme will be: a PIM populated to 40% completeness will produce passports that are 40% complete, and the regulation does not accept partial records.

GS1 Digital Link

GS1 Digital Link turns a GTIN into a resolvable web address, which is increasingly how a data carrier resolves to a passport. Organisations already using GS1 identifiers have a shorter route to EN 18219 compliance than those relying only on internal part numbers.

Classification standards

ETIM, UNSPSC and eCl@ss give attributes shared meaning within a product category, which is precisely what EN 18223 asks for. Teams that have already mapped a catalogue to a classification standard have done a meaningful share of the semantic work. The guide to ETIM classification and data mapping covers how that mapping works in technical product categories.

ERP and PLM

Bills of materials, material declarations and supplier records usually sit here rather than in the PIM. Most passport programmes need a route from these systems into the product record, because composition data rarely lives with marketing content.

What a digital product passport is not

Four misconceptions cause most of the wasted effort on early programmes.

• It is not a QR code. The carrier is the smallest and cheapest part of the job. EN 18220 covers it in one standard out of six. The data behind the carrier is the work.
• It is not a sustainability report. Corporate sustainability reporting is annual, aggregated and written for humans. A passport is item-level, continuous and written for machines.
• It is not a one-off compliance project. A passport has to stay accurate for the life of the product, through supplier changes, reformulations and new production batches. A programme that ends at go-live produces records that are wrong within a year.
• It is not only a manufacturer problem. The obligation attaches to placing a product on the EU market. Importers and distributors who put their own name on a product, or who bring in goods from outside the EU, can carry the responsibility even though they made none of it. This catches distributors who assumed their suppliers would handle it.

The part most programmes underestimate: attribute-level readiness

A typical distributor catalogue carries a product name, a description, a price, a few images and perhaps a dozen structured attributes per category. A passport for the same product may need forty or more, each with a defined unit and a permitted value list, sourced from suppliers who currently send specification data as PDFs and spreadsheets in their own formats.

Three gaps show up repeatedly, and they are three different jobs:

• Attributes that do not exist yet. Recycled content percentage, substance declarations and disassembly instructions are rarely held today. This is a supplier data acquisition problem, and it is the slowest of the three because it depends on other organisations.
• Attributes that exist but are unstructured. The value is present in a specification sheet or buried in a description as free text. This is an extraction problem, and it is the most automatable of the three.
• Attributes that exist but are inconsistent. Weight recorded in kilograms for one supplier and grams for another, or a material described five different ways across the same category. This is a normalisation problem, and it is what EN 18223 will not tolerate.

Sequencing matters. Extraction and normalisation can start immediately against data already held, and both reduce the size of the acquisition problem by revealing which attributes are genuinely missing rather than merely unstructured. Starting with supplier requests, before knowing which fields are actually absent, produces a long questionnaire that suppliers ignore.

This is ordinary product data enrichment work, applied to a new set of required fields. The mechanics are unchanged: define the schema per category, extract what exists, normalise it to consistent units and values, and fill the gaps. What the regulation changes is that the output has a legal deadline and a defined recipient.

What to do before the delegated act lands

The delegated act for a given product group arrives with an 18 month minimum runway. Six things are worth doing before it does, because none of them depend on knowing the final field list.

1. Establish which product groups the catalogue sells into, and therefore which delegated act applies and when. Iron and steel is first; textiles, tyres and aluminium follow.
2. Define the attribute schema per category now. Most passport fields are predictable from the ESPR information requirements, and a schema built early can be extended when the act is published. Schema and attribute definition is the foundation everything else attaches to.
3. Audit what is actually held, measured as completeness per attribute per category rather than as an overall percentage. Catalogue-level completeness figures hide the categories that will fail.
4. Fix identifiers first. EN 18219 makes product, operator and facility identifiers foundational, and identifier problems block everything downstream.
5. Change supplier intake so new products arrive structured rather than being retrofitted later. Every product onboarded to the old standard adds to the backlog.
6. Decide where passports will be generated and served from, and confirm that the system holding the product record can export to the formats in EN 18216 and EN 18222.

For distributors specifically, the acquisition problem is larger than for manufacturers, because the data belongs to several hundred suppliers rather than to one production process. The distributor product data approach covers how intake at that supplier count is usually structured, and AI extraction from supplier documents is what makes the second of the three gaps tractable at catalogue scale.

Key takeaways

• A digital product passport is a structured, machine-readable product record reached through a data carrier. The carrier is the easy part; the structured data behind it is the work.
• ESPR, (EU) 2024/1781, is a framework. Obligations arrive through product-specific delegated acts, with iron and steel first and textiles, tyres and aluminium following.
• The first hard deadline is 18 February 2027 for batteries, under the separate Batteries Regulation (EU) 2023/1542.
• Article 4(4) of ESPR gives an 18 month minimum between a delegated act entering into force and its requirements applying.
• Six CEN and CENELEC standards published on 25 June 2026 define identifiers, carriers, exchange formats, storage, APIs and semantics. EN 18219 and EN 18223 matter most to product data teams.
• The obligation can attach to importers and distributors, not only manufacturers.
• Passport readiness is attribute readiness. Missing, unstructured and inconsistent attributes are three separate problems requiring three different fixes.

Where to go next

The practical first move is an attribute completeness audit per category, because it converts a regulatory deadline into a countable backlog. Once the gap is measured, the extraction and normalisation work can start against data already held, without waiting for the delegated act to confirm the final field list. The overview of product data enrichment covers how that work is structured, and standards and feeds covers the export side once the records are complete.