---
title: "EU Digital Product Passport architecture and integration"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration"
source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration"
author: "Sorena AI"
description: "Guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance."
published_at: "2026-05-09"
updated_at: "2026-07-25"
keywords:
  - "EU Digital Product Passport"
  - "DPP architecture"
  - "data carrier"
  - "unique product identifier"
  - "EU DPP registry"
  - "DPP web portal"
  - "customs controls"
  - "access rights"
  - "supplier data flow"
  - "Digital Product Passport"
  - "unique identifier"
  - "customs access"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EU Digital Product Passport architecture and integration

Guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.

*DPP* *Architecture* *EU*

## EU Digital Product Passport Architecture and Integration

Design the passport as a governed product data system, not just a QR code or public web page.

This page maps the architecture decisions for identifiers, data carriers, Registry and portal integration, access categories, supplier inputs, customs checks, and operating controls.

The EU Digital Product Passport under the Ecodesign for Sustainable Products Regulation is a product-linked information system. A usable architecture must connect the physical product to a unique identifier and data carrier, route users to passport data, apply access rights, register required identifiers for enforcement, keep supplier and lifecycle data current, and preserve evidence after the responsible operator or service provider changes.

## Definitions

### Digital Product Passport data carrier

**Term:** data carrier

A data carrier is a linear barcode, two-dimensional symbol, or other automatic identification medium that can be read by a device. For a covered Digital Product Passport, it connects the product to a persistent unique product identifier and must appear on the product, packaging, or accompanying documentation in the location specified by the applicable delegated act.

**Why it matters here:** The carrier starts the physical-to-digital lookup; it is not the complete passport or the access-control system. Choose its format, placement, durability, and resolver path only after the product rule fixes the passport level and access requirements.

Sources:

- [Regulation (EU) 2024/1781, Article 2(29) and Articles 9-10](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io)

## Start with the passport object and identifier level

The first architecture decision is the level at which the passport identifies the product. ESPR leaves the exact level to the delegated act for the relevant product group, so teams should not assume that every product will use the same model, batch, or item-level passport design.

The passport data model should reserve fields for the unique product identifier, Global Trade Identification Number or equivalent where relevant, commodity codes, compliance documentation, manuals or warnings, manufacturer and importer information, unique operator identifiers, unique facility identifiers, the responsible Union economic operator, and the backup service provider reference when those elements are required for the product group.

