The EU has already built a reference architecture for the passport

While companies wait for delegated acts, EU-funded work has been building and testing what a digital product passport (DPP) system should look like. CIRPASS-2 published a reference architecture, version 1.1, in June 2026, and the pilots run across the same categories that face binding rules first: textiles, electronics, construction and tyres.

This is worth knowing about even though none of it is law.

What a reference architecture is, and is not

It is a description of the building blocks a passport system needs, the roles the different actors play, and a set of recommendations about how they should interact. It maps those against the ESPR requirements.

It is not binding. Nothing in it obliges anyone, and a system that diverges from it is not non-compliant.

What it is, in practice, is the most detailed public statement of what "good" looks like from the part of the ecosystem that will influence the standards. When interoperability is eventually judged, this is the vocabulary it will be judged in.

Why it matters commercially rather than technically

The risk boardrooms miss with passports is not failing an audit. It is choosing a system that cannot exchange data with the systems your customers and suppliers choose.

A passport that only resolves inside one vendor's platform works fine until a customer's procurement system wants to read it automatically, a marketplace wants to surface it, or a recycler wants to query it a decade later. At that point a closed system stops being a product decision and becomes something your supply chain has to work around.

The reference architecture exists precisely to prevent that outcome, which is why aligning with it is a hedge rather than a compliance exercise.

What to ask a vendor about it

Three questions that do not require you to read a 97 page document.

Are you familiar with the CIRPASS-2 reference architecture, and where do you diverge from it? The useful answer names a divergence and explains it. A vendor claiming full alignment with a document that is still a draft recommendation is overstating.

Which of the pilot categories have you looked at? The pilots are public and they surface real integration problems, particularly around supplier data exchange.

How do you handle updates submitted by third parties? Suppliers and repairers submitting data into someone else's passport is where the architecture gets specific, and where implementations differ most.

The gap worth noting

One observation about the architecture's scope rather than a criticism of it: there is no building block for consumer-facing authenticity verification, and counterfeiting is not treated as a use case. The scan is modelled as a way to reach data, not as a way to check that a product is genuine.

That gap is where our own consumer app sits, and it is the reason we treat authenticity and the passport as one code rather than two systems. It is an observation about what the reference model covers, not evidence that nobody else addresses it.

Sources

• CIRPASS-2, *D4.1 Reference Architecture*, version 1.1, 9 June 2026, including the DPP service
• provider building blocks and the architectural recommendations.