The Digital Product Passport market is still at an early stage. Regulation is developing, technical standards are evolving, and technology providers are competing to establish their platforms as part of the infrastructure companies will eventually rely on.
Until now, much of what buyers have seen has come from individual suppliers. Each provider presents its own architecture, terminology and interpretation of what a Digital Product Passport should contain and how it should operate. For companies preparing for future DPP requirements, that can make comparison difficult. Similar claims about interoperability, standards, flexibility and compliance may describe very different technical approaches.
CIRPASS-2 has now added another source of visibility through the launch of the OpenDPP Catalogue, a central collection of open-source Digital Product Passport projects, tools and frameworks.
The catalogue is designed to help developers, researchers, technology providers and other stakeholders discover and compare open-source work taking place across the DPP ecosystem. For buyers, however, its significance goes beyond software discovery. Open implementations can provide useful reference points for understanding what DPP infrastructure actually looks like beneath the commercial descriptions.
Greater visibility into the technology
Enterprise technology is frequently sold using terms such as interoperable, standards-based, flexible, open and future-proof. These descriptions can be meaningful, but they can also be difficult for a buyer to evaluate without access to the underlying architecture.
Open-source projects offer a different level of visibility. Depending on the project, it may be possible to examine how product information is structured, which standards are being implemented, how identifiers are handled, how systems communicate and what assumptions have been made about data exchange.
That does not mean that an open-source project is automatically better than a commercial platform. Commercial providers may offer stronger support, security, governance, integration, scalability and operational responsibility. The value of open source in this context is that it provides another point of comparison.
As the DPP market develops, buyers should increasingly be able to compare supplier claims not only with competing commercial offerings, but also with publicly inspectable implementations of similar technologies.
Vendor dependency will become a procurement issue
One of the most important questions in DPP procurement is likely to be what happens after implementation.
A Digital Product Passport may need to remain associated with a product for many years. Depending on the product category, information may continue to be relevant long after the original technology contract has ended. This creates a different risk profile from ordinary software subscriptions.
Companies therefore need to understand whether their DPP data can be moved to another provider, whether another system can interpret it, and whether important parts of the infrastructure depend on proprietary formats or services controlled by a single supplier.
This becomes particularly important if a provider changes its pricing, leaves the market, is acquired, changes its technical direction or no longer supports the customer's requirements.
Open-source DPP infrastructure does not eliminate these risks, but it can make some forms of dependency easier to identify. If common schemas, interfaces or components become openly available and widely adopted, buyers may have more realistic alternatives to replacing an entire DPP environment when one component changes.
That could make portability and exit planning much more important parts of future DPP procurement.
Open source should not be confused with compliance
There is also an important limitation.
Inclusion in an open-source catalogue does not mean that a project has been verified as compliant with Digital Product Passport legislation, technical standards or the requirements applying to a particular product category.
CIRPASS-2 itself makes this distinction clear.
For buyers, this matters because the word "open" can easily be interpreted as a quality signal that extends beyond what has actually been demonstrated. Source-code availability provides transparency about parts of the technology. It does not automatically establish regulatory compliance, cybersecurity, operational reliability, governance, scalability or long-term maintenance.
A company evaluating any DPP solution, whether commercial or open source, still needs to determine which legal requirements apply to its products, which standards the system supports, how access rights are controlled, how sensitive information is protected, how data quality is maintained and how the solution will operate over the required lifetime.
The practical procurement question is therefore not simply whether a provider can create something called a Digital Product Passport. It is whether the proposed system can support the company's actual regulatory, operational and commercial requirements over time.
Interoperability remains the larger issue
The most significant aspect of open DPP infrastructure may ultimately be its contribution to interoperability.
Digital Product Passports are not intended to operate as isolated product pages owned by individual technology companies. Their usefulness depends on information being available to different participants across a product's value chain and lifecycle.
Manufacturers may create or maintain the passport. Suppliers may provide data. Marketplaces may need to access certain information. Regulators may inspect it. Repairers, recyclers and other downstream actors may rely on parts of the same dataset. Consumers may be given access to another subset.
For that system to work at scale, information needs to remain understandable across organisational and technical boundaries.
This is why interoperability is more than a technical feature. It affects competition, supplier choice, operational resilience and the ability of companies to change technology without rebuilding their entire DPP environment.
Open-source implementations can contribute to that development by making schemas, interfaces and technical approaches visible. They can also provide practical environments in which emerging standards are implemented and tested rather than discussed only at specification level.
The existence of open components does not guarantee interoperability, but it can make claims about interoperability easier to examine.
What buyers should ask suppliers
As the market matures, DPP procurement should move beyond demonstrations of QR codes, product pages and dashboards.
Companies should understand how the underlying system handles their information and how much control they retain over it.
A supplier should be able to explain what data can be exported, which formats are used, which standards are supported and which elements of the architecture are proprietary. Buyers should also understand whether another system could interpret their data, whether identifiers remain usable after leaving the provider and what happens to existing passports if the commercial relationship ends.
Questions about access control, verification, data provenance, integrations and lifecycle management should form part of the same discussion.
These may appear to be technical questions, but their consequences are commercial. They determine how dependent a company becomes on one provider and how expensive it may be to change direction later.
A sign of a maturing DPP ecosystem
The development of open-source DPP infrastructure is one indication that the market is moving beyond its earliest stage.
Initial DPP activity focused heavily on demonstrating that passports could be created. The market is now beginning to confront more difficult questions around standards, interoperability, governance, infrastructure and long-term operation.
The OpenDPP Catalogue will not answer those questions by itself, and it should not be treated as a list of approved or compliant solutions. Its importance is that it makes more of the technical ecosystem visible.
For companies preparing to procure Digital Product Passport technology, that visibility is useful. It provides additional material against which supplier claims can be evaluated and may help buyers ask better questions before committing to platforms that could remain part of their product infrastructure for many years.
As DPP requirements move closer to implementation, the distinction between a system that can demonstrate a passport and infrastructure that a company can safely depend on will become increasingly important.
Open-source development may help make that distinction easier to see.