INTRODUCTION

With the Green Deal adopted in 2019, the EU is pursuing a more sustainable European economy that aims to achieve climate neutrality by 2050 [1]. The Green Deal has led to several regulations, including the CEAP [2], the SPI [3], and the ESPR [4]. To optimize products, the EU proposes the introduction of a Digital Product Passport (DPP) [4] to enhance communication between producers and recyclers and optimize product lifecycle management [5]. A DPP is defined as “a product-specific data set that contains [...] information and that [...] is accessible via a data carrier” [4]. It enhances data transparency and reliability while promoting the circular flow of materials [6].

By providing granular data on material composition and disassembly, the DPP acts as a technical enabler for the 9R, facilitating high-value circularity through repair, remanufacturing, and high-quality recycling [7,8]. Research demonstrates that this transparency can significantly reduce material consumption through optimized, data-driven production control [9] and lower product carbon footprints by enabling automated Life Cycle Assessments (LCAs) for more sustainable decision-making [10]. According to BMUV [11], the aim is to apply the DPP to all products and services in the future. The obligation will be introduced progressively, product group by product group, through delegated acts under the ESPR and through sectoral regulations [4,12]. Where applicable, all actors along a value chain must share their product-related data in a DPP [13].

The framework for designing and implementing DPPs has become considerably more specific. Six harmonized standards now cover the horizontal technical layer [14], and an implementing regulation defines the central registry infrastructure [15]. These acts specify what a compliant passport must provide in technical terms but say much less about what an organization must do to produce one. For most product groups, the product-specific requirements are still being defined [12]. Consequently, the requirements for implementing DPPs in practice remain unclear [16], particularly regarding the organizational aspects of implementation [17]. Progress in standardization does not render the question of practical requirements obsolete; rather, it allows for a distinction between the requirements specified by the framework and those that remain open for implementers. To our knowledge, no study has made this comparison. Therefore, this paper explores the requirements for implementing DPPs in practice and poses the question: What are the requirements for implementing the Digital Product Passport in practice?

This paper systematically elicits and structures empirically grounded practical requirements, compares them with the current normative framework, and derives implications and a research agenda to inform future technical design efforts. To answer this question and gather first-hand empirical data, we conducted a qualitative interview study with nine experts, a SLR, and a multivocal literature review of secondary data. Following transcription and analysis according to [18], we synthesized and structured 76 requirements across 11 distinct categories according to the technology-organization-environment (TOE) framework [19]. We then determined which requirements the harmonized standards and implementing acts already address and which remain open in practice.

The remainder of this paper is structured as follows: Fundamentals Section introduces the DPP and its regulatory and normative framework, Methods Section describes the research design, Requirements for the Implementation of the Digital Product Passport in Practice Section presents the requirements, Discussion Section discusses them, and the last Section concludes.

FUNDAMENTALS

Digital Product Passport

A DPP is a structured collection of product-related data with a predefined scope and definable access rights [20]. The concept of DPPs has emerged as a key enabler of the transition toward a Circular Economy (CE), providing structured and accessible product-related data throughout the entire lifecycle [13,21]. The 9R comprise different strategies to keep materials in the cycle (e.g., refuse, reuse, and recycle) [22]. DPPs can serve as digital artifacts that support these strategies, by promoting transparency and traceability of products and materials [8]. The application of the DPP should provide benefits for each actor in the value chain [23,24]. By integrating specific information on components, materials, chemical substances, and other relevant data from all phases of the product lifecycle into the DPP [25], transparency can be created across the entire product lifecycle [20]. Retailers can improve customer orientation and sustainability in their product ranges [21], while remanufacturers gain easier access to repair and disassembly instructions [24].

For example, research projects such as CIRPASS and CIRPASS-2 are already working on the concept development and DPP demonstrators [26,27]. In addition to the DPP, related terms such as Product Passport (PP) and Material Passport (MP) have circulated. Both were in use long before the EU introduced the DPP. Van Capelleveen et al. (2023) [28] date the first use of the product passport to 1995 and the material passport to 2003, noting that EU regulation later adopted the product passport naming convention. PP and MP are therefore precursor concepts rather than equivalents of the DPP as defined by the ESPR, in which material information such as substances of concern forms one information domain among others [4]. The Battery Passport (BP) has a different status, because the Battery Regulation requires it for batteries starting in February 2027 [29]. These differences in status and scope increase the complexity of discussions on DPP standards and requirements [28]. An example implementation of a BP using Asset Administration Shells (AAS) resulted of the Catena-X Data Space project [30].

Both DPPs and digital twins utilize product-related lifecycle data but emphasize different functions. A DPP structures and makes a defined scope of product information accessible to authorized actors [20]. Stark and Damerau (2019) [31] define a digital twin as a digital representation of an individual product or product-service system that captures selected properties, states, and behaviors through models, information, and data within or across lifecycle phases. Werner et al. (2025) [20] illustrate how these concepts can complement each other through a Modular Digital Twin, which combines application-specific data and partial models to generate product sustainability information for provision through a DPP. The distinction concerns their respective functions rather than whether the information is static or changing. While digital twins can generate and analyze product information, the DPP makes a defined selection of this information available for exchange across the value chain. In the approach proposed by Werner et al. (2025) [20], the AAS supports the structured representation of lifecycle information, providing a possible technical basis for linking these functions. DPP implementations can draw on digital twin data and infrastructure without incorporating the full range of analytical functions that a digital twin may provide.

A significant body of literature focuses on the technical requirements for implementing DPPs along the product lifecycle, including Blockchain solutions [32,33], AAS [13,25], and Knowledge Graphs [34]. Sousa et al. (2024) [33] describe key technologies for ensuring data integrity and accessibility, while Szaller et al. (2023) [24] report that DPPs improve energy and resource efficiency. Several studies highlight the need for standardized data models and platforms [35–37]. Berger et al. (2023) [38] identified the lack of standardization and concerns about data protection as challenges for implementation.

Regulatory and Normative Framework

The ESPR [4] establishes the DPP as a legal instrument but leaves its technical realization to subsequent acts. This realization has advanced considerably since the regulation entered into force. Requirements for DPP implementation now originate from four levels, which differ in legal force, in scope, and progress.

The first level is the ESPR itself. It defines the data content of a passport, the use of data carriers with permanent unique identifiers, the granularity level, the obligations of the actors involved, the availability periods, and technical requirements for openness, machine readability, and interoperability across systems [4]. These provisions are binding but describe outcomes rather than technical solutions, which is why the regulation refers to harmonized standards for concrete specifications.

