CIRPASS-2 Reference Architecture v1.1
A plain-English summary of the EU's clearest blueprint to date for Digital Product Passport systems — published 10 June 2026 — with a candid map of where SmartLinks meets the recommendations and where we don't (yet).
What CIRPASS-2 D4.1 v1.1 actually says
Published 10 June 2026 by the CIRPASS-2 consortium (TNO, CEA, GS1, Fraunhofer, Avery Dennison, Kezzler, EON, Innovalia and many others). It's the closest thing to an official EU blueprint for how DPP systems should be built.
In one paragraph
DPPs should be served over plain HTTPS URLs reached from a QR/NFC data carrier. The EU Web Portal is the always-on resolver of last resort; in normal operation the rEO's redirection service (typically run by their DPP Service Provider) routes the user to the live DPP. Identity uses one credential per actor, trust comes from Verifiable Credentials, and the same DPP must serve consumers, regulators and recyclers in parallel.
Why this matters now
Delegated acts under the ESPR will reference this architecture as the reasonable default. CEN-CENELEC JTC 24 will turn the API surface into binding standards. If your DPP stack doesn't line up with these recommendations, you'll be retrofitting in 2027.
Headline shifts from CIRPASS-1 (2024)
CIRPASS-1 had a parallel DID-only architecture. v1.1 drops it — HTTP only, with DIDs as an optional advanced overlay.
Same identity for EU registry submission and for accessing restricted DPP data — less plumbing for everyone.
The old monolithic "rEO resolver" is broken into smaller pieces; the redirection service is the only piece rEOs must run.