--- title: "EU Digital Product Passport access: public, restricted, and customs views" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/public-restricted-and-customs-access" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/public-restricted-and-customs-access" author: "Sorena AI" description: "How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU Digital Product Passport" - "Digital Product Passport access rights" - "ESPR DPP registry" - "DPP customs controls" - "DPP web portal" - "public DPP data" - "restricted DPP data" - "Digital Product Passport" - "ESPR" - "access rights" - "customs controls" - "DPP registry" - "web portal" --- **[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 access: public, restricted, and customs views How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal. *DPP* *Access model* *EU* ## EU Digital Product Passport Public, Restricted, and Customs Access Separate Digital Product Passport data into public views, credentialed role-based views, authority access, and customs registry checks. This page focuses on ESPR access rights, EU registry and portal handoffs, operational controls, and the evidence needed to prove the access model works. Under the Ecodesign for Sustainable Products Regulation (ESPR), a Digital Product Passport is not just a public QR-code page. It is a structured data set connected to a data carrier and unique product identifier, with access regulated by ESPR Articles 10 and 11 and by product-group delegated acts. Teams should design the passport so public users can reach required product information easily, restricted actors can authenticate for the data they are allowed to see or update, authorities can perform their duties, and customs can verify imported products through the EU registry once the relevant systems are operational. ## Access categories to define before launch Start by separating four views. The public view is the information a customer or other unauthenticated visitor can reach through the data carrier, online listing, or EU web portal. Restricted operational views are for actors such as manufacturers, importers, distributors, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, and other actors named in ESPR Article 11. Authority and customs views must support the legal duties of competent national authorities, the Commission, and customs authorities. The exact data fields for each product group are not fixed by this generic page. ESPR says access to passport data is regulated by the essential requirements and by the specific access rights set in the applicable delegated act. Treat the delegated act as the binding source for field-level visibility, write-access, and product-model, batch, or item granularity. - Public access: no login for data that must be freely and easily accessible to customers or other public stakeholders. - Restricted read access: credentialed views for actors that need non-public passport information for repair, refurbishment, recycling, supply chain, or compliance work. - Restricted write access: only authorised actors may introduce, modify, or update passport data, and those rights must follow the delegated act. - Authority access: competent national authorities, the Commission, market surveillance authorities, and customs authorities need access routes that support their duties under Union law. - Customs access: for release for free circulation, customs checks focus at minimum on matching the unique registration identifier and commodity code against registry data. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 10 and 11 require access to DPP data to follow essential requirements and product-group access rights set by delegated acts. - [CEN-CENELEC CWA 18186:2025 Digital Product Passport guidelines](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Non-binding DPP design guidance describing public versus restricted DPP information and software user roles for restricted access. ## Role-based visibility and update controls A workable DPP access matrix should list each role, the data categories it can read, whether it can add or update any data, the credential or approval needed, and the system that enforces the rule. Public data should not depend on account creation. Restricted views should be tied to authenticated roles, and update rights should be narrower than read rights. ESPR Article 11 requires free and easy access based on access rights, restricts the right to introduce, modify, or update passport data, and requires data authentication, reliability, integrity, security, privacy, and fraud prevention. Those requirements make access design an audit topic, not only a front-end design choice. - Keep a field-level access matrix for public users, customers, dealers, importers, repairers, recyclers, market surveillance authorities, customs authorities, and internal administrators. - Record the delegated act, internal policy, or supplier contract that justifies each restricted field. - Separate read, create, update, withdraw, and emergency correction rights instead of granting broad editor access. - Require authentication for restricted data and keep credential issuance, role changes, and revocations in an audit log. - Block customer personal data from the DPP unless a separate lawful consent process supports it; ESPR also states customer personal data should not be stored without explicit GDPR-compliant consent. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 11 supports role-based read and update controls, data integrity, security, privacy, and fraud-prevention requirements for DPP operation. - [CIRPASS DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS architecture validation describes credential-based requests where data sources determine the requester's access level before returning DPP data. ## Customs access and registry handoff Customs access is not the same as a public product page. ESPR Article 13 creates a Commission-managed DPP registry that stores at least unique identifiers and, for products intended for release for free circulation, the commodity code. The economic operator placing the product on the market or putting it into service uploads the required registry data and receives a unique registration identifier, but ESPR states that this registry response is not proof of compliance. For customs controls under ESPR Article 15, the person placing a covered product under the customs procedure for release for free circulation must provide or make available the unique registration identifier. Customs authorities may release the product only after verifying at minimum that this identifier and the commodity code correspond to registry data. The registry is to be interconnected with EU CSW-CERTEX through the EU Single Window Environment for Customs for automated exchange with national customs systems. - Map every imported covered product to the DPP unique product identifier, registry unique registration identifier, commodity code, and responsible economic operator. - Validate commodity-code mapping before registry upload, because customs verification uses that code alongside the unique registration identifier. - Keep registry upload confirmations separate from compliance approvals; the registry response does not prove ESPR or other Union-law compliance. - Test the customs data package from ERP, PLM, trade-compliance, and DPP systems before release-for-free-circulation workflows depend on it. - Preserve evidence of failed or corrected registry/customs checks, including the data value changed, owner approval, and date of correction. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 13 and 15 establish the DPP registry, registry access by customs authorities, customs verification of unique registration identifiers and commodity codes, and EU CSW-CERTEX interconnection. - [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 explains that DPP information supports sustainability and legal compliance decisions and allows customs authorities to perform automatic checks on imported products. ## EU web portal, data carrier, and resolver controls The public web portal and the product data carrier are different handoffs. ESPR Article 14 requires a publicly accessible web portal where stakeholders can search for and compare DPP data in a manner consistent with their access rights. ESPR Article 10 requires the DPP to be connected through a data carrier to a persistent unique product identifier, and the data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act. Operationally, the data carrier should resolve to the right DPP endpoint for the specific product model, batch, or item. The portal, resolver, and DPP service should return public data without unnecessary friction, challenge restricted users for credentials, and avoid exposing restricted data through predictable URLs, cached files, search snippets, or unauthenticated APIs. - Confirm the delegated act location rule for the data carrier: product, packaging, or accompanying documentation. - Test scans from mobile devices, online product pages, and marketplace listings where a potential customer cannot physically access the product. - Check that the resolver returns only links appropriate for the requester and does not reveal restricted endpoints in public responses. - Make public DPP information searchable and comparable while enforcing role-based restrictions for non-public fields. - Keep a backup-copy and availability plan for the DPP so the access route survives provider failure, insolvency, liquidation, or cessation of activity where the delegated act requires availability. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 10 and 14 cover the persistent unique product identifier, data-carrier placement, web portal search and comparison, and access-right filtering. - [CEN-CENELEC CWA 18186:2025 Digital Product Passport guidelines](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Non-binding guidance discusses DPP information portal access, online presentation, scan paths, searchability, registry linkage, and public versus restricted portal data. ## Audit evidence for DPP access decisions The evidence file should prove that each audience sees the right data and that customs can verify the registry handoff. Keep evidence at field level rather than only storing a screenshot of the public DPP page. Reviewers should be able to trace each field from delegated-act requirement or internal classification to owner approval, source system, publication state, restricted access rule, and test result. The strongest audit trail links access design to operating controls: credential lifecycle, supplier data intake, versioning, registry upload, data carrier tests, portal tests, customs test records, and exception handling. This makes the page useful for product compliance, IT architecture, trade compliance, and audit teams working from the same DPP record. - Access matrix: role, data field, read/write permission, public or restricted status, source system, legal or business rationale, and owner. - Registry evidence: uploaded identifiers, commodity code, unique registration identifier, upload timestamp, responsible operator, and correction history. - Customs evidence: test shipment or release-for-free-circulation record showing identifier and commodity-code matching logic. - Portal and resolver evidence: scan tests, unauthenticated public view tests, authenticated restricted view tests, and failed-access tests. - Change evidence: approval record for every access-right change, data-field change, delegated-act update, credential revocation, or emergency correction. - Security evidence: authentication method, credential issuance process, audit logs, service-provider controls, backup-copy arrangement, and incident response path for exposed restricted data. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR Articles 10 to 15 ground the evidence topics for access rights, update restrictions, data integrity, registry upload, web portal access, and customs verification. - [CEN-CENELEC CWA 18186:2025 Digital Product Passport guidelines](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Non-binding design guidance supports practical evidence records for DPP portal setup, information exchange, traceability, security, and restricted role design. *Recommended next step* *Placement: after evidence section* ## Build a DPP access-control evidence pack Use this access model to connect DPP roles, data fields, registry uploads, customs checks, resolver behavior, and audit evidence before a passport goes live. - [Open Research Copilot](/solutions/research-copilot.md): Check Digital Product Passport access questions against cited ESPR and DPP source material. - [Discuss DPP access controls](/contact.md): Review role-based access, registry handoffs, and customs evidence with Sorena. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Primary legal source for DPP access rights, update restrictions, data-carrier and identifier requirements, registry duties, web portal access, and customs controls. - Quote: "access to data included in the digital product 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 of the DPP as a digital identity card for products and of customs automatic checks for imported products. - Quote: "digital identity card for products" - [CEN-CENELEC CWA 18186:2025 Digital Product Passport guidelines](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Non-binding implementation guidance for DPP designers covering portal setup, public and restricted access, identifiers, data carriers, registry linkage, traceability, and security. - Quote: "Guidelines to create a Digital Product Passport" - [CIRPASS DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS technical architecture source for resolver flows, credential-based access, authority/customs consumption of DPP data, and backup-service-provider considerations. - Quote: "DPP System Architecture" ## 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): A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, 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): Grounded 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 API and resolver architecture](/artifacts/eu/digital-product-passport/api-and-resolver-architecture.md): Grounded 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 architecture and integration](/artifacts/eu/digital-product-passport/architecture-and-integration.md): Grounded guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance. - [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): Grounded 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): Grounded EU Digital Product Passport calendar for ESPR and battery passport milestones, with product-group dates flagged as dependent on delegated acts. - [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): What ESPR says about Digital Product Passport penalties, Member State fine rules, market surveillance, customs checks, and unresolved product-specific delegated acts. - [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): source-linked 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 source-grounded 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): Grounded 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 grounded 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) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/public-restricted-and-customs-access