Digital Product Passport Architecture: The EU ESPR Data Model (2026)
A manufacturer shipping a jacket, a battery, or a refrigerator into the European Union will soon need to attach something the product never carried before: a structured, machine-readable record of what it is made of, where its parts came from, how to repair it, and how to recycle it. That record is the Digital Product Passport. Designing a sound digital product passport architecture is now a systems-engineering problem, not a compliance afterthought — because the same identifier that prints on a QR code has to resolve, a decade later, to data that may live in a PLM system that has since been replaced twice.
This is where most teams underestimate the work. The passport is not a PDF. It is a distributed data product spanning your PLM, ERP, supplier feeds, and a public registry, governed by access rules and expected to survive longer than the software that created it.
What this covers: the layered DPP reference architecture, the data model and identifiers, the registry and resolution path, PLM and supply-chain integration, role-based access control, and the failure modes that bite in production.
Context and Background
The Digital Product Passport originates in the EU’s Ecodesign for Sustainable Products Regulation (ESPR), which entered into force in 2024 and replaces the older Ecodesign Directive that covered only energy-related products. ESPR is a framework regulation: it establishes the legal basis for the DPP but delegates the concrete requirements — which product groups, which data fields, which timelines — to subsequent delegated acts adopted category by category. Textiles, batteries, electronics, iron and steel, and several other groups are named among the early priorities, with requirements phased in over the second half of the decade. The exact mandatory dates differ per category and are still being fixed in the delegated acts, so treat any single hard date with caution.
The battery passport is the first mover. Under the EU Batteries Regulation, industrial and electric-vehicle batteries above a capacity threshold must carry a passport ahead of the broader ESPR rollout, which makes battery data the de facto reference implementation everyone else studies. We unpack that lineage in our deep dive on the battery passport and EU regulation, and the patterns there generalize directly to the wider DPP.
On the technical side, the CIRPASS project, an EU-funded coordination effort, has done much of the groundwork on a cross-sector DPP system definition — vocabulary, data carrier guidance, and the decentralized registry concept. The standardization work that ESPR will lean on is being developed through CEN-CENELEC. The practical upshot for an architect: you are building against a moving target where the data model and the resolution mechanism are stabilizing faster than the per-category content requirements. That asymmetry shapes every design choice below.
The strategic reading is that the plumbing is settling while the payload is still in flux. Identifiers, data carriers, and the resolution model are converging on GS1 and a decentralized registry; the exact required fields per category are not. A sound architecture therefore commits firmly to the stable parts — adopt GS1 Digital Link, build a thin registry integration, design field-level access — and stays deliberately loose about the parts still moving, by treating the field catalogue and event vocabulary as versioned configuration. Teams that hard-code a single category’s fields into their schema will rework that schema with every new delegated act; teams that build a category-agnostic core absorb each new product group as data. This is the central design tension and the thread running through the rest of this reference architecture.
The Digital Product Passport Reference Architecture
Figure 1: The layered digital product passport architecture, from physical data carrier up through identifiers, the registry, the data model, and the source systems that feed it.
The figure shows six layers stacked from the physical product to the systems of record. At the bottom, a DPP data carrier (QR, NFC, or RFID) is physically applied to the product or its packaging. It encodes a unique identifier expressed as a GS1 Digital Link URI. A resolution layer — the product passport registry — maps that identifier to the responsible economic operator’s backend. The data model layer defines the passport’s content. Source systems (PLM, ERP, MES) supply that content. An access-control layer sits across the data so that public, restricted, and private fields reach the right audiences. This separation of carrier, identifier, resolution, data, and access is the spine of any workable design.
A Digital Product Passport is a structured, machine-readable record — reachable from a data carrier on the physical product — that holds a product’s identity, composition, sustainability, repair, and end-of-life data, with fields exposed selectively to consumers, economic operators, and authorities according to defined access rules.
The DPP data model: identity, attributes, and lifecycle events
The data model has three logical tiers of identity, and conflating them is the most common early mistake. Product-level identity describes a model or type — a refrigerator SKU, a jacket design. Batch-level identity describes a production lot sharing a bill of materials and supplier set. Item-level identity describes a single serialized unit. ESPR contemplates passports at the model, batch, or item level depending on the product group; batteries trend toward item-level, while many textiles may sit at model or batch level. Your architecture must support all three because a single manufacturer will span categories.
Around identity sits the attribute set: material composition, substances of concern, recycled content, carbon and environmental footprint, durability and reparability indicators, spare-parts availability, and dismantling or recycling instructions. These are largely static per model or batch — they describe the product as designed and built.
The third element is lifecycle events: a time-ordered log of things that happened to the item after it left the line — repairs, ownership transfers, refurbishment, recycling. Events are append-only and item-scoped. Modeling attributes and events with the same flat schema is a trap; attributes are mostly snapshots, events are a growing ledger, and they have different retention, write-frequency, and access profiles.
The practical consequence is two storage strategies behind one API. Attributes are read-heavy and rarely change, so they cache well at the edge and tolerate aggressive TTLs measured in hours or days. Events are write-occasionally, read-occasionally, and must never lose history, so they want an append-only store with strong durability rather than a cache. A useful mental model is to treat the attribute record like a versioned document — each design or BOM revision produces a new immutable version, and the passport pins to the version that was current when the item was built — while events accrete as an ordered stream keyed by the item identifier. When a regulator asks “what was the recycled-content claim for the unit built in March,” you resolve the item to its build-time attribute version, not to today’s design. Without that versioning, a routine engineering change quietly rewrites the history of every unit already in the field, which is both wrong and, for a regulated claim, a liability.
Schema-wise, expect each category’s delegated act to define a controlled list of required and optional fields with units and allowed value ranges. Your internal model should hold a superset and project the per-category required subset at publication time, so adding a new product group is a configuration change, not a schema migration. Treating the field catalogue as data rather than as code is the single highest-leverage decision in the data model.
Unique identifiers and data carriers: Digital Link, QR, NFC, RFID
The identifier is the keystone. The emerging consensus, reflected in CIRPASS guidance, is to express the unique identifier as a GS1 Digital Link URI. Digital Link turns a plain GTIN or serialized identifier into a resolvable web URL, so a single QR code does double duty: a consumer’s phone opens a human-readable page, while a machine follows the same URI to structured data via content negotiation. That dual role is exactly what a passport needs.
Mechanically, Digital Link works through HTTP content negotiation. The carrier encodes a URI on a resolver domain — conceptually https://id.example.com/01/<GTIN>/21/<serial>, where 01 is the GS1 Application Identifier for a GTIN and 21 is the AI for a serial number. A browser sending Accept: text/html is redirected to the consumer page; a machine sending Accept: application/ld+json is routed to structured data. One physical code, two audiences, resolved by a header. That is why Digital Link, rather than a bare opaque URL, is the recommended identifier: it preserves the structured GS1 keys inside a web-resolvable address, so existing supply-chain systems that already understand GTINs and serials are not blinded by the move to a passport.
The data carrier choice is an engineering trade-off, not a default. A printed DPP data carrier as a QR code is cheap — effectively the cost of ink — needs no power, and is universally scannable, but it is forgeable and offers no on-product storage. A QR code’s data capacity is bounded (a few kilobytes at most in the densest configurations), which is fine because it carries only the identifier, not the passport. NFC tags support tap interactions and can carry a small authenticated payload, useful for anti-counterfeiting, at a unit cost typically in the cents-to-low-tens-of-cents range depending on volume. RFID enables bulk, line-of-sight-free reads — valuable in logistics and at recycling facilities where items are processed in volume — but readers are not in consumers’ pockets. Many designs combine a public QR for consumers with an RFID or NFC tag for industrial reads. The identifier underneath stays the same across carriers; only the encoding and read modality change. Print the QR at a size and error-correction level that survives a decade of handling — error-correction level Q or H trades data density for the redundancy that lets a scuffed or partially abraded code still decode, which matters when the same physical item must be readable at recycling years after manufacture.
The DPP registry and decentralized resolution
The registry is the part architects most often get wrong by assuming it stores the passport. It does not. In the CIRPASS-aligned model, the registry is a thin, decentralized resolution and discovery service: it maps a unique identifier to the responsible economic operator and to the endpoint that serves the actual passport data. The data itself stays in the operator’s backend. This keeps a single regulator-run database from becoming a centralized chokepoint holding every manufacturer’s proprietary bill of materials.
Resolution therefore looks like DNS more than like a data warehouse. A scanner reads the Digital Link URI, the registry (or a Digital Link resolver) routes the request to the operator’s DPP service, and that service returns the appropriate view. The registry also anchors trust — it records who the legitimate data steward is, so a counterfeit carrier pointing at a rogue endpoint can be detected. Designing for this decentralization early is what lets the system scale to billions of items without a monolith in the middle.
It helps to separate three concerns the word “registry” tends to blur. First is discovery: given an identifier, who is the responsible economic operator and where is their endpoint. This is the thin mapping that ESPR-aligned designs centralize, because it must be authoritative and small. Second is resolution: the act of redirecting a scan to that endpoint, which a Digital Link resolver performs and which can be federated or cached close to the user. Third is the data service itself, run by the operator, which holds the passport. Keeping these separate means the regulator-facing registry stores only pointers and steward identity — kilobytes per product, not megabytes — while the heavy, proprietary, frequently-changing data never leaves the operator. The scaling math is the argument: a few billion items each needing only an identifier-to-operator pointer is a modest index, whereas centralizing every bill of materials would be a petabyte-class liability and a privacy hazard nobody wants to run.
There is also a continuity reason to keep the registry thin. Operators change CMS vendors, migrate clouds, and occasionally go bankrupt. If the registry holds only the pointer and the steward record, redirecting an identifier to a successor or an escrow endpoint is a single mapping update; if the registry held the data, every migration would be a bulk transfer with its own failure modes. Decentralization here is not ideology — it is the cheapest path to a system that must outlive the companies inside it.
Integration, Access Control, and Lifecycle
Figure 2: Identifier resolution — from scanning the data carrier to serving a role-based view, including the offline fallback to a cached snapshot when the operator backend is unreachable.
Figure 2 traces the read path. A scan yields a GS1 Digital Link URI; the registry resolves it to the operator’s DPP service; that service either returns live data or, if the backend is down, a cached snapshot; and the response is rendered as a role-appropriate view. The offline branch matters because passports must remain readable for years even if a backend has an outage — a hard availability requirement most teams discover too late.
Feeding the passport: PLM, ERP, and the digital thread
The passport is only as good as the systems behind it. Design-time data — materials, substances, reparability, dismantling steps — originates in PLM. Production-time data — batch, supplier lot, manufacturing site, date — originates in ERP and MES. The DPP service is an aggregation and publication layer on top, not a new master of record.
Figure 3: The publication sequence — PLM and ERP push design and batch data into the DPP service, which registers the identifier, then resolves and serves a filtered passport view on demand.
This is exactly where a strong digital thread pays off. If your PLM already maintains a clean, versioned bill of materials and links it to as-built records, populating the passport is a mapping exercise. If it does not, you are reconciling spreadsheets under regulatory deadline. The discipline of pushing field data back into engineering — what we call closed-loop PLM — is the same muscle that keeps a passport’s lifecycle events accurate over time. For multi-plant manufacturers, a unified namespace architecture gives the DPP service one consistent place to subscribe to production events rather than bespoke point-to-point integrations per site.
The integration topology matters more than the connector technology. The naive approach wires each plant’s MES and ERP directly to the DPP service, which gives you N times M point-to-point links that all break independently when any schema shifts. The better pattern is event-driven: production systems publish well-defined events — unit built, batch closed, supplier lot consumed — onto a shared backbone, and the DPP service subscribes. That decouples the passport’s publication cadence from the engineering systems’ release cycles, and it means a new product line or a new plant joins by emitting the same events rather than by commissioning a new integration. A worked example: a unit’s passport needs four facts at build time — the model’s current attribute version from PLM, the production batch and site from MES, the supplier lot genealogy from ERP, and the serialized identifier minted at the line. If those arrive as four events keyed by the same item ID, the DPP service assembles the passport deterministically; if they arrive as four nightly file drops in different formats, you have a reconciliation project and a class of silent mismatches.
Treat the mapping itself as code under version control. The transformation from internal field names and units to the category’s required schema is logic that will change as delegated acts evolve, and you want it tested, reviewable, and auditable — not buried in an ETL job nobody owns. A failed or partial mapping should surface as a publication error that blocks the passport from going live with missing required fields, because an incomplete passport is a compliance gap, not a cosmetic one.
Role-based access: public, restricted, and private fields
Not every field is for everyone. ESPR is explicit that some passport data is public while other data is restricted to specific actors — authorities, repairers, recyclers — for legitimate reasons including commercial confidentiality. Your DPP service must enforce field-level access tiers, not document-level ones, because a single passport contains a mix.
| Access tier | Typical audience | Example fields | Auth requirement |
|---|---|---|---|
| Public | Consumers, general web | Model identity, care and use, recycled-content claim, recycling guidance | None — open resolution |
| Restricted | Authorities, repairers, recyclers | Detailed bill of materials, substances of concern, dismantling sequence, spare-part references | Verified role credential |
| Private | OEM and named partners | Supplier identity, cost-sensitive composition, internal lot genealogy | Operator-issued token |
The control point is the DPP service, which inspects the requester’s credential and returns only the permitted projection of the record. Access events themselves should be logged — both for audit and because regulators may want evidence that restricted data went only to entitled parties.
Figure 4: Field-level access-control decision flow. An incoming data request is authenticated, its role credential validated against a trusted issuer, and only the permitted projection of passport fields is serialized in the response.
The flow above runs on every read. An unauthenticated caller receives the public projection; an authenticated caller with a verified authority or recycler credential receives the restricted projection; and only an operator-issued token unlocks private fields. Enforcing this server-side — choosing which fields to serialize rather than filtering in the client — is the single most important control in the whole passport surface.
The credential mechanism deserves precision because field-level enforcement is easy to get subtly wrong. The robust pattern is a verifiable role credential — for example, an authority or accredited recycler presents a signed token (an OAuth2 access token or a verifiable credential) whose claims the DPP service validates against a trusted issuer before widening the projection. Crucially, enforce on the server by selecting which fields to serialize, never by returning the full record and hiding fields in the client. The latter is the recurring real-world breach: the restricted bill of materials ships in the JSON payload and the “private” flag only dims it in the UI, so anyone reading the raw response sees everything. The projection must happen before serialization, and the same request returning different field sets to different roles must be exercised by tests. Because Figure 4’s decision runs on every request, it should be cheap — a claims check and a field-allowlist lookup, not a per-field database round trip.
Events over the lifecycle and exchange protocols
Over a product’s life, events flow inward to the passport: a repair shop appends a repair event, a recycler appends an end-of-life event. The exchange surface is typically a web API — RESTful HTTP with content neg
