The EU Digital Product Passport is not a QR label that magically makes a supply chain transparent. It is a governed information system linking a physical product to structured, role-appropriate data that must remain accurate and usable through years of manufacture, sale, repair, resale and recycling. The hard engineering work is identity, source-of-truth boundaries, interoperability, evidence and continuity.
The framework is moving from policy into implementation. The EU Digital Product Passport Registry became operational on 20 July 2026. It registers unique product identifiers and required metadata, while detailed product data is stored in a decentralised manner by economic operators or service providers. The first mandatory deadline highlighted by the Commission is 18 February 2027 for certain battery types, including EV, light means of transport and industrial batteries. Other product groups follow their own legislation and delegated acts; a blanket “every product needs a passport now” statement would be wrong.
Under the Ecodesign for Sustainable Products Regulation (ESPR), product-specific acts determine the data, carrier, identifier level, access and responsibilities. The registry is infrastructure, not a central warehouse for every product record. That distinction should drive the software design.
Conceptual data graph; the exact fields and access rules depend on the applicable product legislation.
One product can connect to components, batches, facilities, suppliers, declarations, repair events and end-of-life records. Avoid turning this into a single mutable JSON blob with no provenance. Model entities and relationships explicitly, version each claim, record its source and validity period, and preserve the difference between a manufacturer statement, a supplier attestation, a measured result and a third-party certification.
The Commission describes the Registry as storing unique identifiers and mandatory registration data, while operators or DPP service providers keep the detailed information. Registration can use a secure interface or API. Architect accordingly: a registry adapter handles identifier registration, verification and required metadata; a separate passport service resolves the identifier to data; domain services remain the source of truth for product facts.
That split limits centralisation and lets operators evolve internal systems, but it creates availability obligations. A QR scan should not depend on a fragile chain of redirects or a single company database that disappears when a supplier closes. Use durable identifier resolution, documented APIs, explicit ownership, monitored dependencies, exportable data and the backup arrangements required by the applicable rules. Test recovery from a service-provider outage and migration to a replacement host.
Do not make “last write wins” the data governance model. If two suppliers report different recycled-material values, preserve both submissions, record which data owner resolved the discrepancy and track the basis for the published value. Validate units and code lists at ingestion. A schema-valid record can still be semantically impossible: negative mass, future manufacture date or a component incompatible with the declared model should be rejected or quarantined.
The EU’s implementation work includes standards for unique identifiers, carriers, interoperability, APIs, data exchange and storage. In practice, a common endpoint is not enough. Participants need stable identifiers, shared vocabularies, versioned schemas, explicit units, language handling, access semantics, error models and migration rules. Map supplier formats to a canonical internal model, but retain the original evidence and transformation version so a downstream auditor can reconstruct how a published field was derived.
Avoid proprietary identifier resolution that makes the QR code useless after a vendor change. Keep the physical carrier bound to a persistent identifier, support the required resolution behavior, and make service-provider replacement a rehearsed operation. Standards reduce bespoke integration but do not remove data-quality or governance work.
Consumers, repairers, recyclers, market surveillance authorities and supply-chain partners do not need identical views. Implement authorization at the data attribute or dataset level, using actor role, purpose, product state and applicable legal requirements. Separate public data from commercially sensitive supplier detail and security-sensitive manufacturing records. The ESPR also restricts storing customer personal data in a passport without explicit consent under the GDPR; avoid using the passport as a customer profile or tracking channel.
Prefer scoped credentials for business APIs, robust authentication for operators, rate limits and audit records for sensitive queries. A QR code is an identifier, not an access token: do not encode secrets or personal identifiers into a scannable URL. Add abuse monitoring without turning access logs into an unnecessary personal-data store.
Products can outlive their manufacturer’s original IT stack. Define who maintains the passport endpoint, who controls the identifier, what happens in insolvency, and how the data and evidence move to a replacement service. Create correction workflows that update inaccurate fields without erasing the audit trail. Keep the current view clear while retaining event history under a documented retention schedule.
Build a continuity drill around a real lifecycle: supplier ceases trading, a product batch is recalled, a data carrier is damaged, the hosting operator is unavailable, or a repairer reports a corrected component. Measure resolution time, percentage of affected identifiers found, stale records, API availability and successful export/re-import. Long-term persistence should be tested, not inferred from a database backup checkbox.
| Risk | Design control | Operational evidence | Common mistake |
|---|---|---|---|
| Counterfeit or duplicated product identity | Globally unique identifier, controlled issuance and duplicate detection. | Issuer records, registration response and collision alerts. | Assume a QR image is inherently authentic. |
| Supplier submits false or stale data | Source attribution, evidence type, validation rules and review for high-impact fields. | Signed submissions, source version and correction history. | Conflate syntactic validation with factual verification. |
| Passport endpoint becomes unavailable | Durable resolution, service continuity, export and tested migration. | Recovery drill, uptime, backup restoration and endpoint transfer test. | Bind the product forever to a vendor-specific URL. |
| Unauthorised access to restricted attributes | Role- and purpose-based authorization with least privilege. | Access decisions, periodic review and abuse alerts. | Make every field public because the QR is visible. |
| Schema changes break old products | Versioned contracts, backward-compatible readers and governed migrations. | Compatibility tests against historical records. | Rewrite old passports in place without preserving meaning. |
I would build a product-data platform around five services: identifier registry adapter, canonical product graph, evidence and provenance store, policy-aware API gateway, and lifecycle event processor. Use immutable claim records with explicit corrections, a schema registry with semantic vocabularies, an event bus for approved lifecycle changes, and static or cached public views for high-volume consumer reads. Keep required registry interactions separate from internal supplier records and avoid coupling all participants to one database.
Start with a narrow product group and a few real partners. Onboard one component supplier, one manufacturer, a repair workflow and a recycler. Test identifier creation, access roles, corrections, outage, vendor migration and end-of-life queries. Expand only after the data contracts work across organisations, not just in a single developer sandbox.
A Digital Product Passport is a durable identity and data-governance system attached to a physical product. The QR code is the entry point; the difficult parts are trustworthy claims, clear ownership, interoperable schemas, role-based access, accurate lifecycle updates and years of service continuity. The EU Registry gives the system a shared indexing layer, while the product data remains decentralised. Build for that hybrid architecture and for product-specific obligations that arrive in stages.
Editorial note: Implementation dates and required data vary by product group and applicable legislation. The dates here reflect the European Commission’s indicative timeline checked on September 28, 2026; confirm the current delegated act before making a compliance decision.