EU Digital Product Passport QR Code and Data Carrier Implementation Guide

ESPR Article 9 says product-group passport requirements must specify the data to include, one or more data carriers, the data carrier layout and positioning, whether the passport is at model, batch, or item level, access before purchase, access rights, update rights, and the period for passport availability. That means a team should not launch a blanket QR-code policy across all products before confirming the applicable delegated act and product granularity.

ESPR Article 10 then sets the core technical baseline: the passport must be connected through a data carrier to a persistent unique product identifier, and the data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act.

A DPP QR code should usually carry a stable identifier or URI that can resolve to passport data, not a large bundle of passport data embedded in the symbol. ESPR requires open, interoperable, machine-readable, structured, searchable, transferable data without vendor lock-in. ETSI guidance also warns that QR codes have limited data capacity and points toward identification, resolution, encoding, decoding, and verification methods rather than plain-text QR dumps.

CIRPASS architecture examples describe a practical flow: the economic operator creates the product identifier, makes machine-readable DPP content available at digital locations, registers links in a resolver service, and lets a user scan a QR code containing a product identifier encoded into a web link. The resolver then returns typed links, and data sources apply the relevant access level.

The QR-code experience is a compliance and usability issue, not only a print-quality issue. ESPR requires free-of-charge and easy access to the DPP based on the access rights set in the applicable delegated act. Dealers and online marketplaces also need a digital copy of the data carrier or unique product identifier, or a webpage link, so potential customers can access the passport where they cannot physically scan the product.

CEN-CENELEC CWA 18186 treats DPP design as an information portal and access-rights problem: public data should be available without login or personal data collection, while restricted data can be controlled through software roles, login, or other authentication. That distinction should drive the QR landing page, resolver rules, and user experience.

GS1 guidance is useful for products that already use GS1 identifiers or where a product group accepts GS1-compatible identifier and carrier designs. The GS1 General Specifications define GS1 identifiers, GS1 Digital Link URI syntax, GS1 QR Code, QR Code symbology, human-readable interpretation, indirect mode, and related data-carrier concepts. That supports a disciplined implementation, but it does not by itself decide which data carrier an ESPR delegated act will require.

CEN-CENELEC CWA 18186 is useful design guidance from the CircThread experience, but it states that a CEN Workshop Agreement is not an official CEN standard and should not be treated for implementation planning. ETSI ES 204 082 and TS 103 881 provide DPP information-model and quality-property context, especially accessibility, persistence, authenticity, identifiability, integrity, verifiability, and traceability.

A defensible implementation file should prove that the printed carrier, decoded identifier, resolver, access-rights model, and passport data all work together. The evidence should be product-specific because ESPR delegated acts can vary by product group and by model, batch, or item level.

Do not treat a successful phone scan as complete verification. The evidence file should also show that the identifier is persistent and unique, the resolver returns the expected links, public users get public data without unnecessary barriers, restricted actors get only the fields they are entitled to, and the DPP remains available for the required period.