ESPR and Digital Product Passport connection guide

ESPR Article 9 says information requirements shall provide that products can only be placed on the market or put into service if a Digital Product Passport is available in accordance with the applicable delegated acts and the passport requirements in Articles 10 and 11. That makes the product-group delegated act the document that turns the framework rule into a concrete DPP obligation.

The same article lists what the delegated act should specify for the product group: the DPP data, one or more data carriers, carrier layout and positioning, whether the passport is at model, batch, or item level, pre-contract access including distance selling, which actors may access which data, which actors may create or update data, how updates work, and how long the passport remains available.

ESPR Article 10 requires the DPP to be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, its packaging, or accompanying documentation as the delegated act specifies, and DPP data must use open standards, interoperable formats, and machine-readable, structured, searchable, transferable data where appropriate.

Article 11 adds the operating requirements: DPPs must be interoperable with other DPPs required by ESPR delegated acts, access must be free of charge and easy for listed actor groups according to their access rights, data update rights must be restricted, and authentication, reliability, integrity, security, privacy, and fraud prevention must be addressed.

ESPR Article 13 requires a Commission-managed digital registry that stores at least unique identifiers, and commodity codes for products intended for release for free circulation. The economic operator placing the product on the market or putting it into service uploads the required registry data, and the registry returns a unique registration identifier. That communication is not proof of compliance.

Article 14 adds a public web portal for searching and comparing DPP data consistently with access rights. Article 15 connects the registry to customs controls: for covered products under release for free circulation, customs authorities verify at least the unique registration identifier and commodity code against registry data once the relevant systems are operational.

The ESPR DPP depends on product and value-chain data that may sit with manufacturers, importers, suppliers, repairers, refurbishers, recyclers, service providers, and authorities. The architecture question is not only where to host a page; it is how product identifiers resolve to DPP data, how restricted actors authenticate, how updates are made, and how a backup copy remains available if the original operator or service provider fails.

CIRPASS architecture material describes DPP system architecture around the product identifier and compares HTTP URI and decentralized identifier approaches. Its validation notes that creation, read, update, and deletion flows can be represented, while backup/archive and some access-right details need careful implementation choices. That is useful architecture grounding, but it is not a binding ESPR delegated act.

Current source material supports the framework connection, the essential DPP requirements, and architecture considerations. It does not support a universal final DPP field set across all ESPR products, a generic date for every product obligation, or a fixed penalty table for DPP failures.

The safe planning position is to prepare systems around the stable horizontal requirements: delegated-act intake, product identifier governance, carrier placement options, access-right design, service-provider and backup responsibilities, supplier data collection, and interoperability. Product-specific obligations should be added only when the relevant delegated act or other applicable Union law defines them.