EU Digital Product Passport Data Carriers, Access Control, and UX

The ESPR lets product-group delegated acts specify whether passport data refers to the model, batch, or item. That level drives the carrier design. A model-level passport can reuse one carrier across a product family; a batch-level passport needs a batch-specific identifier; an item-level passport needs a unique carrier or encoded identifier for each individual unit.

The identifier must be stable enough to connect the physical product to its passport and to the registry data used by authorities. If the carrier points only to a marketing page, or if the URL changes without a resolver or redirect strategy, the passport can fail even when the visible code scans.

ESPR defines a data carrier broadly as a linear barcode, two-dimensional symbol, or other automatic identification data capture medium. The law does not make one universal carrier choice for every product. The delegated act, product size, durability, user population, supply-chain context, and reader environment should decide whether QR, Data Matrix, NFC, RAIN RFID, or another carrier is appropriate.

For consumer UX, QR codes and NFC are usually easier to scan with ordinary smartphones. Data Matrix can be useful where compact 2D marking is already standard, but native consumer-phone support may be weaker. RAIN RFID can support bulk or non-line-of-sight operations in logistics and recycling, but it is not the same UX as a consumer scan and can be affected by materials and reader infrastructure.

The scan should not take every actor to the same view. ESPR requires free and easy access based on access rights set in the applicable delegated act. Customers, repairers, recyclers, market surveillance authorities, customs authorities, economic operators, civil society organisations, and other actors may need different data. Public passport data should be reachable without forcing a consumer to create an account, install a proprietary app, or disclose personal data.

Restricted data and update functions need a real authorisation layer behind the carrier. The carrier itself should open the right starting point, but it should not be treated as the access-control mechanism for confidential technical documentation, commercially sensitive data, authority-only information, or third-party write access.

A useful DPP carrier has to work in three different situations. A customer or repairer may scan the product in a shop, home, or workshop. A restricted user may need to authenticate before seeing technical or commercially sensitive data. Customs and market surveillance authorities may start from registry or commodity-code checks rather than from a physical scan.

The visible UX should make clear what the carrier does, while the technical UX should route the user to the correct data view. Do not make the code mysterious, app-only, or dependent on fragile campaign infrastructure. If the delegated act allows placement on packaging or documents instead of the product, document why the carrier will remain accessible through the expected life cycle.

The evidence file should prove that the carrier, identifier, access rules, and UX were deliberately designed against the ESPR requirements and the product context. It should also show that the implementation was tested, not only specified in a policy.

The strongest records connect each decision to the delegated act, the identifier standard, the physical label test, the resolver or URL design, the access matrix, and the registry/customs data path. This matters because a working customer scan is not enough if restricted authority access or registry verification fails.