A Digital Product Passport is a set of product-specific data made accessible electronically through a data carrier under the applicable rules. The ESPR establishes a framework; product-specific delegated acts determine whether a passport applies and what its detailed requirements are.
What the ESPR framework establishes
Regulation (EU) 2024/1781 creates the framework for setting ecodesign requirements for products placed on the EU market. Its Digital Product Passport provisions are implemented through applicable product-specific delegated acts rather than through one universal dataset for all products.
Under Article 9, those delegated acts may specify the data to include, the data carrier, its positioning, whether the passport operates at model, batch or item level, access rights, responsible actors, update arrangements and availability period.
- Do not assume every product currently needs a DPP.
- Do not assume every DPP uses the same data fields or access model.
- Do not assume a QR code by itself demonstrates compliance.
- Do prepare identifiers, structured data, evidence and accountable processes that can adapt to product-specific requirements.
The operational architecture behind a passport
Persistent identifiers
Controlled product, model, batch or item identifiers connect the correct records to the correct passport scope.
Structured information
Fields need definitions, formats, units, ownership, provenance and quality controls—not only human-readable documents.
Source relationships
Relevant declarations, certificates, test reports and supplier evidence need scope, status and version metadata.
Controlled public projection
Only approved data should become public; private or restricted evidence requires appropriate access controls.
Why maintenance matters
Passport information may need to remain accurate, complete and up to date. That requires ownership and change control for product versions, suppliers, evidence, access policies and applicable requirements—not a one-time publishing event.
- Record the source and owner of every published field.
- Publish immutable, versioned snapshots.
- Keep the public URL or resolver stable where the applicable architecture permits.
- Monitor changes, expired evidence and superseded information.
- Retain an auditable record of corrections and approvals.
Primary and authoritative sources
Source links are provided for verification. Scope, consolidated versions and later measures should be checked again before implementation or reliance.
Regulatory disclaimer. This content provides general diagnostic and preparation information. It is not legal advice, certification or regulatory approval. Requirements may differ by product category, jurisdiction, market and supply-chain role and may change over time.