Artifact GuideEU

EU Digital Product Passport (DPP) Data Carriers, Access Control & UX

Make DPP scanning and access journeys compliant, usable, and audit-ready.

Grounded in ESPR Articles 9-11 + CWA 18186 guidance: physical carriers, stable identifiers, differentiated access rights, and security/trust.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Mar 4, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Mar 4, 2026

Overview

The DPP's success depends on what happens in the first 10 seconds after scanning a code: does it resolve reliably, is the public information accessible before purchase, and are restricted fields protected by correct access rights? ESPR turns these UX questions into legal requirements (data carrier, identifier persistence, pre-purchase access, access rights, security and fraud prevention).

Section 1

Data carrier basics (Article 10): what must be true in the real world

A DPP must 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 specified by the applicable delegated act.

Carrier choice depends on environment and lifecycle: durability, abrasion, chemical exposure, heat, and end-of-life handling.
Carrier placement is a compliance requirement: delegated acts specify layout and positioning - build it into packaging and labeling workflows.
Plan for failures: damaged labels, offline environments, and secondary packaging loss should have fallback access paths.

Section 2

Identifier and resolution: build a DPP resolver you can trust

Scanning must reliably resolve to the correct DPP view (model/batch/item), and it must remain resolvable for the availability period defined by the delegated act (at least expected lifetime).

If DPP versions change, the new DPP must link to the original DPP(s).

Use stable, persistent identifiers; avoid embedding vendor-specific routing logic that breaks on migration.
Implement version linking and change history; ensure old identifiers still resolve to correct current information.
Support multi-channel access: scan -> URL; web search -> DPP; product page -> DPP (distance selling).

Section 3

Public vs restricted data: design differentiated access rights (Articles 9 and 11)

Delegated acts define who can access which fields and who can update which fields. Article 11 requires free and easy access based on those access rights and restriction of modification rights accordingly.

Architecturally, this means multiple views backed by a single canonical dataset with access control and audit logs.

Public view: optimized for consumers; no unnecessary authentication; avoid collecting personal data for public DPP access.
Restricted view: strong authentication, role-based field access, and audit logging for reads and writes.
Write access: enforce least privilege; validate updates; preserve provenance and version history; support dispute resolution and correction workflows.

Section 4

Pre-purchase access (including distance selling): don't bury DPP behind post-purchase flows

Delegated acts must specify how the DPP is made accessible to customers before they are bound by a contract, including in distance selling.

This is a UX + commerce integration requirement: your DPP needs a "consumer-ready" public view that is stable and accessible at the point of decision.

In-store: scanning a carrier should open the public view instantly; support accessibility and multilingual content where required.
Online marketplaces and dealers: they may need a digital copy of the carrier or unique identifier; build automated sharing and time-bound SLAs for requests.
No dark patterns: the DPP should support informed choice; ensure the "public view" includes required sustainability/compliance information.

Section 5

Security, privacy and anti-fraud design (Article 11 + CWA guidance)

Article 11 requires data authentication, reliability and integrity, a high level of security and privacy, and fraud avoidance.

CWA guidance highlights practical design choices: encryption for sensitive data, signatures for tamper detection, and identity mechanisms for controlled access.

Integrity: signed payloads or signed references for key fields (identifiers, compliance docs) + tamper-evident audit logs.
Privacy: do not store customers' personal data in DPP without explicit consent; isolate restricted data and encrypt at rest/in transit.
Carrier authentication: for high-risk categories, consider authenticated carriers (anti-counterfeit) and verified resolution endpoints.
Service providers: if DPP data is stored/processed by a service provider, the provider must not sell/reuse/process the data beyond what is necessary for the service unless specifically agreed.

Section 6

UX patterns that improve usability without breaking compliance

A DPP UI is a "multi-audience document": consumers, repairers, recyclers, authorities. Avoid trying to show everything to everyone in one screen.

Use progressive disclosure: public summary first, then role-based sections with clear labels and evidence links.

Public landing page: identity summary, sustainability highlights, safety warnings (where applicable), and "verify authenticity" indicators.
Role-based tabs/sections: repair, refurbish, recycle, compliance docs, authority-only fields (where allowed).
Searchability: provide stable URLs and machine-readable API endpoints for public data where appropriate (CWA guidance).

Recommended next step

Operationalize EU Digital Product Passport (DPP) Data Carriers, Access Control & UX across ESG workflows

ESG Compliance can take EU Digital Product Passport (DPP) Data Carriers, Access Control & UX from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

ESG workflow

Open ESG Compliance for EU Digital Product Passport (DPP) Data Carriers, Access Control & UX

Start from EU Digital Product Passport (DPP) Data Carriers, Access Control & UX and manage cross team sustainability work, reporting, and evidence from one workflow.

Explore next step

Talk to Sorena

Talk through EU Digital Product Passport (DPP)

Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Data Carriers, Access Control & UX.

Explore next step

Primary sources

References and citations

CEN-CENELEC CWA 18186:2025 - DPP portal access, searchability, and security/trust guidance

cencenelec.eu

Referenced sections

Practical UX and access guidance: public vs restricted access, information searchability, longevity/availability, security/trust and GDPR-aligned design.

European Commission - ESPR overview (DPP rationale and customs checks)

commission.europa.eu

Referenced sections

High-level DPP purpose: support informed decisions and enable customs/authorities to perform checks.

GS1 - Digital Product Passport (standards landscape)

gs1.org

Referenced sections

Identifier and carrier standards ecosystem useful for interoperable carrier/ID implementations.

Regulation (EU) 2024/1781 (ESPR) - Official Journal

eur-lex.europa.eu

Referenced sections

Data carrier + identifier requirements (Article 10), access rights and design/operation requirements (Articles 9 and 11), and availability requirements.

Related guides