- Record the delegated-act product group and the required passport granularity before building carrier labels or APIs.
- Bind each passport to the unique product identifier and keep that identifier stable across resolver, registry, portal, and supplier systems.
- Model operator and facility identifiers separately from product identifiers so supplier, manufacturer, importer, and Union-responsible-operator data can be governed independently.
- Map customs-relevant data, including commodity code and unique registration identifier handling, outside the consumer-facing presentation layer.
- Keep voluntary sustainability claims separate from mandatory passport fields unless a delegated act or other Union law makes them required.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR Annex III lists the passport data elements that delegated acts may require, including unique product, operator, and facility identifiers, GTIN or equivalent, commodity codes, compliance documents, manuals, importer data, and the backup provider reference.
- [ETSI ES 204 082 information model for sustainability and circularity](https://www.etsi.org/deliver/etsi_es/204000_204099/204082/01.01.01_60/es_204082v010101p.pdf?ref=sorena.io) - ETSI ES 204 082 supports the page's data-model guidance by mapping product environmental information to claim data, criteria references, values, conformity, evidence, and URI-based references.

## Make the data carrier a resolver entry point, not the whole passport

The data carrier should give a scanner a reliable path from the physical product to a usable digital address. ESPR describes machine-readable data carriers such as QR codes or watermarks, preferably on the product where possible, and requires relevant identifiers and data carriers to follow recognised standards where applicable.

For implementation, the carrier should encode or resolve to a URI or equivalent identifier that can return typed links for the relevant user: public passport page, machine-readable data, conformity evidence, repair or recycling endpoints, backup access, and authority interfaces. CIRPASS describes both HTTP URI and decentralized identifier approaches; the common architectural point is that the carrier starts discovery while data can remain in decentralized repositories.

Since 15 July 2026, Commission Implementing Decision (EU) 2026/1736 has cited six harmonised standards for DPP data exchange, unique identifiers, data carriers, storage and persistence, lifecycle APIs, and system interoperability. Conformity with those standards gives a presumption of conformity for the ESPR Articles 10 and 11 requirements they cover. The applicable delegated act still controls product scope, passport level, selected data, carrier placement, access rights, and availability.

- Choose the carrier format only after checking product size, durability, lifecycle exposure, scanner context, and delegated-act placement rules.
- Use a resolver pattern so the same product identifier can point to human-readable pages, machine-readable data, evidence documents, and role-specific endpoints.
- Test the carrier on the product, packaging, online offer page, and service workflow if those channels need to expose the passport.
- Keep redirect ownership, domain renewal, resolver availability, and backup-provider activation in the operating model.
- Record which EN 182xx:2026 standard and edition supports each carrier, identifier, persistence, API, exchange, or interoperability decision, and identify any Article 10 or 11 requirement outside that standard's coverage.
- Do not put confidential supplier data, restricted authority data, or unversioned claims directly into the carrier payload.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR supports treating the carrier as the physical-to-digital link by requiring the passport to be connected through a data carrier and by addressing recognised standards for identifiers and carriers.
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS grounds the resolver architecture: a user scans a carrier, obtains a usable URI or DID, asks a resolver or DID document for typed links, and retrieves data from decentralized sources according to role and credentials.
- [GS1 Digital Product Passport Provisional Standard](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - GS1 explains the standards-oriented use case for identification and data carriers as a means to access DPP data through internationally standardized carriers.
- [Commission Implementing Decision (EU) 2026/1736](https://data.europa.eu/eli/dec_impl/2026/1736/oj?ref=sorena.io) - Binding source for the six cited EN 182xx:2026 standards and the presumption of conformity they provide for covered ESPR Articles 10 and 11 requirements.

## Separate decentralized data storage from EU registry and portal integration

The Commission launched the DPP Registry and a testing environment on 20 July 2026, but the detailed passport remains decentralised. The responsible economic operator or a DPP service provider stores passport data; the Registry indexes unique identifiers, registration data, and high-level metadata and stores customs-relevant commodity codes where required. It is not the product master database.

Implementing Regulation (EU) 2026/1778, effective from 6 August 2026, defines the secure interface, registration API, verification platform, user identity and authorisation, semantic repository, and logging. The public web portal remains a separate search-and-compare layer, so teams still need stable, access-controlled endpoints for the detailed passport.

- Create one inventory of authoritative systems: PLM, ERP, supplier portal, lab evidence repository, conformity documentation, resolver, DPP repository, registry upload process, and backup provider.
- Register the data required by ESPR and delegated acts, then keep registry payloads synchronized when identifiers, commodity codes, or required registry fields change.
- Expose portal-searchable data through stable endpoints that reflect the same access categories used by the passport itself.
- Treat the registry response unique registration identifier as an enforcement integration artifact, not proof that the product complies.
- Document fallback behavior for service-provider failure, domain transfer, archive access, and economic-operator cessation.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR Articles 11 to 14 distinguish decentralized passport storage, backup availability, the Commission registry, and the public web portal for search and comparison.
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS describes a decentralized architecture where economic operators or appointed providers manage data while registry and portal functions support discovery, enforcement, and search.
- [Commission Implementing Regulation (EU) 2026/1778](https://data.europa.eu/eli/reg_impl/2026/1778/oj?ref=sorena.io) - Binding source for Registry components, identity verification, interface and API registration, semantic repository, automated checks, versioning, logging, and customs data, effective from 6 August 2026.
- [European Commission: DPP Registry](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/dpp-registry_en?ref=sorena.io) - Current operational source for the live Registry, testing environment, organisation enrolment, and the distinction between Registry metadata and decentralised passport data.

*Recommended next step*

*Placement: after governance section*

## Turn DPP architecture into a governed data flow

This guide helps connect identifiers, carriers, registry payloads, supplier evidence, access rights, and customs integration before publishing passport data.

- [Open Research Copilot](/solutions/research-copilot.md): Check DPP architecture questions against cited legal and technical source material.
- [Discuss DPP implementation](/contact.md): Review identifier, carrier, access-rights, registry, and supplier-data choices with Sorena.

## Build access categories into the data model

Access control is a first-order passport requirement. ESPR requires easy, free access based on access rights set in the applicable delegated act and restricts rights to introduce, modify, or update data. The architecture should therefore label each field by audience, credential, purpose, update right, and evidence source.

The Batteries Regulation is a useful worked example of access categories: some battery model information is public, some information is limited to persons with a legitimate interest and the Commission, test-report results are limited to notified bodies, market surveillance authorities and the Commission, and individual battery data can be limited to persons with a legitimate interest. Product groups under ESPR may differ, but the architectural pattern is the same: data fields need access classes, not one flat public payload.

- Create field-level labels for public, customer, business partner, repairer, recycler, legitimate-interest, notified-body, market-surveillance, customs, Commission, and internal-only data where applicable.
- Use credentials or role verification for restricted endpoints, and log access decisions without exposing confidential business information in public pages.
- Give public users enough sustainability, circularity, durability, legal-compliance, and instruction data to satisfy the delegated act without exposing protected supplier inputs.
- Give authorities and customs machine-readable access paths that do not depend on consumer web-page layout.
- Separate rights to read data from rights to introduce, correct, approve, or withdraw data.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR Article 11 requires access based on delegated-act access rights and restricts introduce, modify, and update rights according to those access rights.
- [Regulation (EU) 2023/1542 concerning batteries and waste batteries](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - The Batteries Regulation provides a concrete passport access model with public battery model information, legitimate-interest information, authority and notified-body information, and individual battery data categories.
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS grounds role-based data flows where the endpoint determines the requester's access level from credentials and returns different data sets for consumer, repairer, recycler, authority, or other roles.

## Design supplier and lifecycle data flows before publication

Many passport fields depend on suppliers, test labs, repairers, recyclers, or service providers. ESPR allows the Commission to require supply chain actors to provide information needed to verify compliance, and CIRPASS shows why the passport architecture needs update flows as well as read flows.

A defensible implementation gives suppliers structured submission routes, evidence formats, data-quality checks, and update rights. It also defines when a downstream lifecycle event updates the existing passport and when a new product identifier or new passport is needed under the relevant product rules.

- Collect supplier evidence against named fields, units, methods, criteria sources, and product identifiers rather than free-text sustainability claims.
- Store provenance for each supplier-provided value: source, date received, product scope, facility or operator identifier, validation status, and approver.
- Require machine-readable values for fields needed by comparison, portal search, customs checks, repair, recycling, or public claims.
- Define role-based update flows for repairers, refurbishers, remanufacturers, recyclers, and authorized suppliers before the product is placed on the market.
- Keep a change log for corrections, reissued evidence, withdrawn supplier data, changed access class, and new backup-provider or resolver details.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR supports supplier-data governance because it allows requirements for supply chain actors to provide information needed for verification of ecodesign compliance.
- [ETSI ES 204 082 information model for sustainability and circularity](https://www.etsi.org/deliver/etsi_es/204000_204099/204082/01.01.01_60/es_204082v010101p.pdf?ref=sorena.io) - ETSI ES 204 082 supports structured supplier data by describing environmental claim fields such as topic, criteria reference, claimed value, benchmark reference, conformance, and conformity evidence.
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS supports lifecycle integration by describing repairer, sorter, refurbisher, remanufacturer, market-surveillance, and customs user stories that depend on role-specific reads or updates.

## Plan customs, public, and restricted access as separate products

Public DPP access, customs access, and restricted professional access solve different problems. Consumers and business buyers need understandable sustainability, circularity, durability, instruction, and compliance information. Customs authorities need the unique registration identifier and commodity code to match registry data when products are released for free circulation. Market surveillance authorities and notified bodies may need deeper compliance evidence.

The architecture should therefore expose different views over the same governed source data. A consumer page can be concise and accessible; the authority and customs integration must be stable, machine-readable, and aligned with the registry and EU Customs Single Window interconnection when applicable.

- Do not make customs checks depend on scraping a consumer page or downloading a marketing PDF.
- Keep the public product page, machine-readable public data, restricted evidence endpoint, registry upload payload, and customs data payload versioned together.
- Validate that public statements are backed by data fields and evidence records before they are published through the passport.
- Make restricted access auditable: requester identity, role, legal basis or delegated-act access class, fields returned, and timestamp.
- Treat a successful customs registry match as an existence and data-match check, not a compliance certification.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR Article 15 grounds customs integration by requiring the unique registration identifier for release for free circulation and electronic verification against registry data, while stating release is not proof of compliance.
- [European Commission ESPR overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - The Commission overview explains the DPP as electronically accessible information for consumers, manufacturers, and authorities, including automatic customs checks on DPP existence and authenticity for imported products.

## Govern the passport like regulated product infrastructure

A DPP architecture is not complete until operational ownership is clear. The responsible economic operator, service provider, data owners, supplier owners, compliance approvers, and IT operators need defined duties for creation, authentication, processing, storage, backup, access control, correction, withdrawal, incident handling, and evidence retention.

Good governance avoids two common failures: a technically working QR code with unverified content, and a compliance data repository that cannot be reached by customers, authorities, or customs through the required passport path.

- Maintain a passport control register covering product group, identifier level, data carrier, resolver, authoritative data sources, access classes, registry upload, portal exposure, backup provider, and owner approvals.
- Run release checks for carrier readability, resolver response, public page content, machine-readable data, restricted endpoint authorization, registry synchronization, and customs data availability.
- Use evidence records with field-level provenance, not page-level supporting source references, for sustainability and compliance claims.
- Review changes when delegated acts, harmonised standards, carrier standards, supplier data, product composition, operator identifiers, facility identifiers, or service providers change.
- Keep personal data out of the passport unless a clear lawful basis and product-rule requirement exist; ESPR requires that personal data relating to customers not be stored without explicit consent and that the passport be designed with a high level of security and privacy.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - ESPR Article 11 grounds governance requirements for interoperability, storage responsibility, linked successor passports, availability after cessation, update rights, authentication, integrity, security, privacy, and service-provider processing limits.
- [Commission consultation on Digital Product Passport service providers](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - The Commission consultation grounds service-provider governance because it sought stakeholder input on how DPP data should be stored and managed by service providers and whether a certification scheme is needed.
- [CIRPASS project results: DPP system architecture](https://cirpassproject.eu/project-results/?ref=sorena.io) - The CIRPASS results page describes the architecture report as centered on the product identifier and covering HTTP URI and decentralized identifier architectures from structural and data-flow viewpoints.

## Primary sources

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal source for DPP technical design, identifiers, data carriers, access rights, registry, web portal, customs controls, and Annex III data elements.
  - Quote: "Technical design and operation of the digital product passport"
- [Regulation (EU) 2023/1542 concerning batteries and waste batteries](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Used as a concrete passport access-category example because Annex XIII divides battery passport information into public, legitimate-interest, authority/notified-body, and individual-battery categories.
  - Quote: "Information to be included in the battery passport"
- [European Commission ESPR overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Commission overview source for the DPP's purpose as electronically accessible product information supporting sustainability, circularity, legal compliance, and customs checks.
  - Quote: "Digital Product Passport"
- [Commission consultation on Digital Product Passport service providers](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Commission source for service-provider storage and management questions and the potential need for certification of DPP service providers.
  - Quote: "service providers"
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - Technical architecture source for decentralized DPP repositories, resolver flows, HTTP URI and DID options, role-based access, supplier and repair updates, authority access, and backup concerns.
  - Quote: "DPP System Architecture"
- [CIRPASS project results](https://cirpassproject.eu/project-results/?ref=sorena.io) - Source page confirming the D3.2 architecture report scope and its focus on product identifiers, HTTP URI architecture, decentralized identifier architecture, and data-flow validation.
  - Quote: "product identifier"
- [ETSI ES 204 082 information model for sustainability and circularity](https://www.etsi.org/deliver/etsi_es/204000_204099/204082/01.01.01_60/es_204082v010101p.pdf?ref=sorena.io) - Technical standard source for DPP information-model concepts, environmental claim data, criteria references, metrics, evidence, and URI-based references.
  - Quote: "information model"
- [GS1 Digital Product Passport Provisional Standard](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Standards source for identification and data-carrier preparation, including access to DPP data through internationally standardized data carriers.
  - Quote: "identification and data carrier"
- [Commission Implementing Regulation (EU) 2026/1778](https://data.europa.eu/eli/reg_impl/2026/1778/oj?ref=sorena.io) - Current binding source for DPP Registry architecture and operations, effective from 6 August 2026.
- [European Commission: DPP Registry](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/dpp-registry_en?ref=sorena.io) - Current official source for Registry and testing-environment availability.
- [Commission Implementing Decision (EU) 2026/1736](https://data.europa.eu/eli/dec_impl/2026/1736/oj?ref=sorena.io) - Official Journal source for the six harmonised DPP standards covering data exchange, identifiers, carriers, persistence, APIs, and interoperability.

## Related Topic Guides

- [Annex III Data Model Planning for EU Digital Product Passports](/artifacts/eu/digital-product-passport/annex-iii-data-model-planning.md): Plan EU Digital Product Passport data fields, identifiers, access rights, update owners, registry inputs, and evidence records against ESPR Annex III and product-specific delegated acts.
- [Digital Product Passport vs Digital Twin](/artifacts/eu/digital-product-passport/dpp-vs-digital-twin.md): Compare EU Digital Product Passports with digital twins: legal access duties, identifiers, public and restricted data, evidence, governance, and reuse limits.
- [Digital Product Passport vs Paper Product Passports](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): Compare EU regulated digital product passports with paper, PDF, web, and internal product passports across access, identifiers, data carriers, restricted data, customs checks, registry, and interoperability.
- [DPP customs access review workflow for ESPR products](/artifacts/eu/digital-product-passport/customs-access-review-workflow.md): Review public, restricted, and customs access for EU Digital Product Passports, including registry handoffs, portal access rights, and release-for-free-circulation evidence.
- [DPP Data Governance RACI Template for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Assign accountable owners for EU Digital Product Passport data, access rights, supplier inputs, resolver links, registry uploads, verification checks, and retained evidence.
- [DPP data-model intake workflow for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow.md): An intake workflow for EU Digital Product Passport data models: product scope, legal status, field owner, evidence, access class, identifiers, carrier, registry mapping, and publication readiness.
- [DPP Governance, Verification and Audit Controls](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates.
- [DPP QR code vs NFC data carrier choices under EU ESPR](/artifacts/eu/digital-product-passport/faq/qr-code-vs-nfc-carrier-choices.md): How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.
- [DPP registry and web portal integration under EU ESPR](/artifacts/eu/digital-product-passport/dpp-registry-and-web-portal-integration.md): Official source guide to EU Digital Product Passport registry and web portal integration under ESPR, covering identifiers, data carriers, access rights, service providers, and lookup design.
- [DPP vs Battery Passport: ESPR and Battery Regulation Comparison](/artifacts/eu/digital-product-passport/dpp-vs-battery-passport.md): Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.
- [DPP vs EPREL Comparison](/artifacts/eu/digital-product-passport/dpp-vs-eprel.md): Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.
- [DPP vs GS1 Digital Link: Duties vs Standard](/artifacts/eu/digital-product-passport/dpp-vs-gs1-digital-link.md): Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.
- [EU Digital Product Passport access: public, restricted, and customs views](/artifacts/eu/digital-product-passport/public-restricted-and-customs-access.md): How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.
- [EU Digital Product Passport API and resolver architecture](/artifacts/eu/digital-product-passport/api-and-resolver-architecture.md): DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.
- [EU Digital Product Passport Applicability Test](/artifacts/eu/digital-product-passport/applicability-test.md): Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.
- [EU Digital Product Passport checklist](/artifacts/eu/digital-product-passport/checklist.md): A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.
- [EU Digital Product Passport compliance: ESPR requirements](/artifacts/eu/digital-product-passport/compliance.md): EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.
- [EU Digital Product Passport Data Carriers, Access Control, and UX](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.
- [EU Digital Product Passport data requirements and fields](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation.
- [EU Digital Product Passport deadlines and compliance calendar](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): EU Digital Product Passport calendar covering the live DPP Registry, ESPR product-rule milestones, and fixed battery passport dates.
- [EU Digital Product Passport FAQ](/artifacts/eu/digital-product-passport/faq.md): Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.
- [EU Digital Product Passport identifier and data carrier design](/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design.md): How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.
- [EU Digital Product Passport penalties and enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How EU Digital Product Passport breaches can lead to national penalties, corrective action, market restrictions, and customs holds under ESPR or battery law.
- [EU Digital Product Passport Product Group Readiness](/artifacts/eu/digital-product-passport/product-group-readiness.md): Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.
- [EU Digital Product Passport requirements under ESPR](/artifacts/eu/digital-product-passport/requirements.md): Overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.
- [EU Digital Product Passport supplier data validation controls](/artifacts/eu/digital-product-passport/supplier-data-validation.md): Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.
- [EU DPP customs access: registry, portal, and restricted data](/artifacts/eu/digital-product-passport/faq/customs-access.md): FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.
- [EU DPP implementation playbook and vendor selection](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence.
- [EU DPP Product-Group Readiness Checklist](/artifacts/eu/digital-product-passport/product-group-readiness-checklist.md): A checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.
- [EU DPP QR Code and Data Carrier Implementation Guide](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): Guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.
- [EU DPP supplier data validation workflow](/artifacts/eu/digital-product-passport/supplier-data-validation-workflow.md): A workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.
- [EU DPP unique identifier requirements: product, operator and facility IDs](/artifacts/eu/digital-product-passport/faq/unique-identifier-requirements.md): FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.
- [Public vs restricted EU Digital Product Passport data](/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data.md): How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.
- [What is a Digital Product Passport under ESPR?](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.
- [What is the EU Digital Product Passport registry?](/artifacts/eu/digital-product-passport/faq/dpp-registry.md): FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.
- [Which products come first for the EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/which-products-come-first.md): FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.
- [Who must create an EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/who-must-create-a-digital-product-passport.md): DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.


---

[Privacy Policy](https://www.sorena.io/privacy.md) | [Terms of Use](https://www.sorena.io/terms-of-use.md) | [DMCA](https://www.sorena.io/dmca.md) | [About Us](https://www.sorena.io/about-us.md)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration.md