Digital Product Passport QR Code Requirements: What the EU Rules Say

A QR code is a machine-readable carrier that can point a phone or scanner toward product information. The passport is the governed record behind that carrier: the unique product identity, required data, access rights, update responsibilities, and technical services that keep the information available.

That distinction matters in procurement. A polished mobile page proves that a link resolves and content can be displayed. It does not by itself prove that the product is in legal scope, the required data are complete, restricted fields are protected, identifiers are persistent, or the record can survive a provider change.

ESPR requires the applicable delegated act to specify one or more data carriers, their layout and positioning, and whether the passport is established at model, batch, or item level. The carrier must be physically present on the product, packaging, or accompanying documentation as the product rule specifies.

This means teams should not lock a universal packaging decision too early. A QR code may be the practical choice for many consumer journeys, but the legal answer depends on the rule for the product group. The same rule also has to address how customers can access the passport before committing to a distance sale.

The Batteries Regulation is a separate adopted-law anchor. It requires covered batteries to use a QR code that gives access to the battery passport and connects the passport to a unique identifier. Its detailed scope and 18 February 2027 date should not be copied across unrelated categories.

Battery rules are therefore useful as a working example of how a carrier, identifier, public information, restricted information, and lifecycle responsibilities can fit together. They are not a universal template for every future ESPR passport.

A credible DPP architecture begins after the code is scanned. The destination must resolve the correct product identity and present information according to the access rights in the applicable rule. The underlying data should be structured, machine-readable, accurate, complete, current, and transferable across providers.

For a prototype, separate the visible consumer experience from the control layer. Show which system owns each value, how a correction is approved, how restricted data are protected, how the identifier behaves after a migration, and what happens if the service provider fails.

Ask the demonstrator to name the law, product scope, data carrier rule, identifier level, and effective date behind every compliance claim. Then test the operational controls rather than judging only the page design.

The best early prototype is honest about unresolved category fields. It can validate identity resolution, supplier evidence, access control, export, and corrections without claiming that a draft dataset is the final legal passport.