Search every question across sub-FAQs

No universal QR-code or NFC mandate is supported by the grounding sources. ESPR says the data carrier must be physically present on the product, packaging, or accompanying documentation as specified in the applicable delegated act. It also requires the data carrier and unique product identifier to comply with the standards referenced in Annex III, or equivalent European or international standards until harmonised standards are published.

That means a DPP team should treat QR and NFC as carrier options, not as automatic legal conclusions. The product group delegated act, when applicable, is the control point for where the carrier must sit and what product level it identifies: model, batch, or item.

A QR code is usually strongest when the user needs a visible, low-cost, phone-camera route to a web-resolvable DPP page and one-by-one manual scanning is acceptable. The CEN-CENELEC DPP design guidance treats QR codes as one of the main carrier options and notes that smartphone camera applications can read a QR code URI and hand it to the browser in a default consumer flow.

The weak points are physical durability, line-of-sight scanning, label space, and information density. More encoded characters increase the size and scanning burden, so a DPP QR code should normally carry a resolvable identifier or link rather than trying to store the passport itself.

NFC is stronger where close-range tap access is acceptable, the product surface makes printed codes unreliable, or the product needs a more durable embedded carrier. The CEN-CENELEC guidance lists passive RFID tags such as NFC among the main carrier options and distinguishes NFC's close-proximity alignment from QR-code line-of-sight scanning.

NFC is not automatically better. It adds electronic components, cost, environmental burden, and a different failure mode. It also requires the user to know where to tap, so physical cues and accessible instructions matter.

Freeze the data carrier only after testing the real product, not just the artwork. ESPR requires easy, free-of-charge access to DPP data according to access rights, while the design guidance highlights reading context, reading distance, lifespan, data capacity, speed, alignment, placement, and accessibility.

The evidence should show that the carrier identifies the right product level, resolves to the right DPP, survives the expected use environment, and works for customers, repairers, recyclers, market surveillance authorities, and other intended users.

Treat customs access as a handoff between the product passport, the Commission registry, and customs systems. For a covered product intended to be released for free circulation, the person placing it under that customs procedure must provide or make available the unique registration identifier linked to the DPP registry entry.

Customs may release the product for free circulation only after checking, at minimum, that the unique registration identifier and the commodity code match the data stored in the registry. ESPR also says that this release is not proof that the product complies with ESPR or other Union law, so teams should not use a passed customs check as a general compliance certificate.

ESPR distinguishes general access to the DPP from rights to specific data. Customers, economic operators, repairers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and other relevant actors must have free and easy access to the DPP based on the access rights in the applicable product-specific delegated act.

That means customs can be a privileged actor for data needed to carry out Union-law duties, but the public does not automatically receive the same view. The DPP must be designed for differentiated access, with rights to introduce, modify, or update data restricted according to the delegated-act access model.

The registry is not just the public DPP page. ESPR requires the Commission to set up a secure registry that stores at least unique identifiers and, for products intended for release for free circulation, the commodity code. Economic operators upload the required registry data and receive a unique registration identifier.

The public portal is different: it lets stakeholders search and compare DPP data in a way that respects their access rights. Customs integration is different again: the Commission must interconnect the registry with EU CSW-CERTEX so information can be exchanged automatically with national customs systems through the EU Single Window Environment for Customs.

Do not pre-fill a DPP customs template with additional customs clearance fields unless a product-specific delegated act or another sourced legal requirement actually calls for those records.

For this FAQ, the grounded ESPR customs fields are narrower: unique identifiers in the registry, the commodity code for products intended for release for free circulation, the unique registration identifier provided or made available to customs, and any additional registry data later specified by the Commission under the criteria in Article 13.

At minimum, a required DPP must be connected through a data carrier to a persistent unique product identifier. ESPR defines that identifier as a unique string that identifies the product and enables a web link to the product passport.

The product-specific delegated act decides whether the passport is established at model, batch or item level. That choice matters because a model-level identifier supports shared product information, while batch or item identifiers support more granular traceability and lifecycle updates.

