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 operating requirements for interoperability, access, update restrictions, authentication, reliability, integrity, security, privacy and fraud prevention. Implementing Decision (EU) 2026/1736 now publishes harmonised standards for data exchange protocols, unique identifiers, data carriers, storage and persistence, lifecycle APIs and system interoperability. Applying a listed standard creates a presumption only for the Article 10 and 11 requirements it covers.

ESPR Article 13 requires a Commission-managed registry. Implementing Regulation (EU) 2026/1778 was published on 17 July 2026 and enters into force on 6 August 2026. It specifies access management, actor verification, secure user-interface and API registration routes, storage of identifiers and commodity codes, passport granularity, logs and authority access. A verified economic operator registers the passport at the model, batch or item level selected by the applicable product rule.

Article 14 adds a public web portal, and Article 15 connects the registry to customs controls. Registry submission includes automated checks such as semantic conformity against the applicable rules, but registry communication is not proof that the product complies with all substantive requirements.

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 and CWA 18186 remain useful design history, but the July 2026 harmonised-standard references now control any claimed presumption of conformity for the Article 10 and 11 requirements they cover. Use project material for architecture options, the listed EN standards for the covered horizontal requirements, the registry regulation for registration mechanics, and the product delegated act for data content and access decisions.

Current source material now supports the framework connection, six harmonised DPP standards and detailed registry arrangements. It still does not support a universal final DPP field set across all ESPR products, a generic product start date or a fixed EU penalty table.

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.