The second level encompasses the horizontal technical requirements. Under standardization request 5423 [39], the joint technical committee CEN/CLC JTC 24 developed eight European standards for the DPP system. Six of these address data exchange protocols [40], unique identifiers [41], data carriers [42], data storage, archiving, and persistence [43], application programming interfaces for passport lifecycle management [44], and system interoperability [45]. The Commission cited these six as harmonized standards in the Official Journal in July 2026 [14], so a passport conforming to them is presumed to conform with the corresponding ESPR requirements. The two remaining standards, which cover access rights management, information system security, and business confidentiality [46] and data authentication, reliability, and integrity [47], were still drafts at the time of writing in September 2026 and carry no presumption of conformity. Access management and data authentication are therefore the two areas of the horizontal framework that remain technically unsettled.

The third level pertains to the registry. The implementing regulation on the DPP registry [15] defines how users are identified and authorized, how registration identifiers are generated, and how identifiers, customs commodity codes, verified service providers, and the semantic repository for passport data are maintained, with every operation logged. The registry does not hold the passports themselves. The Commission operates the registry, while the passport data remain with the economic operators or their service providers; the architecture is therefore neither fully centralized nor fully decentralized.

The fourth level encompasses product-specific requirements and is the least developed. A DPP becomes mandatory for a given product only when a delegated act for that product group or a sectoral regulation requires it. The first ESPR working plan [12] identifies six priority product groups with indicative adoption dates ranging from 2026 to 2029. The battery passport follows a separate track under the Battery Regulation [29] and will apply from February 2027. Consequently, the specific data that a passport must carry and the timeline for implementation remain open for most product groups.

Beyond the European framework, international standardization has embraced the DPP. Following a proposal by DIN, ISO and IEC established the joint technical committee ISO/IEC JTC 5 Digital Product Passport in spring 2026. Its scope includes cross-sectoral and cross-system interoperability, as well as the framework of the DPP system and ecosystem, while excluding sector-specific standards and topics already covered by other ISO and IEC committees [48]. CEN/CLC JTC 24 collaborates with JTC 5 as its international counterpart. The committee commenced its work in the third quarter of 2026, with initial deliverables expected by 2028 [49]. For implementations within the single market, the European standards will serve as the reference, while the international layer will determine the extent to which a passport developed according to them also works in other markets.

In summary, the framework is more nuanced than the general provisions of the ESPR alone suggest. However, it does not yet clarify which requirements an implementation must meet beyond those specified by the standards. The requirements identified in this study were collected independently of this framework, allowing for a comparative discussion and the ability to distinguish between requirements already covered by the framework and those that remain unresolved in practice.

METHODS

To investigate practical requirements for DPP implementation, we adopted a qualitative, multi-source research design that combined (1) a SLR, (2) a multivocal review of grey literature, and (3) semi-structured expert interviews. Each evidence stream was examined separately before its findings were compared and synthesized. Combining the streams broadened the evidentiary basis and enabled a comparison between academic and practitioner perspectives.

Literature Review

Following the guidelines established by Webster and Watson [50] and PRISMA 2020 [51], for literature reviews, we conducted a SLR. We searched AISeL, Scopus, and ScienceDirect using the terms “digital product passport,” “digital passport,” and “product passport” in the title, abstract, and keyword fields. We deliberately retained these partially overlapping concepts, because databases differ in how they handle phrases and query expansion, and earlier publications used “digital passport” or “product passport” before the term DPP became established [21]. Table 1 lists the search queries and results for each database, yielding 21 (AISeL), 82 (Scopus), and 179 (ScienceDirect) papers, for a total of 282 articles.

We reviewed the papers in multiple iterations. As shown in Figure 1, we screened 282 database records and excluded 218 during the title-and-abstract screening because they did not meet the inclusion criteria (see Table 2). We retrieved 64 reports for full-text assessment. After this assessment, 34 reports were excluded, resulting in 30 publications being included. Forward and backward citation searching identified one additional peer-reviewed publication, yielding a final corpus of 31 publications. The final peer-reviewed sample was predominantly concentrated in Scopus: 30 of the 31 included publications were indexed there. This concentration should not be interpreted as evidence that Scopus provides exhaustive coverage. It may reflect differences in disciplinary coverage, indexing practices, and database search functionality.

Because DPP is still a new topic and is driven by national and EU regulations, we complemented the peer-reviewed corpus with grey literature, in line with the rationale for multivocal literature reviews [52]. These data sources allow consideration of white papers, position papers, and reports from governments, consultancies, and industry [53]. We identified these sources through Google web searches. The commercial sources include websites of DPP providers, such as iPoint-systems GmbH (Reutlingen, Germany) [54] and Crossmint, Inc. (San Francisco, CA, USA) [55]. The project and institutional sources comprise publications from research projects, such as CIRPASS [26] and CIRPASS-2 [27], as well as reports from institutions such as the Wuppertal Institute [56], DIN, and DKE [57], and the German Economic Institute [13]. Some sources were identified through the references in previously retrieved sources. The ESPR, the only regulatory source, was also retrieved through a web search. We included commercial sources if the company explicitly offers a DPP solution and its website describes concrete DPP functions. We included regulatory, project, and institutional sources if the document outlines specific DPP functions or requirements. All sources had to be publicly accessible and written in German or English. We stopped searching when new results no longer added information beyond the sources already included. For interpretation, we categorized the grey literature sources as regulatory or normative, project and institutional, industry, or commercial. We did not treat their roles as equivalent. We used regulatory and normative documents to establish formal obligations or authoritative guidance. We used research projects and institutional reports for documented concepts, methods, and implementation experience. Industry sources provided contextual evidence about practice. Commercial-provider websites were used only to illustrate available offerings or publicly claimed functionality, not as independent evidence that a requirement had been validated, implemented successfully, or shown to comply with regulation. We excluded sources without an identifiable author or date. For the remaining sources, we followed the quality considerations proposed by Garousi et al. (2019) [52] and assessed authority, objectivity, methodological transparency, and direct relevance during interpretation.

The review yielded 25 publicly available pieces of information from existing secondary literature and studies, comprising 1 regulatory or normative source, nine project and institutional sources, and 15 commercial sources.

Expert Interviews

To enhance our understanding of the current state of research and practice in implementing DPPs and to enrich it with empirical knowledge from the field, we interviewed nine experts. Interviews are a data-collection method firmly rooted in the experiences of industry practitioners and their social environment [58,59]. We selected interview partners based on their stakeholder roles to obtain a comprehensive view, ensuring diverse backgrounds across different disciplines. Each interview was conducted using a semi-structured interview guide, maintaining structure and comparability while allowing flexibility to adapt to ad hoc situations during the interviews [18]. All interviews were conducted virtually, lasted an average of 46 min, and were recorded and transcribed for further analysis. Table 3 provides an overview of the experts and the length of each interview, along with their index number for reference.