Start with the required access path: scanning the carrier must lead to the right passport for the relevant product level. ESPR allows a linear barcode, two-dimensional symbol or other automatic identification data capture medium, but the delegated act can specify which carriers, layout and positioning apply to the product group.

Do not overload the carrier with the whole passport. In practice, teams should encode the identifier or a resolvable web link, then resolve users to the passport data according to access rights. Technical guidance from CIRPASS and GS1 treats the identifier choice as architecture-shaping because it determines which resolver, URI, Digital Link or equivalent path can get a scanner from the product to the DPP.

Operator and facility identifiers are not generic company labels. They are passport data elements used when the product-group delegated act requires traceability of value-chain actors or manufacturing locations.

If a required operator or facility identifier is not already available, Article 12 puts work on the economic operator creating or updating the passport: first seek confirmation that no identifier exists, then request one on behalf of the relevant actor or the actor responsible for the location or building, and provide the details once issued.

Keep evidence that proves the identifier can be traced from the product to the correct passport and that each required actor or facility ID is controlled, unique and maintainable. The evidence should be understandable to product, packaging, ecommerce, customs, market-surveillance and supplier teams.

Avoid unsupported commitments that a chosen identifier scheme is always sufficient. ESPR leaves important product-group details to delegated acts, and technical standards are still part of the implementation layer. Evidence should therefore show both the current rule basis and the design assumptions that may need to change.

Under ESPR, a digital product passport must contain the data specified in the applicable product-group delegated act. That delegated act must state which actors have access to which data, who can create or update passport data, and how long the passport remains available.

The practical rule is therefore to build an access matrix before publishing the passport. Each data field should be marked as public, restricted to defined value-chain actors, restricted to authorities or notified bodies, registry-only, customs-relevant, or not yet supported by the applicable product rule.

A useful DPP access design separates the public portal experience from the restricted operational layer. Public data should be reachable without unnecessary login friction. Restricted data should require authentication or equivalent controls tied to the actor's role.

The battery passport shows why this matters. Annex XIII to the Batteries Regulation divides passport content into public model-level information, information for persons with a legitimate interest and the Commission, information only for notified bodies, market surveillance authorities and the Commission, and individual-battery data for persons with a legitimate interest.

The ESPR registry is not the same thing as the public DPP web portal. The registry is a Commission-managed system that securely stores at least unique identifiers, and for products released for free circulation it also stores the commodity code. Economic operators upload the required registry data, and the registry returns a unique registration identifier.

The web portal is the public search and comparison layer. It must allow stakeholders to search and compare passport data consistently with the access rights set in delegated acts. Customs controls use the registry and passport data for risk management, customs controls, and release for free circulation.

Keep evidence that proves the access decision for each data field. A visitor, auditor, authority, supplier, repairer, or customs broker should be able to see why a field was public, restricted, authority-only, customs-relevant, or excluded from publication.

The evidence should also show who can change passport data. Read access for a recycler, repairer, authority, or customer does not automatically mean write access.

The registry is the official ESPR register for DPP identifier data. Article 13 requires the Commission to set up a secure digital registry that stores at least unique identifiers; for products intended for release for free circulation, it also stores the commodity code.

The registry should not be treated as the public product passport page or as a complete product-data repository. ESPR keeps the DPP architecture decentralised: the economic operator or a DPP service provider stores the passport, while the registry records identifier data needed for authentication, customs, and authority access.

The economic operator placing the product on the market or putting it into service uploads the data required for the registry. Once that data is uploaded, the registry automatically communicates a unique registration identifier associated with the unique identifiers uploaded for that product.

That registry response is operational proof of a successful upload, not proof of compliance. Teams should keep the registry identifier linked to the product passport record, customs workflow, and authority-support files so the same product can be traced through its DPP, registry, and import checks.

For products intended to be placed under the customs procedure for release for free circulation, customs authorities verify at minimum that the unique registration identifier and the commodity code correspond to the registry data. The verification is electronic and automatic once the registry-to-customs interconnection is operational.

This means the registry exists to support border controls and traceability, not to replace the product passport. Customs may retrieve and use registry and passport data for their duties, but a successful customs release is still not proof that the product complies with ESPR or other Union law.