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 remain linked to the correct passport and registry record. ESPR defines a unique product identifier as a unique string that identifies a product and enables a web link to its passport. A carrier that opens only a generic marketing page does not meet that function. If a service URL may change, keep the identifier stable and maintain a resolver or controlled redirect for the required availability period.

Commission Implementing Decision (EU) 2026/1736 has applied since 15 July 2026. It cites EN 18219:2026 for unique identifiers and EN 18220:2026 for data carriers, alongside four standards for data exchange, persistence, APIs, and interoperability. Conformity gives a presumption of conformity only for the ESPR Articles 10 and 11 requirements covered by the cited standard; the product delegated act still decides passport granularity, carrier placement, access rights, and product-specific rules.

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 an authorisation layer behind the carrier. The carrier is an entry point, not the access-control mechanism for confidential technical documentation, commercially sensitive data, authority-only information, or third-party write access. The applicable delegated act, rather than a generic role model, decides which actors may read or change each field.

Test the carrier in three 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 a physical scan. The Commission launched the DPP Registry and a testing environment on 20 July 2026; product-group duties still depend on the applicable legislation.

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.

Connect each decision to the delegated act, identifier standard, physical label test, resolver or URL design, access matrix, and registry or customs data path. A working customer scan does not prove that restricted authority access or registry verification works.