The scientific interviews were conducted with five experts from the fields of standardization, sustainability, and battery passports. The four industry experts included two prospective DPP users, a sustainability consultant, and a software developer specializing in sustainability solutions. All nine experts have participated in DPP research projects with their respective institutes or companies. Geographically, they are all classified within the European region and possess several years of experience in their respective fields. Based on the transcribed interviews, we conducted a qualitative content analysis following Mayring (2015) [18] using MaxQDA. This approach allows for a systematic, rule-guided analysis of qualitative data. In the first step, we developed a coding scheme deductively, resulting in nine a priori codes related to the practical requirements of DPPs: Definition, Current State, Current State in Research, Current State in practice, Implementation, Requirements, Challenges, Terminology, and Prognosis. In the second step, we derived 65 subcodes inductively from the material. All transcripts were coded by a single researcher using a codebook that documented both the deductive and inductive codes. No further validation procedures were applied. The results of the literature review and qualitative content analysis were searched inductively for requirements.

Data Analysis

We derived the requirements by triangulating three data sources: the SLR of peer-reviewed publications, the analysis of secondary data, and the expert interviews. Triangulation indicates how broadly each requirement is documented across source types. It does not validate the requirements, which would necessitate testing them in implementation projects. We first grouped the findings of the SLR and the multivocal review under rudimentary categories that emerged during the literature screening: Storage, Multiple DPP, Implementation, Technology, Target Industries, Lifecycle, General, Standardization, EU & Regulation, Data & Information, and Access Management. We then compared these categories with respect to the concerns they addressed, such as the types and quality of product-related data or the governance of access rights, and inductively aggregated overlapping categories into 11 practice-oriented requirement categories with their respective requirements: Terminologies, Regulatory, Data Management, Standardization, Data, Application Fields, DPP-System, Access Management, Development, Implementation, and Usability. Four examples illustrate this assignment.

Werner et al. (2025) [20] report that DPP initiatives leave their data requirements uncertain, which we assigned to Data, and Gallina et al. (2023) [32] state that the DPP should initially target prioritized high-impact product sectors, which belongs to Application Fields. The technical foundations for building a DPP listed by Kebede et al. (2023) [34] fall under DPP-System, and the granular and controlled access to product data required by Adisorn et al. (2021) [21] falls under Access Management. Table 4 documents the resulting mapping. The category Data, for instance, rests on evidence coded under Data & Information and Lifecycle, whereas Data Management draws mainly on Data & Information, which holds the requirements concerning information handling.

Finally, we mapped the coded segments from the expert interviews onto this framework. The interviews supported the existing categories and provided empirical detail, but they did not yield a requirement category beyond the 11 derived from the literature. Table 5 shows which sources support each category, allowing the categories to be traced back to the academic discourse and the current state of practice.

To determine which identified requirements are already addressed by the normative framework, we compared each requirement against the four levels introduced in the section on the Regulatory and Normative Framework. We assigned one of three states: a requirement is considered covered when a provision of the ESPR, a harmonized standard, or the registry implementing regulation specifies it; partially covered when the framework addresses the underlying concern but leaves the concrete realization to the implementer, meaning that the requirement specifies how the provision is met in practice; and open when no provision addresses it. This comparison refers to the standards published in September 2026 and to the implementing acts in force at that time. The harmonized standards and the registry implementing regulation served as the benchmark for this comparison. We did not include them in Table 5 as a fourth evidence stream because they emerged only after our data collection, first as drafts in August 2025 and then as final versions in 2026. A requirement derived from a standard would be covered by that same standard by construction. The ESPR is the exception because it was already part of the secondary literature. Five requirements cite it both as a source and in their normative status; for these, the status restates the source without adding any new findings. Additionally, we classify each requirement by type, distinguishing technical (Tech) and organizational (Org) requirements from regulatory (Reg) conditions and managerial (Mgmt) recommendations because these differ in terms of who must act on them.

REQUIREMENTS FOR THE IMPLEMENTATION OF THE DIGITAL PRODUCT PASSPORT IN PRACTICE

Following the TOE framework [19], we structured the 11 requirement categories derived from our analysis along its technology, organization, and environment dimensions (see Figure 2). Baker (2011) [81] describes the framework as an examination of how technological characteristics, internal organizational factors, and external influences interact in the adoption of new technologies. This framework is applicable to the DPP, whose adoption relies on the technology itself [23], the resources and processes of the adopting firm [24], and a regulatory environment that has developed at the horizontal level while remaining open at the product-specific level [4,12,14]. Since no single dimension carries the requirements independently, we use the framework to structure the identified categories and their requirements.

We derived the eleven categories inductively from the material and subsequently assigned them to the dimensions, so the framework structured the results without guiding the coding. Several categories touch on more than one dimension. Data Management requires both technical mechanisms and organizational responsibility for data quality, while Standardization concerns bodies outside the organization as well as internal processes. We therefore assigned each category based on the dominant locus of action, that is, where its requirements must be acted upon. Categories whose requirements are settled by actors outside the adopting organization belong to the environment dimension. Categories in which the organization decides what passport it provides, for which products, and with what information belong to the organization dimension. Categories that describe the properties the DPP system and its components must satisfy belong to the technology dimension. Table 4 records this assignment with a brief rationale for each category. Where a category spans dimensions, the type column in Tables 6–9 highlights that distinction. Access Management sits in the technology dimension, while three of its seven requirements are organizational by type. Conversely, Application Fields exhibits the opposite pattern: three of its four requirements are regulatory by type because the delegated acts define the product groups, but the requirements take effect when an organization decides which of its products to start with. This is why we assign the category to the organization dimension.

Environment Requirements

Baker (2011) [81] defines the context as “[…] the structure of the industry, the presence or absence of technology service providers, and the regulatory environment.” Table 6 maps each requirement in this dimension to its supporting sources across the SLR, the secondary literature, and expert interviews.

Terminologies

The EU designation “DPP” is not universally used. Different terms and conceptual images circulate for essentially the same concept, and the distinction between the EU-wide DPP and topic-specific passports such as BP and MP remains insufficiently clarified, leading to confusion among stakeholders and overlapping implementations [13,60,65,56]. These terms stand in different relations to the DPP. Regulated sectoral passports such as the BP should be understood as domain-specific subsets of a unified DPP concept, adhering to a shared conceptual and technical framework even when distinct labels are used (I2, I4, I5, I8). PP and MP, by contrast, predate the regulatory DPP, with material information forming an information domain within a passport rather than constituting a passport of its own. Expert I3 distinguishes the DPP as a system from the DPP as a data layer, considering this separation necessary to avoid misunderstandings. The basic DPP framework, which encompasses data management among other aspects, should be consistent across all products (I6), while individual data standards can build upon it (I7). Companies should therefore define how existing passports are integrated, migrated, or phased out to prevent redundant passport solutions from emerging (I6). According to expert I1, organizations do not need to rebuild existing passport systems from scratch but can adapt their current structures to comply with EU DPP standards.

