Public and consumers
Approved identity, origin, instructions, sustainability or circularity information intended for open access.
Access and security guide
Digital Product Passport Access Controls for Regulators, Buyers and Partners
Use one persistent product identity while giving each stakeholder only the information and evidence they are authorised to access.
Differentiated viewsEvidence securityTenant isolationVersion history
The core principle
A DPP is not one public document
A Digital Product Passport can serve consumers, customers, service partners, auditors, market-surveillance authorities and the responsible manufacturer. Those audiences do not necessarily need the same fields, evidence or actions.
A robust architecture resolves one governed product identity, then evaluates the requester, purpose and applicable access policy before returning the permitted view. This protects sensitive information without fragmenting the product record.
Stakeholder views
Match access to role, relationship and legitimate need
Customers and asset owners
Purchased-product information, technical records, service guidance and evidence permitted for the commercial relationship.
Inspectors and service partners
Item history, inspection context, maintenance instructions and evidence needed for an authorised task.
Auditors and conformity bodies
Controlled evidence and traceability appropriate to the audit or assessment, where applicable.
Authorities and customs
Information required by applicable legislation and the access mechanisms defined for competent authorities.
Manufacturer teams
Internal product data, workflow status, exceptions and administrative controls limited by tenant and role.
Four-layer model
Treat access control as a system, not a page setting
Identity and authentication
Establish who or what is requesting access, using an appropriate user, organisation or system identity.
Authorisation
Decide whether that identity may perform the requested action for the relevant tenant, product and purpose.
Data classification
Label fields, evidence and lifecycle events by permitted audience instead of treating the passport as one public document.
Audit and version history
Record publication and access-relevant changes while preserving the integrity of historical passport versions.
Information classification
Classify the data before designing the screen
The final classes and mandatory access rights must follow applicable law. A configurable implementation can use a policy model like the following to prepare product fields, evidence and lifecycle events.
| Illustrative class | Purpose |
|---|---|
| Public | Openly accessible information approved for the published passport |
| Authenticated business | Customer, supplier or partner information available after verified sign-in and relationship checks |
| Auditor or authority | Evidence and data restricted to an authorised assurance or regulatory role |
| Internal | Operational data used by the responsible organisation but not published externally |
| Restricted | Sensitive evidence or records requiring narrow, explicitly approved access |
Evidence access
Protect the document, not only the link
Sensitive certificates, inspection records or commercial evidence should remain in private storage. An authorised download service can validate tenant, role, product and evidence scope before issuing short-lived access.
Permanent public file URLs can bypass later policy changes. Signed, time-limited delivery reduces that exposure while keeping authorised evidence usable.
Public passport boundary
Expose a narrow published interface
The public passport should receive only approved published data through a deliberately limited interface. Anonymous visitors should not gain direct access to internal product, tenant or evidence tables.
UniQorn Trace separates the public DPP experience from authenticated client workspaces and applies tenant-isolated access to operational data.
Implementation checklist
Test the denial paths as carefully as the approved view
A polished public page does not prove access security. The pilot must test who can see, download, change and publish each class of information—and what happens when access is refused.
- List every stakeholder that needs to read, contribute, approve or administer DPP information
- Classify each field, document and lifecycle event by audience and legitimate purpose
- Define authentication and organisation-verification requirements for non-public access
- Map permissions to tenant, product, role, action and evidence sensitivity
- Separate the public delivery interface from internal product-data administration
- Test direct URLs, expired sessions, cross-tenant access and unauthorised evidence downloads
- Preserve immutable published versions and use governed corrections or superseding events
- Review access rules when legislation, contractual relationships or product status changes
UniQorn Trace™ capability
A controlled foundation for differentiated DPP access
UniQorn Trace supports multi-tenant isolation, separation between authenticated workspaces and published passports, evidence visibility with protected delivery, lifecycle-event visibility, and immutable published history.
Detailed role policies and external authority credentials are configured and validated for each deployment. We do not present a generic regulator credential integration as a finished, universal feature.
Prove access with one real product
Classify its fields and evidence, publish the approved view, test restricted downloads and exercise one lifecycle change before scaling.
Discuss an access-control pilot Review the DPP data modelReview the API integration guideCommon questions
Digital Product Passport access control FAQ
Is all Digital Product Passport data public?
No. ESPR provides for differentiated access rights. The information visible to each stakeholder and the detailed access rules are determined by the applicable product-specific measures and other relevant law.
Who determines access to DPP information?
Applicable legislation defines mandatory access rights and datasets. The responsible economic operator also needs governed policies for legitimate business information that falls outside those mandatory requirements.
How can a DPP protect trade secrets and personal data?
Classify information before publication, minimise personal data, separate public and restricted interfaces, authenticate non-public users, authorise narrowly and record accountable changes. Legal and security specialists should validate the final design.
Can a buyer and a regulator see different DPP information?
Yes, where the applicable rules and authorisation model allow it. One product identity can resolve to different permitted views without creating conflicting passport identities.
How should evidence downloads be protected?
Keep restricted documents outside public storage, check the requester’s tenant, role and permitted scope, and issue short-lived signed access rather than exposing permanent public file links.
Can DPP access change after publication?
Access policies may evolve, but published product history should remain accountable. Correct content through a governed new version or append a superseding lifecycle event rather than silently rewriting the historical record.
Primary sources
See Regulation (EU) 2024/1781, particularly Articles 10–13, and the European Commission’s Digital Product Passport FAQs and DPP overview. Confirm the current product-specific legislation and security requirements applicable to your deployment.
Editorial note: This guide provides general architecture guidance, not legal advice, security certification or a claim that every product already requires a DPP.