Digital Product Passports and Machine-Readable Data

What is actually mandated, and when?

A Digital Product Passport is a structured, machine-readable data record attached to a physical product, reachable by scanning a data carrier and registered against a unique identifier in a central EU registry.

The framework comes from the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781. The regulation itself sets the architecture; the obligations arrive product group by product group through delegated acts. The Commission adopted its Ecodesign and Energy Labelling Working Plan 2025–2030 in April 2025, naming textiles, furniture, tyres, mattresses, iron and steel, and aluminium as first priorities, plus horizontal measures on repairability and recycled content for electrical and electronic equipment, with a mid-term review scheduled for 2028.

Two things happened in July 2026 that moved this from planning to plumbing. The Commission launched the Digital Product Passport Registry, together with a testing environment, on 20 July 2026. And Commission Implementing Regulation (EU) 2026/1778 of 16 July 2026 — which sets the practical arrangements for the registry, including access management, user verification, data registration and storage — was published in the Official Journal on 17 July 2026 and entered into force on 6 August 2026.

Here is the state of play as the Commission itself presents it. Note how much of it is indicative rather than fixed:

If you take one thing from that table, take this: there is no single DPP deadline, and the honest planning horizon for most product groups is "the delegated act has not been adopted yet".

What about construction products?

Construction runs on a parallel track. The recast Construction Products Regulation, (EU) 2024/3110, entered into force on 7 January 2025 and became generally applicable on 8 January 2026. Under its Chapter X the Commission is empowered to adopt delegated acts to create and govern a construction digital product passport system, aligned as far as possible with the ESPR passport. The Commission's indicative milestone for that act is Q2 2027.

The direction of travel is already visible in the regulation's own reasoning. Its recitals state that declarations of performance and conformity should allow the user, by means of an IT application, to check conformity, and that "an important prerequisite for machine-readable declarations is a standardised IT format". Economic operators must make copies available by electronic means, "unamendable, human and machine readable, available, accessible and unequivocally linked to the product".

In December 2025 the Commission published its first CPR Working Plan for 2026–2029 (COM(2025) 772 final), setting an indicative, product-family-specific roadmap for standardisation requests, revised harmonised technical specifications, and the horizontal delegated acts that introduce the DPP. For a building-product manufacturer, that document — not a vendor's marketing timeline — is the schedule to plan against.

Why does the registry matter if it does not hold your data?

Because it changes where the burden sits.

The registry stores unique identifiers for each product alongside mandatory registration data. It does not store the passport content. Economic operators register each passport so the identifier and its metadata are centrally recorded; the substance stays with you. Registration is restricted to verified economic operators, with identity established through eIDAS means.

That architecture is a directory, not a database. It means no central body is going to normalise your attributes, reconcile your units, or notice that your datasheet and your PIM disagree. Whatever you register resolves to whatever you serve. The compliance obligation is therefore, in substance, a data-quality obligation.

What data has to be machine-readable?

The ESPR text is precise about the mechanics even where the content per product group is still open. The passport should be linked to a unique product identifier and, where appropriate, to a unique operator identifier and a unique facility identifier. Identifiers and data carriers must be issued in accordance with internationally recognised standards. Digitalised information should be "easily accessible by scanning a data carrier, such as a watermark or a quick response (QR) code". And the data must be transferable through an open interoperable data exchange network without vendor lock-in.

Read that as an engineering brief and it decomposes into five capabilities:

1. 01Stable, unique identification at the right granularity — product model, batch or item, depending on the act.
2. 02Typed attributes with units and defined semantics, not free text in a specification field.
3. 03Documents as data — declarations, certificates and EPDs as records with issue dates and scope, not a folder of PDFs.
4. 04Provenance and versioning, so any value can be traced to a source and a date.
5. 05A resolver that returns the record when the carrier is scanned, and keeps returning it for as long as the act requires.

None of that is exotic. All of it is expensive to retrofit onto a catalog that has grown organically for twenty years.

How do ETIM, ECLASS, AAS and IEC 63365 fit together?

The regulation says the data must be machine-readable and interoperable. It does not tell you what "rated operational current" means. That is what the classification and modelling standards are for, and they are converging on these requirements faster than the legislation is arriving.