The harmonized standards define the terms of the DPP system without clarifying the relationship to preceding passport concepts. ISO/IEC JTC 5 addresses this cross-sectoral framing, with initial deliverables expected from 2028 [49], so the requirement remains open for now.

Regulatory

The ESPR establishes core requirements for DPPs, covering data content, the use of data carriers with permanent unique identifiers, granularity levels, actor obligations, availability periods, and overarching technical requirements for openness, machine-readability, and cross-system interoperability, with overall governance retained by the European Commission [4,23,70]. Several further EU policy initiatives reference these requirements and treat the DPP as an information instrument of the EU sustainability agenda [56,75]. Across these initiatives, the DPP is designed to ensure technical aspects such as interoperability and data authenticity for a broad audience over an extended period (I1). To guide their concrete application, the “8 pillars” developed in the CIRPASS project [26] should serve as a reference basis when deriving specific regulatory requirements for DPP implementations. Expert I4 emphasizes that the appropriate level of granularity should be driven by sector-specific regulatory requirements. Expert I3 notes that the EU DPP should function as a regulatory framework that references and builds upon existing technical standards rather than prescribing new ones. Legislators must therefore prevent the parallel development of incompatible country-specific DPP regulations, as such fragmentation would undermine global interoperability. Despite this regulatory framework, current ESPR requirements remain insufficiently specific regarding actor-level disclosure obligations (I2). Organizations should adapt their existing data exchange frameworks to the emerging delegated acts before they become binding, thereby avoiding costly rework later (I9). Acceptance among stakeholders depends on more than compliance. It requires a transparent and secure infrastructure that maintains data sovereignty [32] and complies with the ESPR, GDPR and related regulations such as the right to repair [6,63,67,68,73].

Standardization

The ESPR mandates open and interoperable standards [4], and the horizontal technical layer has since been specified through the EN 182xx series [14]. However, sectoral data standards with harmonized vocabularies remain largely absent [16] (I4, I7), as the published standards do not aim to provide them. EN 18223 states that avoiding sector-specific ontologies is an objective and instead enables the parallel use of multiple ontologies through a horizontal layer that is independent of technology, ontology, and domain [45]. Thus, practice and standardization address the same concern from opposite directions, a divergence we will discuss further. Standardization must encompass both process descriptions and the data structures relevant for DPPs [20,63]. Both should be based on a foundational system on which various standards can be built, depending on the application [66] (I3, I7), and the standards should remain flexible enough to accommodate sectoral variations Proposed foundations for a harmonized DPP data standard include the AAS combined with the IEC Common Data Dictionary [25], as well as formats such as GS1 and ISO standards [33]. However, the published standards do not adopt any of these. EN 18216 lists the AAS as one option in a non-exhaustive enumeration of data exchange solutions [40], and the IEC Common Data Dictionary is not referenced anywhere in the series. EN 18223 treats openness toward different technological approaches as a design principle and decouples data points from their definitions for that purpose [45]. Expert I1 notes that harmonized standards for the eight technical modules of the DPP system architecture must be finalized soon, emphasizing that existing frameworks such as the AAS serve as the technical basis for this work rather than something to be replaced. Six of the eight standards developed under the standardization request have since been cited as harmonized standards [14], while access rights management [46] and data authentication [47] remain in draft stage, a status that EN 18223 itself records [45]. The requirement raised in the interviews has thus been met in terms of timing, but not in the manner the expert expected, as the series does not build on the AAS or any other single existing framework. Given that complete harmonization across all data points is unlikely, expert I9 proposes an 80% rule: at least 80% of DPP data points should share a uniform description based on a common semantic model, which is sufficient for interoperability across systems and sectors. Standards should further define the information requirements of different stakeholder groups for R-strategies and common data exchange formats [57], be developed at the level of product groups or industries rather than individual passports, and achieve consensus among all involved parties on mandatory DPP content (I7). Beyond mandatory data requirements, DPPs should also provide a shared framework for the voluntary exchange of additional product information [56].

Organization Requirements

Baker (2011) [81] defines the organizational dimension as “[…] the characteristics and resources of the firm, including linking structures between employees and intra-firm communication processes […]”. Applied to the DPP, it encompasses the structures, resources, and communication processes a firm must have in place for successful implementation. Table 7 lists the sources for each requirement.

Application Fields

In the future, the DPP is intended to be used across a range of sectors and industries [76] and ultimately aims to apply to all products and services [32].

However, the legal basis does not extend that far. The ESPR applies only to physical products placed on the Union market and does not encompass services, meaning that this ambition exceeds the current regulatory scope rather than identifying a gap within it. Given the scale of this ambition, the rollout should prioritize high-impact sectors [20,32]. The first ESPR working plan follows this logic by naming six priority product groups with indicative adoption dates [12]. Practical implementations should initially focus on textiles [69,82,83], batteries [84,85], automotive [86], construction [34,87], electronics [85], and packaging [71], a prioritization that most interviewed experts confirm (I1, I2, I5, I8, I9). Expert I4 proposes a principle of economic proportionality, suggesting that the depth of a DPP implementation should reflect the product’s economic value and circularity potential. DPP solutions should also be scalable across all relevant sectors to ensure that they remain applicable and affordable beyond the prioritized ones [23]. These priorities indicate where the rollout begins, not how requirements differ between sectors. Our design does not support such a comparison because we elicited the requirements across sectors. The normative framework does not yet allow for this either, since the product-specific acts that would define sector requirements are still pending for most product groups.

DPP-System

Koppelaar et al. (2023) [78] conceptualize the DPP as a container for datasets from all phases of the product lifecycle linked to a universal product identifier, distinguishing between static, read-only passports and dynamic passports that can be updated over time [20,33,65,70]. Akhras et al. (2023) [64] emphasize the DPP’s role as an end-to-end information system that makes lifecycle data accessible to all relevant parties across the value chain. Consequently, a DPP must function as a platform for data exchange [77], allowing actors to insert and consume data in support of circular supply chains. It must support identification technologies so that link digital data to physical products throughout the lifecycle [66]. From a system perspective, Jansen et al. (2023) [68] outline that DPP infrastructures should rely on decentralized data storage, clear and machine-interpretable semantics, standardized data schemas, well-defined APIs, and a modular architecture that ensures accessibility, availability, and transferability of product identifiers along the value chain.

