The Digital Product Passport (DPP) is frequently discussed as a new compliance obligation: collect the required information, attach a data carrier and make the record available. That interpretation is understandable—but too narrow.
Under the EU Ecodesign for Sustainable Products Regulation, the DPP is intended to provide electronic access to relevant information about products, components and materials. The exact requirements will be defined for individual product groups. Yet the architectural challenge is already visible: information must remain identifiable, understandable, current and accessible to authorised actors across organisational and lifecycle boundaries.
A QR code can provide an entry point. It is not the passport itself.
Begin with the questions the data must answer
An effective DPP architecture starts with use cases, not fields in a form. A manufacturer may need evidence of material composition. A service organisation may need the correct maintenance instructions for a specific product instance. A recycler may need safe disassembly information. A market surveillance authority may need conformity-related evidence. A customer may need verified sustainability information.
These actors do not require identical data or identical access. The architecture therefore has to answer five questions:
— Identity: Which product model, batch or individual instance does the information describe?
— Meaning: Are terms, units and classifications interpreted consistently?
— Provenance: Who supplied or changed the data, and when?
— Access: Which actor may see which information under which conditions?
— Continuity: How will links and records remain usable throughout the relevant lifecycle?
If these questions are postponed, the result is likely to be a collection of disconnected documents. If they are addressed early, the DPP can become part of a reusable industrial data foundation.
A passport should connect data, not duplicate every system
Most companies already hold relevant information in product lifecycle management, enterprise resource planning, manufacturing execution, quality, supplier and service systems. Replacing those systems is neither necessary nor realistic.
The DPP should instead act as a governed access layer. It can link stable product identities to authoritative data sources, translate information into agreed semantic structures and expose the appropriate view for each authorised role. Some information may be stored directly in a passport repository; other information may remain distributed and be retrieved through controlled services.
A practical architecture commonly includes:
— a persistent identity and resolvable data carrier
— machine-readable information models and vocabularies
— connectors to authoritative source systems
— lifecycle events and version management
— authentication, authorisation and usage policies
— APIs for exchange with partners and public services
— monitoring for data quality, availability and change
Asset Administration Shells can support this approach by providing standardised representations and submodels for industrial assets. They are not the only possible component, but they can reduce bespoke integration and support continuity between product, production and service data.
Compliance and value creation can use the same foundation
The strongest business case for DPP readiness is not limited to regulatory reporting. The same structured information can support faster service, more precise spare-parts identification, remanufacturing, product-as-a-service models, supply-chain transparency and better product development feedback.
This does not mean that every conceivable data point should be included. Data collection has a cost, and commercially sensitive information requires protection. The goal is a deliberate minimum: the information needed for defined use cases, with sufficient quality and governance to make it trustworthy.
Start small, but design for a lifecycle
A sensible first pilot selects one product family and two or three high-value use cases. The team maps available data, identifies gaps, defines identity and access rules, implements a reference chain and tests it with the people who will actually use it. The result should be evaluated not only for technical functionality, but also for ownership, maintainability and scalability.
The DPP should not become a late-stage compliance portal disconnected from engineering and operations. Designed as data architecture, it can provide the connective tissue between product development, production, use, repair and circular recovery.
EIRAS develops DPP reference architectures and demonstrators with manufacturers and technology partners. Talk to us about a focused readiness assessment or pilot for one product family.