DPP system requirements: what a real implementation needs

DPP system requirements: building real-world infrastructure for circular economy data

A Digital Product Passport is not simply a document or a website. It is a complex, multi-organizational infrastructure requiring careful alignment of technical standards, data governance rules, stakeholder incentives, and privacy safeguards. Implementing a functional DPP at scale demands clarity on what the system must actually do—and do well. This article synthesizes peer-reviewed research to identify the concrete system requirements that distinguish viable DPP implementations from incomplete pilot projects.

Defining the ecosystem and its nine core capabilities

King, Timms, and Mountney (2023) established a universal definition of Digital Product Passport Ecosystems (DPPE) through systems engineering methodology, synthesizing stakeholder requirements from EU regulatory consultations. Their work identifies that a functional DPPE rests on nine discrete capabilities, each addressing a distinct operational need. These capabilities span data collection and aggregation, access control, traceability validation, and lifecycle documentation—capabilities that cannot be reliably achieved by isolated point solutions.

The research demonstrates that systemic interoperability is non-negotiable. Organizations across supply chains—from raw material suppliers to recyclers—must exchange information using agreed protocols and semantic standards. This is not a nice-to-have; it is foundational. Without interoperability, each actor builds a separate, siloed system, defeating the circular economy objective that DPPs are meant to enable.

Equally critical, King et al. (2023) emphasize that effective DPPE implementation depends on agreed ethical principles and clear data-sharing incentives. A manufacturer will not voluntarily disclose supply chain details, material composition, or repair instructions to a competitor unless the system includes safeguards—confidentiality protections, usage restrictions, and benefit-sharing mechanisms—that make participation rational and fair.

Multi-stakeholder collaboration and lifecycle data governance

Pourjafarian and colleagues (2023) present a concrete technical implementation model: a cloud-based Digital Product Passport system built on the Asset Administration Shell (AAS) standard. Their work demonstrates how multiple stakeholders—manufacturers, distributors, service providers, recyclers—can collaboratively create and maintain product information from manufacturing through end-of-life recycling.

The AAS approach is significant because it provides a standardized, machine-readable representation of product data and its metadata across organizational boundaries. Rather than each actor maintaining separate databases in proprietary formats, the AAS creates a shared digital twin of the physical product. This enables a distributor to view repair requirements, a recycler to identify material streams, and a regulator to verify compliance—all from a single, authoritative source.

However, Pourjafarian et al. (2023) also flag two critical technical challenges that DPP system requirements must address:

• Interoperability across legacy systems: Supply chain partners operate diverse IT environments. DPP infrastructure must translate between formats, manage version control, and resolve schema conflicts without requiring wholesale system replacement.
• Data privacy and role-based access: A DPP cannot be “open to all.” System design must enforce role-based access controls—ensuring a competitor sees product specs but not cost data, and a regulator sees compliance evidence but not trade secrets.

Identifying functional and non-functional requirements systematically

Jansen, Meisen, Plociennik, and colleagues (2023) undertook systematic stakeholder engagement and literature review to identify and categorize DPP system requirements. Their research fills a critical implementation gap: while EU regulations (ESPR, Battery Regulation, Data Act) mandate DPP functionality, they do not prescribe technical architecture. This paper establishes clear criteria for designing DPP infrastructure.

The authors distinguish between functional requirements (what the system must do) and non-functional requirements (how well it must do it):

Functional requirements include:

• Data aggregation and integration from multiple upstream sources
• Real-time or near-real-time update of product lifecycle events
• Standardized data models aligned with GS1 EPCIS 2.0, GS1 Digital Link, or equivalent traceability frameworks
• Query and retrieval interfaces for regulated actors (producers, authorities, consumers)
• Audit trails and immutable records of data changes for regulatory accountability

Non-functional requirements include:

• Reliability: Regulatory data cannot be lost or corrupted; system uptime and backup protocols are non-negotiable.
• Scalability: The system must handle millions of products and billions of lifecycle events without performance degradation.
• Security: Authentication, encryption, and API rate-limiting protect against data breaches and unauthorized access.
• Data quality: Validation rules, schema enforcement, and anomaly detection ensure upstream data is fit-for-purpose before it enters the DPP.