Expert I9 proposes a Digital Twin Registry based on the AAS, suggesting that digital twins can serve as a technological component of DPP implementation. Organizations from various application domains can then incrementally add data points, lowering the barrier to implementation and ensuring compatibility with standards still under development (I9). The same expert notes that even in fully decentralized DPP architectures, a central registration authority is necessary to establish and validate participant identities and roles during onboarding [16]. Given that DPPs were still in the early stages of development when the interviews were conducted (I6, I7), system architectures should remain open to iterative refinement to incorporate emerging standardization results (I7). With the horizontal standards now published, this requirement particularly applies to the product-specific acts that are still pending. For the time being, organizations should therefore work with exploratory prototypes rather than large-scale pilots and adjust their roadmaps as new guidance becomes available (I6, I8). At the same time, DPP pilots should move beyond marketing-driven front-end prototypes (e.g., LyondellBasell B.V. [88]) toward production-ready systems that are integrated with back-end system and capable of meeting regulatory and standardization requirements that are still under development (I8). The decisive step is therefore the transition from conceptual or interface-focused designs to DPP and BP systems that operate in real settings. Commercial DPP offerings should be developed as interoperable system components rather than isolated front-end products. Organizations must be able to switch providers without disproportionate effort or loss of data, making the avoidance of vendor lock-in a fundamental requirement of the system design (I3, e.g., Circularise B.V. [86], Vaayu Tech GmbH [89], Spherity GmbH [90]).

Data

A DPP must capture sustainability indicators and track-and-trace data on product origin, material composition, repair and disassembly possibilities, and end-of-life options [20,21,24,32,56,60,61,64–67,76], providing the information needed to implement R-strategies and lowering barriers to repair, reuse, and recycling [57,63] (I2, I5). DPP data must also include the information required to automate sustainability calculations through lifecycle assessments (LCAs) [62]. To remain useful throughout the entire product lifecycle, this data should be available in real time and over extended periods, continuously supporting circular processes [6,68]. It should also be updatable so that the information remains accurate and actionable (I7). According to expert I1, the granularity and the type of information provided should also be differentiated by actor role. This actor-specific granularity is particularly important for repair because future products should include the necessary repair and maintenance information to facilitate easier and more cost-effective repairs [13].

Technological Requirements

Baker (2011) [81] defines the technological dimension as encompassing “[…] includes all the technologies that are relevant to the firm, both technologies that are already in use at the firm as well as those that are available in the marketplace but not currently in use.” For the DPP, this pertains to which existing systems firms can extend and which new technologies they must adopt. Tables 8 and 9 list the sources for these requirements.

Usability

DPPs should be attractive and easy to use for all stakeholders, including end consumers, to avoid being perceived as a burden (I6, I7) [6]. Duarte et al. (2025) [60] attribute low acceptance to limited access, a perceived lack of need, and mistrust. Therefore, consumers require low-threshold interfaces that allow them to interpret information at the point of purchase. Since purely digital access is planned for the DPP, target groups must have the necessary devices to identify data carriers, such as QR codes, on the products [21]. Beyond ease of use for human actors, DPP systems must also fulfill explicit requirements for longevity, machine readability, and searchability, enabling diverse stakeholders to process data automatically [33].

Access Management

Access rights in a DPP must be differentiated by actor role, ensuring that not every actor can view all data [4,6,21,74,73] (I7). The “need-to-know” principle ensures that actors receive only the information relevant to their function [73]. In line with the CIRPASS definition, a DPP can be understood as a collection of product data linked to a unique identifier and governed by agreed rules on data sovereignty and access rights [20,70], which protect intellectual property rights [4]. Operationally, a DPP must implement a tiered access model [63]. In addition to reading, data input and modification should also be subject to access control [4,74], defining which actors may access or change specific data points (I9). Technically, DPP access management must integrate data security, authentication, and data minimization, with access governed by usage agreements and role-specific permissions [33] (I1, I7). Regardless of the technical design, effective access management requires that actors to be willing to share their product information with others [13] (I2, I5), with exceptions applying only to market surveillance authorities, for example, when identifying non-compliant products [4,74].

The normative framework covers this area less comprehensively than others. EN 18221 mandates that archived passport versions be retrievable only by authenticated and authorized actors, with the same access restrictions applying to the corresponding attributes of the current passport. It refers to EN 18246 for their integrity and originality [43]. The two standards specifying mechanisms for access rights management, information system security, and business confidentiality [46], as well as data authentication, reliability, and integrity [47], were still drafts as of September 2026 and are not among the standards cited in the Official Journal [14]. Consequently, the horizontal framework states the access requirement normatively while leaving its realization to standards that do not yet carry a presumption of conformity.

Development

While the horizontal standards are now in place, product-specific requirements are not, and the academic debate remains at an early stage with many open questions [16,20,24]. DPP solutions should therefore adopt a modular, adaptable design that can be realigned with forthcoming specifications (I6). To minimize unnecessary effort, development should build on existing enterprise systems rather than create new infrastructure from scratch. Existing supply chain systems (I6, I7), data management structures with ontologies and data clusters (I1), and compliance and sustainability tools (I8) already address significant portions of DPP requirements and should be adapted and extended accordingly. Expert I2 adds that modular architectures help control costs, whereas bespoke new developments can be expensive. Manufacturers should also engage their supply chains and align expectations across actor groups to ensure that the DPP becomes part of a functioning industrial ecosystem [17].

DPP solutions should be based on common standards from the outset to avoid costly rework (I9) and should guard against isolated, partial implementations that cannot deliver the holistic product lifecycle view required [38]. DPP development must follow a systematic orchestration process encompassing regulatory analysis and system design [79]. Core quality requirements such as interoperability, security, accessibility, and traceability must be met within an EU-level governance framework [23]. A distributed approach, in which data ownership remains with the originating actor, is advocated to prevent excessive concentration of power (I7). Kebede et al. (2023) [34] identify further open development questions, including them the concrete content of DPPs, practical implementation models, data storage approaches, the balance between transparency and the trade-secret protection, customer involvement, and regulatory use.

Implementation

