The EU's central DPP registry has been live since 19 July 2026. Manufacturers in regulated categories are now mapping product data to ESPR fields, choosing a platform, and planning for the battery passport deadline in February 2027. All of that work is necessary. None of it is the point.

A new report from Forrester, "The Digital Product Passport Is A Bridge To Your Customer" by analyst Paul Miller, makes an argument worth sitting with before you finalize your DPP setup: a passport that satisfies ESPR can still fail at the one thing that makes it worth building at all.

What the report actually says

Miller identifies five uses for a digital product passport that go beyond sustainability compliance: reusing supply chain data instead of collecting it twice, establishing one authoritative source for product information, improving traceability across the value chain, helping people make informed choices about a product, and supporting regional circular economy goals.

He also lays out what a passport technically needs: a unique identifier at item or batch level, a machine-readable access point (in practice, almost always a QR code), a registry that can be trusted, a defined set of mandatory and optional fields, and governance that keeps the data accurate over time. Then he adds a requirement most teams skip past: access and presentation that change depending on who is scanning.

His example is Volvo's EX90 electric SUV, which has run a live battery passport since 2024, well ahead of the regulatory deadline.

Where most DPP rollouts fail

Miller's central criticism is blunt: most digital product passport demonstrations fail because they pull every available data field from every connected system, instead of asking what the person scanning actually needs.

Think through who scans an ESPR passport in practice. A compliance auditor checking conformity needs certificates and test reports. A retailer or end customer wants material composition and care instructions, not a data schema. A recycler needs disassembly information and material fractions. If your product involves any kind of service or repair, a technician needs spare parts and service history, not a sustainability score.

Show all of that to all of them, and the passport is technically compliant and practically useless. Nobody scans a QR code, gets a wall of fields they don't need, and comes back for a second look.

Why this matters more, not less, under ESPR

It would be easy to read this as a nice-to-have layered on top of compliance. It isn't. ESPR's own structure already assumes differentiated data: the regulation distinguishes mandatory fields from optional ones and requires governance for accuracy, exactly the elements Miller lists as passport requirements. For textiles alone, the current specification runs to 49 data points across four categories, and not every one of those points belongs on the same screen.

A passport built as one long data sheet meets the letter of the regulation and misses what the EU registry going live was actually meant to enable: a working link between your products, the people who handle them across their life, and the compliance data behind them.

The commercial case for getting this right is its own topic, and we have covered it in depth elsewhere: how a DPP moves from a compliance project to a competitive advantage, and how manufacturers are already turning QR scans into after-sales revenue. What Forrester adds is independent confirmation that the underlying design principle, presentation by role, is not a dpp.cloud opinion. It is where the analyst world is landing too.

Built for who is actually scanning

This is the reason dpp.cloud's passports are built on device-level identity rather than product-level records alone. A product-level passport can list what a material is made of. It cannot tell a repair technician which specific unit they are holding, what has already been replaced on it, or what its individual service history looks like. Role-based presentation needs that granularity underneath it, or there is nothing to present differently.

That architecture is not new to us. It is the same foundation sqanit, the company behind dpp.cloud, already runs in regulated medtech deployments, where a single scanned device needs to show one thing to a maintenance engineer and a different thing to the person using it. Bringing that to ESPR-driven manufacturers in textiles and electronics means your compliance data and your customer-facing data live on the same passport without competing for the same screen.

For a textile or electronics manufacturer, that could mean one QR code that opens a compliance view for an auditor, a care and material view for a shopper, and a disassembly view for a recycler, all from one product record, mapped once out of your existing PIM.

What to do before your passport goes live

Before you finalize field mappings and call your ESPR passport done, answer one question: who scans this, and what does each of them actually need to see? If the honest answer is "everyone sees everything," you have built a compliance document, not the bridge to your customer Forrester is describing.

If you want a second pair of eyes on your specific setup, a 30-minute strategy session is the fastest way to get one. We look at your product data, your regulated categories, and who actually needs to scan your passport, then tell you what a role-based rollout looks like for your catalog.

Book your strategy session