EU Digital Product Passport Identifier and Data Carrier Design

The first design decision is the granularity of the unique product identifier. ESPR allows the passport data to refer to a product model, batch, or item as specified in the relevant delegated act. Do not serialize every unit by default unless the product rule, lifecycle risk, repair model, or traceability use case needs item-level identity.

A practical design record should name the identifier level, the standard or issuing route, the product data model fields that depend on it, and the downstream systems that must keep it stable. If the passport may be recreated after repair, remanufacturing, repurposing, or another lifecycle event, define how the new passport links to the original passport record.

ESPR requires the data carrier to be physically present on the product, packaging, or accompanying documentation as specified by the delegated act. Where possible, design for product-level placement so the passport remains available through use, repair, resale, and end of life. If product placement is not practical, document why packaging or documentation is the controlled alternative.

QR codes are usually the easiest public entry point because common smartphones can scan a URI. NFC can be useful where a tap interaction or protected tag is better than an exposed printed code. RFID can support logistics, repair, or industrial scanning where automatic identification at distance matters. The carrier choice should be validated against surface material, wear, weather exposure, replacement parts, packaging loss, privacy expectations, and whether basic public data can be reached without a vendor-specific app.

The data carrier should not be treated as a static web-page pointer. A resolver lets the same identifier route different users to the right passport view or machine-readable resource, based on link type, role, language, format, or access rights. For a customer scan, the default path should return public passport information in a mobile-accessible web format; for authorities, recyclers, repairers, or automated systems, the same identifier may need typed links to structured data, restricted views, or delegated supplier resources.

A resilient design keeps the product identifier stable while allowing service endpoints to change. That means maintaining DNS, redirect rules, link-type responses, backup hosting, and failure handling. If a responsible operator, service provider, or supplier endpoint disappears, users should not be stranded with an unreadable code or a 404.

The ESPR registry is separate from the public passport endpoint. The Commission registry stores at least unique identifiers, and for products released for free circulation it stores the commodity code. After upload, the registry communicates a unique registration identifier associated with the uploaded unique identifiers; ESPR states that this communication is not proof of compliance.

Customs checks depend on this registry path. Once the registry is operational, a person placing a covered product under release for free circulation must provide or make available the unique registration identifier, and customs may release the product only after verifying at minimum that the unique registration identifier and commodity code correspond to registry data.

Identifier design affects the data model. A model-level passport can expose shared performance, repairability, material, conformity, and circularity fields, but it cannot reliably carry item-specific events unless there is a linked record. An item-level passport can support lifecycle events, repair updates, ownership-independent maintenance, and recycling histories, but it increases data governance and resolver complexity.

Before issuing carriers at scale, define the minimum data model that the identifier must unlock: public fields, restricted fields, authority fields, update permissions, supplier references, evidence fields, and versioning behavior. The data must be based on open standards, interoperable, machine-readable where appropriate, structured, searchable, and transferable through an open interoperable data exchange network without vendor lock-in.

The evidence file should prove that the identifier and carrier design works in the real product environment, not just that a code was generated. Keep the design decision, source basis, standards choice, scan tests, resolver tests, registry mapping, access matrix, and supplier integration records together.

Avoid unsupported claims that a particular QR, NFC, RFID, DID, GS1, or proprietary implementation is legally required unless the applicable delegated act or source states that requirement. Where the product-specific rule has not fixed the standard, present the choice as an implementation option and document why it is interoperable, durable, and accessible.