Regardless of the chosen technology, the ESPR defines overarching technical requirements, such as full interoperability, free and simple access for authorized actors, the option to store DPP data either at the manufacturer or at a DPP service provider, the possibility of linking multiple passports, and guarantees regarding authenticity, reliability, integrity, security, and data protection [4]. The two dominant implementation approaches are Blockchain and AAS (I6, I9). Any approach is valid as long as it ensures interoperability; however, several experts (I1, I2, I3, I4) and Plociennik et al. (2022) [25] favor AAS because it represents data in a standardized, machine-interpretable form. Conversely, Blockchain should be deprioritized because of energy and governance concerns, a preference not shared by the standards themselves [40,45]. Nine of the 15 commercial providers analyzed advertise Blockchain [55,91], indicating that technology choices should be assessed against interoperability, scalability, and data sovereignty rather than marketing considerations. The Knowledge Graph is highlighted for its ability to retrieve unstructured data quickly and efficiently [34] (I6), and such solutions should also be considered for DPP implementations [32]. Since the appropriate technology is inherently sector- and business-model-dependent (I4), DPP implementations should systematically evaluate these approaches and justify the chosen solution against identified requirements. According to Kim et al. (2023) [80], practitioners should utilize existing layered architectural models from the literature when defining technical requirements, allowing them to specify technical layers, required services, and integration points with enterprise IT landscapes. DPP implementations must adopt decentralized architectures supported by Data Spaces, integrate security, authentication, and access control as foundational components, and use ontologies and universal identifiers to achieve semantic interoperability [33]. Physical-digital linking mechanisms, including QR codes, near-field communication tags, and RFID, must connect digital records to physical products [66]. Automated data capture via Cyber-Physical Systems (CPS) must be supported across all lifecycle phases, with digital signatures and decentralized storage securing data integrity and traceability [23]. Implementations must further move from proprietary formats to standardized passport structures and support IoT-based mechanisms for updating lifecycle data [5]. Responsibilities for maintaining and updating DPP content must be clearly defined, covering product modifications, refurbishment, and component transfers, while questions of confidentiality and intellectual property protection must be resolved [61]. Expert I7 proposes a distributed approach in which each data owner retains control over their data, and the choice of implementation technology should align with the company's business model and the value proposition created by the DPP. Finally, encrypted communication between systems must be implemented to protect data privacy, and article-level DPP implementation should be carefully evaluated given the potentially disproportionate administrative and energy overhead it entails [73].

Data Management

DPP data management must cover, at a minimum, product and component information, design specifications, material composition (I5), environmental impacts, sustainability and lifecycle data, manufacturer details, and end-of-life management [63,72] (I4), as well as emission behavior, disassembly capability, reparability, energy efficiency, and dynamic usage data [20,61]. This range of data is needed to enable end-to-end traceability across the entire value chain, including the recording of resource consumption and pollutant emissions at each process step [64,67,69,71], so that the various R-strategies can be implemented in a more standardized way [57]. To avoid disproportionate data lakes, organizations should apply a principle of data economy.

Data requirements should be scoped precisely to what each actor actually needs (I2), and existing data should be reused wherever possible rather than collected anew (I4). Expert I8 notes that many organizations currently lack the necessary data points in their IT systems to fully populate a DPP. Companies should therefore identify and close these data gaps before implementation can yield meaningful results. Companies should also ensure that their data are up to date [73] and of high quality so that the DPP remain meaningful [13]. DPP data should be tailored to the actor group that accesses it, which means data formats should suit diverse use contexts [70] and the level of granularity should reflect the actors' digital maturity and implementation goals, ranging from model level to individual product level [33]. This actor-specific information can be made accessible via apps, websites, or augmented reality, for example [21]. A further cross-cutting requirement is interoperability [57] (I1, I4, I7), which presupposes a uniform data standard [16,34,56,68,76]. Clear semantics simplify both the provision of data [68] and the exchange of product data among companies, sectors, and information systems [16] (I3, I7).

DISCUSSION

This paper investigates the requirements for implementing the Digital Product Passport (DPP) in practice. Our triangulated analysis identifies 11 requirement categories structured along the technology, organization, and environment dimensions of the TOE framework and highlights three cross-cutting requirements: the long-term availability of DPP data, fine-grained access management, and the misalignment of industrial prototypes and technical standards that have since been harmonized. Before discussing the implications, we compare these requirements with the current normative framework and examine their distributed across our three data sources, as both factors shape how confidently each requirement can be interpreted.

Requirements in Light of the Normative Framework

Comparing the 76 requirements against the four levels introduced in the section on the Regulatory and Normative Framework shows that the framework covers 26 of them, partially addresses 19, and leaves 31 open. About one-third of what our sources demand is now specified normatively, while about two-fifths is not.

The distribution follows the scope of the standards. DPP-System and Implementation are the most extensively covered categories, which is expected because the EN 182xx series was written specifically for these questions. The two data categories have the least coverage on the content side because the delegated acts that determine which data a passport must carry are still pending for most product groups. Access Management stands apart: of its seven requirements, one is covered, two are partially covered, and four remain open. The one covered requirement concerns the exemption for market surveillance authorities, which follows directly from the ESPR rather than from any technical standard.

This gap is not merely an observation from our analysis. EN 18221 requires archived passport versions to be retrievable only by authenticated and authorized actors and refers to EN 18246 for their integrity and originality [43]. EN 18216 lists both EN 18239 and EN 18246 among its normative references [40]. Both are still drafts, and neither is cited in the Official Journal [14]. Thus, two of the six harmonized standards depend normatively on documents that carry no presumption of conformity. Our sources treat access management as a precondition for data sharing, and the framework leaves precisely this area unresolved.

Another observation concerns technology neutrality. The series does not prescribe a specific technology, and EN 18216 lists the AAS as one option among others in an explicitly non-exhaustive enumeration [40]. This leaves the preference of several experts and part of the literature for the AAS unfulfilled while simultaneously satisfying the requirement that the choice of technology remain dependent on sector and business model. This design decision produces both an open requirement and a covered one, suggesting that technology neutrality is not a neutral choice for implementers: it shifts the burden of selecting and justifying a technology to the organization.

A further observation is a divergence rather than a gap. Our sources call for sectoral data standards with harmonized vocabularies, whereas EN 18223 states the avoidance of sector-specific ontologies is an objective and instead enables the parallel use of several ontologies through a layer that is independent of technology, ontology, and domain [45]. Practice and standardization address the same concern in opposite directions. Whether the horizontal approach removes the need for sectoral vocabularies or merely relocates the problem to the implementation level remains an open question that our data cannot settle.

When read by requirement type, the results sharpen the theoretical argument developed below. Of the 12 organizational requirements, three are covered, two are partially covered, and seven remain open. The framework specifies what a passport must do but says little about what an organization must be able to do to produce one. At the same time, the open count should not be interpreted as a deficiency throughout: eight of the 76 requirements are managerial recommendations, and six of these are open because a standard is not the appropriate instrument to fulfill them.