The mental model that keeps these straight: GS1 answers which thing is this, ETIM and ECLASS answer what do its properties mean, AAS answers how is the digital twin structured, IEC 63365 answers what goes on the nameplate, and the DPP legislation answers what you must publish and when. They are complementary layers, not competing options.

This is not only an EU story

Two reasons a manufacturer in Chicago, Nagoya or Seoul should read the above as their problem too.

First, the rules attach to market placement, not to head office. ESPR obligations apply to products placed on the EU market irrespective of where they were produced. A Japanese component maker shipping into Germany is inside the perimeter; a US distributor whose products reach EU customers through a partner is closer to it than it feels.

Second, comparable machine-readable expectations are appearing independently in every major market.

• Globally, GS1's Sunrise 2027 programme is a coordinated commitment by retailers worldwide to be able to scan 2D barcodes carrying GS1 data at the point of sale by the end of 2027, with GS1 Digital Link connecting the symbol to richer online data. That is the same idea as a DPP data carrier, arriving through commerce rather than regulation.
• In North America, the electrical industry has enforced structured product data for a decade: IDEA, jointly owned by NEMA and NAED, operates the Industry Data Warehouse and mandates a set of 43 fully populated critical data fields on items, alongside its UNSPSC-based classification specification and data dictionary. Public procurement adds another vector, with state-level Buy Clean rules in the United States requiring product-specific Type III Environmental Product Declarations for specified construction materials.
• In Japan, METI launched the Ouranos Ecosystem in April 2023 as a cross-industry interoperable data infrastructure, with battery traceability as its first use case; NTT DATA demonstrated interoperability between that platform and Europe's Catena-X in April 2025. Japanese suppliers are being pulled towards the same data model from a domestic direction.

The convergence is the point. Wherever you are headquartered, someone in your value chain is about to require structured, identified, provenanced product data from you.

The strategic argument: you are building this asset anyway

Here is the part that rarely makes it into compliance briefings.

Everything the DPP forces you to build — one canonical record per product, a stable unique identifier, typed attributes against a shared dictionary, documents modelled as data, provenance and versioning, and a resolver that serves it on demand — is precisely the substrate an AI agent needs in order to answer questions about your products correctly.

The two use cases differ only in access pattern. A DPP resolver answers one query about one item: someone scans a carrier, you return that product's record. An agent asks many queries across the range: every part meeting three constraints, the second source for an obsolete component, the declaration issued after a given date. Same records, different index.

Which means the choice in front of most product-data teams is not "compliance project or AI project". It is whether to fund the same data work once or twice. Organisations that run them as separate programmes typically end up with a compliance data set that is complete but unqueryable, and a commercial catalog that is queryable but unverified — and then spend a third budget reconciling them.

What should you do in the next twelve months?

1. 01Inventory your identifiers. Establish which products have a stable unique identifier, at which granularity, and who issues it. Nothing else works until this does.
2. 02Pick your dictionary and commit. ETIM if you are in electrical, HVAC or building products; ECLASS if you are broader or cross-sector. Partial adoption of both is the worst outcome.
3. 03Convert documents into records. Every declaration, certificate and EPD should have a type, a scope, an issue date, a validity period and a link — not just a filename.
4. 04Establish provenance and a last-verified date on every attribute. This is the field that will matter most when a regulator or an agent asks where a number came from.
5. 05Build the resolver once, and serve it to multiple consumers: the data carrier, your website, your feeds and your agent endpoints.
6. 06Track the delegated acts for your product groups rather than the general commentary, and revisit the plan each quarter.
7. 07Keep the output format pluggable. The content of your record is durable; the serialisation the delegated act eventually demands is not yet knowable.

Where to remain sceptical

Treat any claim of "DPP-ready" software with the question: ready against which delegated act? For most product groups the answer today is none, because the act has not been adopted. Treat claims that the registry will validate your data with the same scepticism — it records identifiers and metadata, not content. And treat 2027 as the beginning of the obligation curve, not the end of it.

The defensible position is unglamorous and durable: get the canonical record right, keep it verified, and make it addressable. Partsgraph exists to do exactly that job as an overlay on the catalog you already have, serving the same verified graph to compliance exports and to AI agents.

If you want a concrete starting point, run your domain through the free grader at /audit. It shows what a machine can currently read from your catalog — which is a reasonable proxy for how much work the passport will actually be.