Strip away the sustainability framing and Miller's argument is a straightforward one: a product that

Miller frames the digital product passport around five use cases that go well past sustainability reporting: reusing data across the supply chain, establishing one authoritative source of product information, improving traceability, supporting sustainable choices, and strengthening regional circular economy goals as sovereign manufacturing initiatives grow.
He then breaks down what a passport actually needs to work: a unique identifier at the item or batch level, a machine readable access point (almost always a QR code today), a registry that reliably resolves that code, a small set of mandatory data fields, a larger set of optional data for people who want more, governance over who is responsible for the data's accuracy, and, critically, access and presentation that changes based on who is scanning.
That last point is the one most manufacturers skip. Miller points to Volvo as the example furthest along: its EX90 electric SUV ships with a QR code inside the driver's door that resolves to a real battery passport, live in the field since 2024.
Here is Miller's sharpest line: most digital product passport demonstrations fail because they retrieve every possible data field from every back end system they can reach, instead of thinking about what the person scanning actually needs.
A maintenance engineer scanning a QR code wants service history and spare parts. The owner wants usage guidance. The recycling technician needs material composition. Point all three at the same wall of undifferentiated data and none of them get what they came for, and the passport stops being useful to any of them.
That is not a data problem. It is a product design problem, and it is the same problem that shows up whenever a manufacturer builds installed base data without designing for the person on the other end of the scan.
Strip away the sustainability framing and Miller's argument is a straightforward one: a product that can identify itself, resolve to a database, and present the right information to the right role is not a compliance artifact. It is a direct line between the manufacturer and whoever is holding the device.
That is the same idea sqanit customers have been building on for years, with QR codes today sitting on more than 1.2 million pieces of medical equipment worldwide. A serial numbered device, scanned by a technician, a hospital buyer, or the manufacturer's own service team, each seeing only what their role needs: service history, current configuration, the manual for that exact unit, or a direct line to book a repair.
One global manufacturer of surgical devices runs this today across a device fleet spread over dozens of countries. Before the QR scan connected the device to its full service record, a technician needed an average of several minutes and multiple calls to find out what they were looking at and what had already been tried. After: 29 seconds to a working answer, five times fewer calls back to the manufacturer, and a 93% adoption rate among the field technicians who now scan first instead of calling first.
Henry Schein saw a comparable shift after consolidating device data the same way: a 27% reduction in service cost and resolution times cut in half, because the information the technician needed was attached to the device itself instead of buried in a system they had to go find and log into separately.
Neither result came from a compliance mandate. Both came from treating the scan as the moment the manufacturer gets to be useful, exactly the bridge Miller describes.
Read more on how sqanit connects device data to a single authoritative source in sqanit and Akeneo: One Integration, Two Ways to Put Product Data to Work, and on the cost side in How to Reduce MedTech Service Costs by 27%.
Everything above describes the service side of the digital product passport idea: what happens after the scan, for equipment already in the field. That is a different problem from the one actually driving most of the regulatory urgency in Miller's report, the EU's Ecodesign for Sustainable Products Regulation (ESPR). Battery passports become mandatory for EV, industrial, and light transport batteries over 2 kWh from February 2027. Textiles and clothing follow soon after under the same regulation, with more product categories added over the next few years.
That compliance side, the mandatory identifiers, the registry submission, the sustainability and circularity data ESPR actually requires, is what sqanit built a dedicated product for. dpp.cloud is sqanit's dedicated solution for digital product passports: it gets a product's ESPR passport built, registered, and published, using the same underlying idea Forrester describes, one identifier, one scan, one authoritative source, but aimed at the regulatory obligation rather than the service layer sqanit itself covers.
For manufacturers weighing where to start: if your compliance deadline is the driver, see how dpp.cloud approaches the EU's Central DPP Registry launch, or the ESPR software buyer's guide for what to look for. If your product category is textiles specifically, dpp.cloud's breakdown of the textile DPP timeline and its required data points covers what Miller's report only summarizes at a high level.
Forrester's report gives manufacturers permission to stop thinking about the digital product passport as a regulatory obligation and start thinking about it as a product decision: what does the person scanning this device actually need, right now, from this exact unit.
That is the design question sqanit customers have been answering at the serial number level for years, and it is the design question dpp.cloud answers for the categories where a passport is a legal requirement rather than a choice.
See how sqanit builds a device level digital twin →
See how dpp.cloud handles ESPR compliance for batteries and textiles →
Getting started usually takes a few weeks, not months. We first look at your device fleet and workflows, then define a pilot with around 200–500 devices. From there, we handle the setup and onboarding and typically go live within 6–12 weeks.
Most customers are up and running within 6–12 weeks from kickoff. This includes the initial setup, device tagging and rollout to the relevant teams. The exact timeline depends mainly on fleet size, data availability and the systems we need to connect.
No. Users simply scan the QR code with their phone camera and are taken directly to the relevant device information or service flow. There is no app to download and no account or login required for the end user.
sqanit is API-first and designed to work alongside your existing systems. Device records and service data can be exchanged through REST APIs and connected to systems such as ERP, CRM, service or asset-management platforms.
sqanit also supports GS1 and UDI standards and is a GS1 Germany Solution Partner, so existing device identifiers can be used rather than creating a separate identification structure.
sqanit creates a traceable record of device and service interactions at serial-number level, helping teams maintain the documentation needed for regulated service and quality processes.
The platform is hosted in the EU and designed in line with GDPR requirements. Access and permissions can also be managed based on user roles and responsibilities.