Finally, the comparison shows movement in both directions. Long-term data availability was raised by our sources before the standards existed and is now specified in detail, including access after the responsible economic operator has left the market [43]. Conversely, EN 18221 introduces the role of the DPP backup service provider, an organizational solution that none of our sources proposed, although they had identified the underlying problem. The normative framework and practice are therefore not simply ahead of or behind one another; each has articulated something the other did not.

Distribution of Requirements across Sources

The triangulation in Tables 5–9 shows that the requirements are supported differently across the SLR, the secondary literature, and the expert interviews. Of the 76 requirements, 44 rest on a single stream, and only six are supported by all three. We interpret this distribution as a substantive finding and relate it to the normative status reported above. Four patterns stand out.

First, the support for individual categories is markedly asymmetric. As Table 5 shows, Data and Data Management are broadly triangulated across all three sources, whereas DPP-System, Development, and Usability receive no support from the secondary literature. At the time of data collection, this absence allowed for two interpretations. Either no robust secondary literature existed because the available reports concentrated on regulation, or these requirements were so close to implementation that practitioners articulated them only through direct exchange. The normative comparison adds a third perspective. The three categories without secondary support are now covered above average, with nine of their 21 requirements covered and 5 partially covered, compared with 26 and 19 of 76 overall. For these categories, the EN 182xx series has since supplied the written, implementation-oriented documentation that the grey literature lacked. The broadly triangulated data categories show the opposite picture: only 2 of their 14 requirements are covered because the delegated acts that define passport content are still pending for most product groups. Broad support across sources and normative coverage therefore do not coincide. For the implementation-oriented categories, the interviews closed an evidence gap that standardization has since narrowed; for the data categories, they document requirements that no provision specifies yet.

We interpret this clustering as an indication of the maturity of the respective discourse communities rather than a property of the requirements themselves. The normative comparison supports this reading: Terminologies, Regulatory, and Standardization have 13 of their 19 requirements at least partially addressed. In contrast, Access Management exhibits a different pattern. All seven of its requirements are supported in the literature, and the interviews confirm four of them; however, the framework addresses only three at least partially.

Third, several requirements rely on only a single source, and the three forms of support must be interpreted differently. Their normative status also varies by stream. Of the 22 requirements supported solely by interviews, ten remain open, whereas four of the five supported only by secondary literature are covered. For example, where a requirement is backed only by one or a few experts, such as the 80% rule raised by I9 or the AAS-based Digital Twin Registry approach, this may reflect the small sample of nine experts. It remains uncertain whether a larger sample would have confirmed, qualified, or supplemented such statements. Therefore, these points should be viewed as preliminary indications rather than established requirements. Where a requirement is supported only by the SLR, such as the call for a systematic orchestration process in Development or for low-threshold, value-adding interfaces in Usability, this may indicate a purely academic requirement not yet effective in practice or an aspect that practitioners already take for granted. Requirements carried solely by secondary literature, such as the shared framework for voluntary additional product information in Standardization or the explicit exceptions for market surveillance authorities in Access Management, often point to regulation-driven or vendor-driven topics that have not yet entered the scientific discourse. Collectively, this one-sidedness is to be expected in a field this nascent and is itself a finding about the maturity of the DPP discourse rather than primarily a weakness of the individual requirements.

Fourth, the interviews did not generate a category beyond the 11 derived from the literature. This suggests a degree of completeness at the category level; however, with only nine experts, it does not imply completeness at the level of individual requirements. A larger or more diverse sample could likely surface additional or competing requirements within the existing categories. We therefore regard the category framework as relatively stable while considering the inventory of requirements within it as open.

Practical Implications

For practitioners, the results translate into a several interconnected lines of action. Regarding regulation and standardization, companies need to align with the ESPR specifications and the harmonized standards instead of developing isolated, proprietary DPP solutions. Our analysis of existing providers reveals that many current offerings resemble front-end prototypes loosely coupled to the ESPR requirements and sectoral data models. With the horizontal standards now binding through the presumption of conformity, the risk of lock-in and costly rework is no longer prospective but immediate. In line with Piétron et al. (2023) [16], who argue that standardization should be coordinated by governments or neutral organizations, our results support a governance model in which neutral bodies coordinate DPP standardization while companies participate through industry consortia. The category Terminologies adds a further condition: regulators, standardization bodies, and industry must converge on a coherent terminology for DPPs and related passports, such as BPs and MPs, to prevent the emergence of parallel, incompatible implementations.

Aligning with external standards is only half the task, as the data within the passport raises its own demands. The long-term availability and semantic consistency of DPP data extend beyond the often-cited call for transparency: companies must ensure that relevant information remains accessible and interpretable over extended periods, including after the end of the physical product life. From the perspectives of Data and Data Management, this concerns not only which attributes are stored but also how companies reuse existing enterprise data instead of creating redundant silos, which is essential for operationalizing the data economy. As the interviews indicate, this is as much an organizational challenge as a technical one, as companies need employees capable of interpreting complex lifecycle data; without them, the DPP risks being reduced to a mere compliance instrument.

This organizational aspect deserves as much attention as the technical one. Practitioners must navigate a framework that is settled at the horizontal level but not at the product-specific level. Our study shows that current pilots often focus on user interfaces and basic traceability while interoperable Data Spaces and access management remain insufficiently addressed, reflecting the categories of Development, Implementation, and DPP-System. Used as a checklist, the practical implications derived from our categories can help identify such gaps in ongoing DPP initiatives early and align them with the harmonized standards, the product-specific acts still to come, and emerging Data Spaces.

Academic Implications

Beyond guiding practitioners, this study advances the academic discourse on DPPs. By triangulating expert interviews, an SLR, and secondary literature, we develop a TOE-based framework of 11 requirement categories that consolidates previously fragmented insights and extends prior work focused on individual technologies or sector-specific case studies.

The robustness of this framework must be qualified in light of its evidence base. On the literature side, the second screening iteration reduced the relevant papers from 64 to 31, and the restriction to peer-reviewed publications in English and German, along with the open-access limitation in Scopus, may have excluded relevant work. The EN 182xx standards emerged afterward and entered the study only through the normative comparison. The grey literature was retrieved through Google searches, whose results depend on time and search history and cannot be fully reproduced. On the interview side, experts were selected based on their stakeholder roles and participation in DPP research projects. This provides depth but introduces a selection bias: experts involved in DPP projects may emphasize requirements already on the project agenda, while barriers faced by companies without such involvement may be underrepresented. All nine interviewees work in Europe, so the requirements reflect the EU regulatory context and cannot be transferred to other jurisdictions without further study. The interviews were also not designed to compare sectors and included too few experts per sector for such a comparison. Thus, the requirements are cross-sectoral, and sector-specific differences remain outside the scope of this study. With nine experts, four of whom are from industry, the interviews indicate which requirements occur in practice but not how widespread they are, and differences between researchers and industry experts can only be interpreted as tendencies. The codebook supported consistent application of the codes across transcripts, but there was no second coding pass, no review of the coding by co-authors, or member check with the experts. Intercoder reliability therefore could not be assessed, and individual coding decisions may reflect the coder’s interpretation. This primarily affects the 22 requirements supported only by interviews. Requirements also supported by the literature do not rely solely on the coding.

