--- title: "Public vs restricted EU Digital Product Passport data" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data" author: "Sorena AI" description: "How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU Digital Product Passport" - "DPP access rights" - "public passport data" - "restricted passport data" - "ESPR registry" - "battery passport" - "Digital Product Passport" - "ESPR" - "Product passport registry" - "Customs controls" --- **[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) --- # Public vs restricted EU Digital Product Passport data How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules. *FAQ* *DPP access* *EU* ## EU Digital Product Passport Public vs restricted passport data Do not treat the DPP as one public web page. ESPR expects access to be differentiated by data type and stakeholder role, with product-specific delegated acts deciding who can see or update each data set. Use this FAQ to classify public consumer data, restricted value-chain data, authority-only evidence, registry records, and customs information without exposing confidential business information. Public DPP data is the information that customers and other stakeholders should be able to find without a private access gate. Restricted DPP data is information that only named actors should see or update, such as repairers, recyclers, market surveillance authorities, customs authorities, notified bodies, or persons with a legitimate interest where a sector rule says so. The exact access map is not universal: ESPR requires product-group delegated acts to specify the data, the actors with access, and the actors allowed to create or update passport data. ## Public vs restricted passport data Compare the main DPP visibility categories teams need to separate before publishing, sharing, or registering passport data. - **Public passport data**: Data intended for customer, stakeholder, search, and comparison use under the applicable delegated act or sector rule. - **Restricted passport data**: Data limited to specific actors, authorities, notified bodies, customs uses, or legitimate-interest users according to the applicable rule. | Dimension | Public passport data | Restricted passport data | Operational implication | Sources | | --- | --- | --- | --- | --- | | Scope boundary | The product-group delegated act or sector rule decides which DPP fields are public. | The same rule decides which actors can access restricted data and which actors can create or update it. | Do not make access decisions from a generic DPP template; cite the product rule for each field. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 10 ties data access to product-group access rights. | | Covered actors | Public DPP data should be reachable through the data carrier or public portal without unnecessary login or personal data collection. | Restricted DPP data should use role-based access, login, authentication, or digital credentials suitable for the actor and data sensitivity. | Build separate public and restricted views rather than hiding all data behind one account wall or exposing all fields on one public page. | [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance links restricted data to software roles, logins, or authentication.
[Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 11 requires free and easy access based on respective access rights. | | Trigger | Battery model information such as material composition, carbon footprint information, recycled content, rated capacity, voltage, power capability, lifetime, warranty period, and waste-battery management information is listed as publicly accessible. | Battery detailed composition, spare-part source details, dismantling information, safety measures, test report results, and individual-battery state data are assigned to narrower access groups. | Use the battery model as proof that DPP access is field-specific, not simply public versus secret. | [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Annex XIII demonstrates a multi-tier passport access model. | | Core obligations | Public portal visibility is for search and comparison according to access rights; it is not the customs verification record. | Registry and customs flows use unique identifiers, unique registration identifiers, and commodity codes for verification and release-for-free-circulation controls. | Keep public content governance separate from registry upload controls and customs broker handoff controls. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 15 says customs release is not proof of compliance with ESPR or other Union law. | | Evidence record | Public data governance focuses on accuracy, completeness, accessibility, comparison, stable links, and avoiding unnecessary personal data collection. | Restricted data governance focuses on authentication, purpose limitation, update permissions, integrity, security, privacy, and protection of confidential business information. | A complete DPP evidence file needs both a publication review and an access-control review. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Recital 32 frames DPP access without endangering confidential business information. | | Timing and deadlines | The passport should stay available for at least the expected lifetime of the product, and the delegated act can set a longer period where needed. | The registry must be operational by 19 July 2026, and customs checks start only when the registry-to-customs connection is operational. | Treat publication timing, registry timing, and customs timing as separate implementation milestones. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The registry and customs controls are phased separately from passport access and data-retention rules. | | Enforcement | Public data issues are mainly publication-quality issues: missing fields, unclear labels, or data that should have been public but was not presented accessibly. | Restricted data issues can trigger market-surveillance action, formal non-compliance findings, and penalties when access controls or update rights are not respected. | Enforcement is about compliance checking and penalties, not about deciding which fields are public. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The enforcement chapter separates corrective action, formal non-compliance, and penalties from the access-rights rules. | | Overlap and reuse | The same data field can be public in the portal and still need to be stored in the registry or cited in technical documentation. | Restricted fields can be reused across registry checks, customs checks, and market-surveillance files without becoming public by default. | Reuse the field, not the access rule: one field can serve several processes under different visibility rules. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 13 to 15 and 67 show how registry and customs data can be reused in different workflows. | | Practical decision rule | If a field helps consumers compare products, start by checking whether the delegated act makes it public. | If a field supports repair, conformity, customs, or surveillance work, check whether the delegated act limits access or update rights. | Classify each field by its primary use first, then confirm the access rule in the applicable legal text. | [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The decision rule should follow the legal function of the field rather than a generic template. | Sources for Scope boundary - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 9 requires delegated acts to specify DPP data and actor access. - Quote: "actors that are to have access" Sources for Scope boundary - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 9 also requires delegated acts to specify who may create or update passport data. - Quote: "create a digital product passport or update" Sources for Scope boundary - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 10 ties data access to product-group access rights. - Quote: "specified in the applicable delegated act" Sources for Covered actors - Public passport data: - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance says public data should be available without logins and personal data collection. - Quote: "public data should be available" Sources for Covered actors - Restricted passport data: - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance links restricted data to software roles, logins, or authentication. - Quote: "restricted data who has access" Sources for Covered actors - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 11 requires free and easy access based on respective access rights. - Quote: "free of charge and easy access" Sources for Trigger - Public passport data: - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Annex XIII lists battery model information accessible to the public. - Quote: "accessible to the public" Sources for Trigger - Restricted passport data: - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Annex XIII lists separate access categories for legitimate-interest users, authorities, notified bodies, and individual-battery data. - Quote: "notified bodies, market surveillance authorities and the Commission" Sources for Trigger - operational implication: - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Annex XIII demonstrates a multi-tier passport access model. - Quote: "INFORMATION TO BE INCLUDED IN THE BATTERY PASSPORT" Sources for Core obligations - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 14 establishes the public web portal for search and comparison under access rights. - Quote: "publicly accessible web portal" Sources for Core obligations - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 13 and 15 govern registry and customs identifier checks. - Quote: "unique registration identifier" Sources for Core obligations - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 15 says customs release is not proof of compliance with ESPR or other Union law. - Quote: "not be deemed to be proof of compliance" Sources for Evidence record - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 9 requires DPP data to be accurate, complete, and up to date. - Quote: "accurate, complete and up to date" Sources for Evidence record - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 11 requires restricted update rights, data integrity, security, privacy, and fraud prevention. - Quote: "rights to introduce, modify or update data" Sources for Evidence record - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Recital 32 frames DPP access without endangering confidential business information. - Quote: "without endangering the protection" Sources for Timing and deadlines - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 9 requires the passport to remain available for at least the expected lifetime of the product. - Quote: "at least the expected lifetime" Sources for Timing and deadlines - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 13 sets the registry deadline and Article 15 ties customs verification to registry operational status. - Quote: "By 19 July 2026" Sources for Timing and deadlines - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The registry and customs controls are phased separately from passport access and data-retention rules. - Quote: "the first subparagraph of this paragraph shall apply from the moment the registry is operational" Sources for Enforcement - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 14 establishes the public web portal for searching and comparing DPP data. - Quote: "search for and compare" Sources for Enforcement - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 69, 71, and 74 cover market-surveillance measures, formal non-compliance, and penalties. - Quote: "effective, proportionate and dissuasive" Sources for Enforcement - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The enforcement chapter separates corrective action, formal non-compliance, and penalties from the access-rights rules. - Quote: "formal non-compliance" Sources for Overlap and reuse - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The public portal and registry are separate systems with different functions. - Quote: "publicly accessible web portal" Sources for Overlap and reuse - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The registry, customs checks, and enforcement files can use the same underlying product data for different purposes. - Quote: "retrieve and use the data included in the digital product passport" Sources for Overlap and reuse - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 13 to 15 and 67 show how registry and customs data can be reused in different workflows. - Quote: "the registry shall store the unique identifiers" Sources for Practical decision rule - Public passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 14 gives the public portal a search and comparison function. - Quote: "search for and compare" Sources for Practical decision rule - Restricted passport data: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 9 to 11 and 13 to 15 cover access rights, update rights, registry use, and customs controls. - Quote: "based on their respective access rights" Sources for Practical decision rule - operational implication: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - The decision rule should follow the legal function of the field rather than a generic template. - Quote: "specified in the applicable delegated act" ### How should teams decide what is public or restricted? - Start with the applicable delegated act or sector rule and list each mandatory passport field. - Classify every field by read audience, update audience, purpose, authentication method, and evidence owner. - Keep registry and customs data controls separate from the public web portal view. - Escalate fields that expose confidential business information, personal data, safety-sensitive detail, or conformity evidence before publication. Sources for the practical decision rule: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR is the primary source for DPP data access, update rights, registry handling, and customs controls. - Quote: "based on their respective access rights" - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Battery passport Annex XIII provides a concrete example of field-level access tiering. - Quote: "accessible only to persons with a legitimate interest" ## What is the rule for public versus restricted DPP data? Under ESPR, a digital product passport must contain the data specified in the applicable product-group delegated act. That delegated act must state which actors have access to which data, who can create or update passport data, and how long the passport remains available. The practical rule is therefore to build an access matrix before publishing the passport. Each data field should be marked as public, restricted to defined value-chain actors, restricted to authorities or notified bodies, registry-only, customs-relevant, or not yet supported by the applicable product rule. - Public data should support customer access, comparison, circularity decisions, and other public uses named in the product rule. - Restricted data should be limited to the actors that need it for repair, reuse, recycling, conformity, market surveillance, customs, or another specified role. - Update rights are separate from read rights: ESPR requires rights to introduce, modify, or update passport data to be restricted according to access rights. - Do not publish confidential business information simply because it sits in the passport data model; ESPR expressly requires differentiated access and protection of confidential business information. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 9 to 11 require delegated acts to define passport data, actor access, update rights, and essential technical safeguards. - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Recital 33 explains why DPPs need differentiated access by data type and stakeholder typology. ## Which access categories should a DPP team design for? A useful DPP access design separates the public portal experience from the restricted operational layer. Public data should be reachable without unnecessary login friction. Restricted data should require authentication or equivalent controls tied to the actor's role. The battery passport shows why this matters. Annex XIII to the Batteries Regulation divides passport content into public model-level information, information for persons with a legitimate interest and the Commission, information only for notified bodies, market surveillance authorities and the Commission, and individual-battery data for persons with a legitimate interest. - Public model data: consumer-facing and comparison data, such as the categories made public for battery models. - Restricted legitimate-interest data: operational detail such as dismantling, spare parts, safety measures, or individual item status where the sector rule grants access. - Authority and notified-body data: conformity evidence such as test report results when the rule reserves it for notified bodies, market surveillance authorities, and the Commission. - Customs data: identifiers and commodity codes used to verify imported products against the DPP registry, not a general public disclosure channel. Sources for this answer: - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Annex XIII gives a concrete battery passport example with public, legitimate-interest, authority-only, and individual-battery access tiers. - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The CEN-CENELEC guidance describes public access without logins and restricted access through software roles or authentication. ## How do the registry, web portal, and customs checks differ? The ESPR registry is not the same thing as the public DPP web portal. The registry is a Commission-managed system that securely stores at least unique identifiers, and for products released for free circulation it also stores the commodity code. Economic operators upload the required registry data, and the registry returns a unique registration identifier. The web portal is the public search and comparison layer. It must allow stakeholders to search and compare passport data consistently with the access rights set in delegated acts. Customs controls use the registry and passport data for risk management, customs controls, and release for free circulation. - Registry: at least unique identifiers, plus commodity code for products intended for release for free circulation. - Web portal: public search and comparison, limited by each stakeholder's access rights. - Customs: verification that the unique registration identifier and commodity code correspond to registry data before release for free circulation once the relevant systems are operational. - Evidence implication: keep registry upload records, the returned unique registration identifier, commodity-code mapping, and the access-rights matrix together. 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 to 15 establish the registry, public web portal, and customs-control linkage for DPP identifiers and commodity codes. - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance describes the central registry as a lookup database for identifiers and commodity codes and distinguishes it from the DPP web portal. ## What evidence should teams keep? Keep evidence that proves the access decision for each data field. A visitor, auditor, authority, supplier, repairer, or customs broker should be able to see why a field was public, restricted, authority-only, customs-relevant, or excluded from publication. The evidence should also show who can change passport data. Read access for a recycler, repairer, authority, or customer does not automatically mean write access. - A DPP data inventory mapped to the applicable delegated act or sector rule. - An access-rights matrix by field, actor, purpose, read permission, update permission, and authentication method. - A confidential-business-information review for data proposed for public display. - Registry evidence: uploaded identifiers, commodity code where relevant, and the returned unique registration identifier. - Customs evidence: process controls for making the unique registration identifier available when a covered product is released for free circulation. - Change-control evidence showing who created, modified, or updated each restricted passport field. 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 open, interoperable data, protection of personal data, restricted update rights, data integrity, security, and privacy. - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance links restricted DPP data to logins or authentication and says public data should be available without personal data collection. ## How should teams decide what is public or restricted? - Start with the applicable delegated act or sector rule and list each mandatory passport field. - Classify every field by read audience, update audience, purpose, authentication method, and evidence owner. - Keep registry and customs data controls separate from the public web portal view. - Escalate fields that expose confidential business information, personal data, safety-sensitive detail, or conformity evidence before publication. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR is the primary source for DPP data access, update rights, registry handling, and customs controls. - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Battery passport Annex XIII provides a concrete example of field-level access tiering. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR is the primary source for DPP data access, update rights, registry handling, and customs controls. - Quote: "based on their respective access rights" - [Regulation (EU) 2023/1542 (Batteries Regulation)](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Battery passport Annex XIII provides a concrete example of field-level access tiering. - Quote: "accessible only to persons with a legitimate interest" - [CWA 18186:2025 DPP guidelines](https://www.cencenelec.eu/get-involved/research-and-innovation/horizon-europe-projects/cwa-download-area/?ref=sorena.io) - The guidance links restricted data to software roles, logins, or authentication. - Quote: "restricted data who has access" ## 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 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): 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. - [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. *Recommended next step* *Placement: after evidence section* ## Turn DPP access rules into an evidence matrix Map each passport field to its legal source, role-based visibility, update rights, registry handling, and customs evidence before exposing public DPP data. - [Open Research Copilot](/solutions/research-copilot.md): Test DPP access classifications against cited source material. - [Discuss DPP implementation](/contact.md): Review public, restricted, authority, and customs access controls with Sorena. --- [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/faq/public-vs-restricted-passport-data