Questions and answers

No universal QR-code or NFC mandate is supported by the 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.

A DPP team should therefore treat QR and NFC as design options until the applicable rule is known. For ESPR products, the delegated act controls where the carrier sits and whether the passport identifies a model, batch, or item. For covered batteries, Article 77 of the Batteries Regulation requires a QR code linked to the battery's unique identifier.

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 can be a stronger design option where close-range tap access is acceptable, the product surface makes printed codes unreliable, or the product needs a protected 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 adds electronic components, cost, environmental burden, and a different failure mode. Users also need 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.

Once the EU CSW-CERTEX interconnection is operational, customs may release the product for free circulation only after an electronic, automatic check confirms that the unique registration identifier and commodity code match the Registry. ESPR also says that release is not proof that the product complies with ESPR or other Union law.

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.

Customs can receive privileged access to data needed for Union-law duties without exposing that data to the public. The DPP must support differentiated access, and the delegated-act access model restricts who may introduce, modify, or update data.

The Registry is not the public DPP page. It is now operational and stores identifiers and mandatory registration metadata. Under ESPR it stores at least unique identifiers and, for products intended for release for free circulation, the commodity code. Economic operators upload the required 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 cited 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.

Keep the product identifier separate from the unique registration identifier. The product identifier connects the product to its passport. The Commission Registry generates the registration identifier after the economic operator uploads the required identifiers and metadata; ESPR says that registry response is not proof of compliance.

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 unique operator identifier for an actor other than the manufacturer, or a required unique facility identifier, is unavailable, Article 12 requires the economic operator creating or updating the passport to confirm that no identifier exists, request one for the relevant actor or location, and provide the issued details to that actor.

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.

Build an access matrix before publishing the passport. Mark each data field as public, restricted to defined value-chain actors, restricted to authorities or notified bodies, registry-only, customs-relevant, or unsupported 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.