Within these limits, the framework still yields substantive contributions. Our results empirically highlight three cross-cutting requirements that have received limited attention in the DPP literature thus far: the long-term availability of DPP data, fine-grained access management, and the misalignment of industrial prototypes with the technical standards that have since been harmonized. These findings refine the research agenda for future DPP studies.

The comparison in Section Requirements in Light of the Normative Framework separates these three. Long-term availability is now specified normatively, confirming the concerns raised by our sources rather than diminishing them. Alignment with standards is no longer an open target at the horizontal level, where specifications now exist, but it remains open for the product-specific acts, and the misalignment of existing prototypes has become more consequential rather than less. Access management is the one area that has become sharper rather than weaker, as four of its seven requirements remain open and the standards that would specify it are still drafts.

The triangulation also points to differences between academic and practitioner views, which we interpret as tendencies given the four industry experts in our sample. Terminologies, Regulatory, and Standardization are shaped by the academic and regulatory debate, whereas Development, Implementation, DPP-System, and concrete Application Fields are problematized mainly by industry experts.

Viewed through the TOE framework, these differences refine the framework itself. The organizational dimension encompasses what the normative framework leaves open: regulation and standards address 29 of the 37 technical requirements at least partially, but only 5 of the 12 organizational ones. Baker (2011) [81] describes this dimension through the characteristics and resources of a firm, whereas DPP implementation translates it into a set of tasks, from governing access for actors outside the firm to mobilizing suppliers and building the competencies to interpret lifecycle data. The boundary with the technological dimension also blurs. Only one of the 18 requirements we assign to the organizational dimension is organizational by type, while the others are technical requirements through which an organizational demand takes effect, such as role-differentiated access rights for decisions about access governance.

The environmental dimension, in turn, provides design specifications rather than only conditions for an adoption decision, as the ESPR, the harmonized standards, and the registry implementing regulation prescribe concrete system properties down to data carriers and access rights. The unit of analysis shifts accordingly. Baker’s definition refers to intra-firm communication processes, whereas requirements such as supply chain mobilization or the willingness to share data apply between organizations. Future theoretical work could specify the organizational dimension of TOE for regulated, cross-organizational infrastructures and test whether these refinements also hold for other regulatory data-sharing obligations.

Future work should also examine how DPP architectures and governance models can keep data durable, semantically stable, and adaptable over the multi-decade lifetimes of many products, drawing on knowledge graphs and ontologies for heterogeneous lifecycle data, utilizing decentralized identifiers (DIDs) for cross-organizational traceability, and integrating DPPs into interoperable Data Spaces. From a technical perspective, comparative evaluations of blockchain-based, AAS-centric, and knowledge-graph-based approaches are necessary to understand their strengths in scalability, interoperability, efficiency, and alignment with ESPR requirements.

CONCLUSIONS, LIMITATIONS, AND OUTLOOK

This paper identified practical requirements for implementing DPPs and examined their implications. We combined nine semi-structured interviews with experts from industry and research, a SLR that identified 31 relevant papers, and a multivocal literature review of secondary data, including reports and websites of research projects and solution providers. The main contribution is an empirical exploration of the practical requirements that DPPs must meet for successful implementation. By bridging the gap between theory and practice, the findings extend the body of knowledge across eleven requirement categories: Terminologies, Regulatory, Data Management, Standardization, Data, Application Fields, DPP-System, Access Management, Development, Implementation, and Usability, comprising 76 requirements. Comparing these requirements with the current regulatory and standardization framework reveals that 31 of them are not yet addressed, particularly in access management and the two data categories, where product-specific acts are still pending. These findings illustrate how feasible DPP implementations can operationalize circular economy (CE) principles through the 9R strategies by providing reliable, long-term product data throughout the lifecycle.

These findings come with limitations, which the discussion examined alongside with the requirements they affect. In summary, the results are based on a qualitative design, meaning that interpretation and coding may have influenced findings, which were not externally validated. The interview sample is small and consists of experts involved in DPP projects, so although the requirements reflect practical occurrences, they do not indicate how widespread these practices are, and differences between groups can be interpreted only as tendencies. Both the sample and the regulatory frame of reference are strongly European, which may limit the transferability of our findings to non-European contexts. Finally, DPPs are evolving rapidly, so some statements may already have been overtaken by subsequent development.

Two avenues for future research emerge from these limitations. The stability of the 11 categories should be tested with larger, non-European samples that include companies without DPP project experience to examine whether a broader evidence base refines the inventory of requirements. Sector-specific studies are a second step, becoming feasible once the delegated acts for priority product groups are in force, because only then will a sector-specific reference exist. The technical questions of data durability, Data Spaces, and access management are outlined in the academic implications.

Conceptual and practical progress on DPPs has been considerable; however, despite the short implementation timelines established by the EU, the DPP is still far from full implementation and widespread acceptance in practice. By highlighting the requirements that matter during implementation, this paper provides stakeholders such as managers and engineers with a clearer basis for advancing DPP adoption within their organizations and supporting the transition toward a more sustainable circular economy.

DATA AVAILABILITY

All data generated from the study are available in the manuscript.

AUTHOR CONTRIBUTIONS

SB: Conceptualization, Methodology, Investigation, Formal Analysis, Data Curation, Visualization, Project Administration, Validation, Writing–Original Draft Preparation, Writing–Review & Editing; CH-L: Conceptualization, Methodology, Writing–Original Draft Preparation, Writing–Review & Editing; JS: Writing–Original Draft Preparation, Writing–Review & Editing; JJ: Conceptualization, Methodology, Supervision, Validation, Writing–Review & Editing.

CONFLICTS OF INTEREST

The authors declare that they have no conflicts of interest.

FUNDING

This research was partially funded by the European Union’s Horizon Europe research and innovation programme under grant agreement No. 101094287 (Bioindustry 4.0). Views and opinions expressed are those of the authors only and do not necessarily reflect those of the European Union or the granting authority. Neither the European Union nor the granting authority can be held responsible for them.