Artifact GuideEU

EU Digital Product Passport (DPP) Architecture & Integration

A reference architecture for building DPPs that are interoperable, secure, and audit-ready.

Designed to meet ESPR requirements: open standards, no vendor lock-in, access rights, registry readiness, and customs workflows.

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

DPP is an information system with legal constraints. ESPR requires persistent identifiers, physical data carriers, open standards and interoperable formats, differentiated access rights, security and integrity, and EU registry/portal/customs infrastructure. This page turns those requirements into architecture patterns you can implement without painting yourself into a vendor lock-in corner.

Section 1

Architecture principle 1: product-centric identity (the DPP starts with the identifier)

ESPR requires a persistent unique product identifier connected through a data carrier. Architecturally, the identifier is the stable key that binds physical items/models to digital data across lifecycle updates.

Design your DPP around resolution: scanning a carrier should reliably resolve to the correct DPP view (public or restricted) for the correct level (model/batch/item).

Define identifier scheme(s): unique product identifier + (where relevant) GTIN/commodity codes and operator identifiers referenced in Annex III.
Build a resolver service: stable URLs/URIs that map identifier -> DPP view -> access-controlled data.
Support version linking: if a new DPP is created, it must link to prior DPP(s) (Article 11).

Section 2

Architecture principle 2: open standards and no vendor lock-in (Article 10)

Article 10 is explicit: DPP data should be based on open standards, developed with interoperable format, and be machine-readable/structured/searchable/transferable through an open interoperable data exchange network without vendor lock-in.

This requirement should drive vendor selection and data modeling choices.

Choose interoperable formats: structured data (not only PDFs) for core fields; publish stable schemas and versioning.
Exportability: ensure you can export DPP data and history without proprietary tooling; test migration paths early.
API-first: design DPP as an API-backed dataset with multiple renderers (consumer UI, B2B view, authority view).

Section 3

Architecture principle 3: differentiated access rights (public vs restricted views)

Delegated acts specify which actors have access to what data and who may update which fields. Your architecture must enforce this with least privilege and audit logs.

Article 11 requires free and easy access based on access rights, and restriction of modification rights accordingly.

Public view: accessible without unnecessary friction (avoid forced apps and personal data collection for public fields).
Restricted view: strong authentication, role-based field access, and comprehensive audit logging for reads and writes.
Update workflow: validate and version changes; tie updates to actors and evidence; enforce data quality SLAs (accurate, complete, up to date).

Section 4

Architecture principle 4: security, integrity and trust (Article 11 + CWA guidance)

Article 11 requires authentication, reliability and integrity of data, high security and privacy, and fraud avoidance. CWA guidance discusses practical security and trust mechanisms (encryption, signatures, governance).

Treat DPP as a high-value target: it can be used for compliance verification and customs checks.

Integrity controls: signatures/hashes for key records; tamper detection; immutable audit trail for critical updates.
Privacy: do not store customer personal data without explicit consent; isolate sensitive data and encrypt at rest/in transit.
Carrier security: consider authentication for data carriers in high-risk contexts (anti-counterfeit, high-value goods).

Section 5

Registry + portal integration (Articles 13-15): build for the EU dependency chain

ESPR requires an EU registry (by 19 July 2026) that stores at least unique identifiers and issues a unique registration identifier after upload. A web portal enables search/compare consistent with access rights. Customs controls use the registration identifier once operational.

Architect these as integrations with explicit operational SLAs and failure modes.

Registry upload pipeline: unique identifiers and any delegated-act required registry fields; store the returned unique registration identifier and link it to the DPP identifier.
Portal readiness: ensure public fields are searchable/compareable; ensure restricted fields are only accessible within rights.
Customs workflow: be able to provide the unique registration identifier for release for free circulation when required; support automated verification.

Section 6

Integration blueprint: source systems -> canonical DPP layer -> views

DPP data lives across multiple systems. The robust pattern is: authoritative sources feed a canonical DPP layer, which powers different views and exports.

This minimizes duplication while preserving provenance and auditability.

Sources: PLM/PIM (specs, model data), ERP/SCM (batch/commodity, importer info), compliance repositories (DoC/technical docs), labeling systems (carrier generation), service/repair tools (where applicable).
Canonical DPP layer: normalized schema aligned to Annex III + delegated-act extensions; provenance metadata; versioning; access control.
Views: consumer UX (public), business partner portal (restricted), authority view (restricted), machine-readable API exports.

Section 7

Implementation checklist: architecture decisions you must lock early

Most DPP rework comes from late decisions on granularity, identifiers and access rights. Lock these early and prototype end-to-end.

Use this checklist to de-risk before large rollout.

Granularity: model vs batch vs item; ensure identifiers and carrier printing can support it.
Identifier and resolver design: stable, persistent, and version-linkable; test scanning across environments.
Access model: actor types, public/restricted fields, authentication, and audit logging.
Export and migration: prove no vendor lock-in with data export and schema evolution plan.
Registry readiness: map what you upload, what you store, and how customs and market surveillance flows are supported.

Recommended next step

Operationalize EU Digital Product Passport (DPP) Architecture & Integration across ESG workflows

ESG Compliance can take EU Digital Product Passport (DPP) Architecture & Integration from operationalizing this sustainability obligation across workflows and reporting 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) Architecture & Integration

Start from EU Digital Product Passport (DPP) Architecture & Integration 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) Architecture & Integration.

Explore next step

Primary sources

References and citations

CEN-CENELEC CWA 18186:2025 - DPP designer guidance (portal, searchability, security/trust)

cencenelec.eu

Referenced sections

Implementation guidance for DPP portal setup, searchability (API patterns), data longevity/availability, access control and security/trust mechanisms.

CIRPASS DPP System Architecture (D3.2, March 2024)

doi.org

Referenced sections

Reference architecture patterns: product-centric identifiers, decentralised approaches, and interoperability principles.

GS1 - Digital Product Passport (standards landscape)

gs1.org

Referenced sections

Identifier and data standards context useful for interoperable DPP implementations.

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

eur-lex.europa.eu

Referenced sections

Architecture drivers: Article 10 (open standards, no vendor lock-in), Article 11 (interoperability, access rights, security), Article 13 (registry), Articles 14-15 (portal and customs), Annex III (identifiers and data).

Related guides