Jansen et al. (2023) emphasize that DPP system requirements cannot be defined in isolation from circular economy objectives. The infrastructure must actively support disassembly, material recovery, and product refurbishment by making lifecycle data accessible and machine-readable to downstream actors.

Confidentiality-preserving data exchange as a system requirement

One of the most underestimated system requirements is confidentiality-preserving data sharing. Berger, Rusch, Pohlmann, and colleagues (2023) directly address this barrier through a case study of battery ecosystem stakeholders. Their finding is stark: companies refuse to share production data, supply chain details, and material composition unless confidentiality is guaranteed.

The researchers propose machine learning and data science approaches—including differential privacy, secure multi-party computation, and homomorphic encryption—as technical layers within DPP infrastructure. These techniques allow aggregate insights (e.g., “70% of batteries use this cathode material across the ecosystem”) without exposing proprietary details of individual manufacturers.

This is not theoretical. Berger et al. (2023) demonstrate that confidentiality-preserving data exchange directly enables sustainable product management. Recyclers can optimize material recovery processes, regulators can detect fraud, and circular economy participants can identify bottlenecks—all without leaking commercial secrets. For any DPP system deployed at scale, confidentiality-preserving mechanisms are therefore a technical requirement, not a feature.

Integration with existing standards and platforms

DPP system requirements cannot ignore existing supply chain infrastructure. Most large organizations already use GS1 EPCIS 2.0 for traceability, GS1 Digital Link for product identification, or similar frameworks. A new DPP system must integrate with these, not replace them wholesale.

The research confirms that successful implementations use established semantic standards (GS1, ISO standards for material identification) and API-first architecture to bridge legacy systems with new DPP infrastructure. This is a pragmatic requirement: organizations will not adopt a DPP that forces them to abandon years of supply chain investment.

Frequently Asked Questions

What is the difference between a DPP and a simple product database?

A product database stores information; a DPP system stores information with governance. King et al. (2023) establish that DPP ecosystems require role-based access control, confidentiality protections, audit trails, and interoperability across organizational boundaries. A simple database cannot enforce these requirements or prevent data misuse. A DPP is infrastructure with legal and technical safeguards built in.

Can a single organization operate a DPP, or must it be multi-stakeholder?

Pourjafarian et al. (2023) demonstrate that multi-stakeholder collaboration is the intended design. A manufacturer alone cannot create a complete product passport; recyclers and regulators must also contribute and access data. However, initial implementations may operate within a single organization or supply chain cluster, then expand. The system architecture must be designed for multi-stakeholder extension from the outset.

How do DPP systems balance transparency with commercial confidentiality?

Berger et al. (2023) show that privacy-preserving data science techniques—differential privacy, secure computation—enable this balance. A regulator can verify material composition without seeing a supplier’s exact costs. A recycler can access disassembly instructions without learning manufacturing processes. This is not theoretical; it is an achievable technical requirement if built into system architecture from design phase.

References

• King M.R.N.; Timms P.D.; Mountney S. (2023). A proposed universal definition of a Digital Product Passport Ecosystem (DPPE): Worldviews, discrete capabilities, stakeholder requirements and concerns. Journal of Cleaner Production. https://doi.org/10.1016/j.jclepro.2022.135538
• Pourjafarian M.; Plociennik C.; Rimaz M.H.; Stein P.; Vogelgesang M.; Li C.; Knetsch S.; Bergweiler S.; Ruskowski M. (2023). A Multi-Stakeholder Digital Product Passport Based on the Asset Administration Shell. IEEE International Conference on Emerging Technologies and Factory Automation, ETFA. https://doi.org/10.1109/ETFA54631.2023.10275715
• Jansen M.; Meisen T.; Plociennik C.; Berg H.; Pomp A.; Windholz W. (2023). Stop Guessing in the Dark: Identified Requirements for Digital Product Passport Systems. Systems. https://doi.org/10.3390/systems11030123
• Berger K.; Rusch M.; Pohlmann A.; Popowicz M.; Geiger B.C.; Gursch H.; Schöggl J.-P.; Baumgartner R.J. (2023). Confidentiality-preserving data exchange to enable sustainable product management via digital product passports – a conceptualization. Procedia CIRP. https://doi.org/10.1016/j.procir.2023.02.060