EU Digital Product Passport Compliance

Start by confirming whether the product is covered by an ESPR delegated act that requires a digital product passport. The delegated act controls the product group, the data to include, the passport level, the applicable conformity assessment, and any product-specific information rules.

For covered products, the manufacturer must make a digital product passport available before placing the product on the market or putting it into service. Importers must check that the passport exists before placing covered products on the market. Treat the passport as part of the conformity system, not as a separate marketing asset.

The passport data model should be built from the delegated act and Annex III categories, not from a generic sustainability questionnaire. ESPR lists possible passport elements such as the unique product identifier, GTIN or equivalent identifier, commodity codes, compliance documentation, instructions, manufacturer and importer information, operator identifiers, facility identifiers, and the backup service provider reference.

The data carrier must resolve to the right passport record and remain usable through the product life cycle where possible. CEN-CENELEC guidance separates the design choices for product, operator, facility, and registry identifiers from the carrier and portal choices, which helps teams avoid hard-coding one QR destination before the data model and access model are stable.

Commission Implementing Decision (EU) 2026/1736, in force from 15 July 2026, cites six EN 182xx:2026 standards for data exchange, unique identifiers, data carriers, storage and persistence, lifecycle APIs, and system interoperability. Conformity with a cited standard provides a presumption of conformity for the ESPR Articles 10 and 11 requirements it covers. It does not replace the delegated act, conformity assessment, technical documentation, or product-specific field and access decisions.

A compliant DPP separates public information from restricted information. ESPR expects differentiated access by data type and stakeholder, while protecting confidential business information and personal data. Customers should be able to access public information without turning that access into unnecessary personal-data collection.

The Commission launched the EU DPP Registry and a separate testing environment on 20 July 2026. The Registry is an indexing service for unique identifiers, registration data, and high-level metadata, not the full passport repository. Economic operators can enrol an organisation and register or manage DPPs through the user interface or API; customs and market-surveillance uses remain subject to the applicable product legislation and access rules.

Most passport failures start upstream: supplier declarations, materials data, recycled content evidence, component identifiers, and facility information are accepted without validation rules. The DPP owner should run supplier data through the same control discipline as product master data and conformity documentation.

Governance should cover who may create, approve, update, restrict, or retire passport data. CEN-CENELEC guidance recommends considering versioning, timestamps, authentication, access rights, backup, and third-party verification options because the passport remains useful only if users can trust the data and detect changes or tampering.

A DPP evidence file should let a decision owner or authority trace each published field back to the rule, system, supplier record, calculation, approver, and publication event. Keep this evidence with the product's technical documentation rather than in a separate web-content workflow.

Do not add unsupported penalties, fixed thresholds, or launch dates to the passport plan unless the applicable delegated act or official implementation act supplies them. Where the regulation leaves details to future product-specific rules, mark the field as pending instead of filling it with a generic claim.