The practical bottleneck: who is allowed to register a passport?
The EU DPP Registry has been operational since 20 July 2026. Many teams started with the technical questions: can a product identifier be registered, and does the data carrier resolve correctly? Both matter, but they are incomplete. Commission Implementing Regulation (EU) 2026/1778 of 16 July 2026 gives the identity before registration its own regulatory significance: registration is performed by verified economic operators, while access to registry functions is distinct from public access to product information.
This is not a reason to make QR codes more complicated. It is a reason to model responsibility, evidence and permissions before the first production registration. This guide separates those layers and sets out what manufacturers can prepare now.
Three identities that must not be conflated
Every DPP programme involves at least three separate identities.
First, there is the economic operator: the company or sole trader placing a product on the market or acting in the Registry. Article 4 of Regulation 2026/1778 links qualification as a verified economic operator to proof of identity. For EU-established sole traders, the act refers, for example, to a qualified electronic signature or an eIDAS-compliant electronic identification means at high assurance level. Legal persons are likewise subject to defined verification evidence.
Second, there is the human user. Procurement, master-data teams, compliance, external providers and a DPP service provider do not automatically have the same authority. A user account is therefore not a substitute for a verified company context. Systems need a traceable assignment: who acts for which economic operator, in which role, and until when?
Third, there is the product identity. A GTIN, serial number or another identifier describes the product at the required granularity; it does not prove that the person at the screen may register it. ESPR keeps these domains separate. The data carrier connects the product to the passport, while the Registry retains unique identifiers and registration data. The European Commission's DPP guidance describes the flow accordingly: product information is created and registered, then the Registry generates a unique registration identifier.
Combining those three identities in one table, API token or shared mailbox creates an operational and audit risk. The useful question is not “who knows the link?” but “who may trigger a registry action on behalf of this economic operator?”
A public QR scan is not registry authorisation
A QR code on a product remains an entry point to the passport. It is not a login mechanism for the Registry and should not become one. Consumers, repairers, recyclers and authorities require different information. The Commission’s current DPP guidance expressly describes information access according to user roles.
In practice, a clear separation of layers helps:
- A public scan serves a stable, free-to-access passport view containing the information required for the relevant product group.
- A role-restricted area manages evidence, supplier data, change history and internal approvals.
- The registry connector transmits only the necessary registration data and assigns the Registry response to a specific product record.
This avoids two common mistakes. First, a “secret” QR URL is not access control: it can be shared and is not evidence of authorisation. Second, the Registry is not the store for every product document. The Commission explains that complete product information may remain with the economic operator or a DPP service provider, while required metadata and identifiers are registered.
What the regulation implies technically
Regulation 2026/1778 describes more than a lookup database. It includes an API for registration and receiving information, a platform to confirm existence and completeness, a scheme for unique registration identifiers, a list of verified DPP service providers, a logging system, and identification and authorisation schemes. Data models must also be versioned.
Those provisions do not prescribe a finished product architecture. They do provide sound design constraints.
Establish the company profile before importing products
Before a bulk import, create a controlled company record. Include the legal entity, its economic-operator status, the verification method, the verification time and the accountable function. A DPP system should retain the underlying proof only where necessary and lawful; often a verification status with a reference and expiry or reassessment logic is enough.
Treat delegation as its own record
When a service provider or agency acts, the delegation needs scope. At a minimum, record the economic operator, permitted actions, product groups or brands, start, end and revocation. A general API key without a mandate boundary is too coarse for a registration-relevant action.
Make registration an evidential process
For each registration, retain at least the local product version, submitted identifier, response including registration identifier, timestamp, acting role and error class. That makes it possible to distinguish later between incomplete product data, an identifier collision and missing authority. Logging must not become a collection of unnecessary personal data; its purpose is a responsible, reviewable action chain.
Test permissions as rigorously as domain rules
Test coverage should not stop at “the API returned 200”. At minimum, verify that an unauthorised user cannot register; a delegated provider may handle only its agreed mandate; an expired delegation is rejected; the public passport view reveals no private Registry or evidence data; and a resubmitted operation is recognisable as a repeat.
A lean start plan for the coming weeks
Do not start with a full migration. Select a small representative product set and a real responsibility chain.
- Map the manufacturer, placer on the market, data owner and, where applicable, service provider for every pilot product.
- Document the method used to verify the economic operator and the person who approves that verification.
- Define roles for drafting, domain approval, registration and read-only access.
- Register a test record with versioned product data, and retain the registration, response and correction path.
- Test the public QR access separately from internal roles and the Registry connector.
- Rehearse revocation and change: a provider transition, changed company identity or an erroneous identifier.
This complements the existing QR3 guidance to test the Registry, resolver and data source separately. The additional focus is that a robust API integration begins only after the verified organisation and responsible role are clear.
What should not be claimed yet
The Registry Regulation establishes a technical and organisational framework. It does not make every product group immediately subject to a DPP requirement, nor does it replace sector-specific delegated acts. The Commission still describes introduction by product group, and ESPR delegated acts generally carry a transition period of at least 18 months. Verified operator status is also not a licence to submit incomplete or incorrect product data.
The practical conclusion is still immediate: identity, mandate, roles and audit trail belong in the DPP backlog before registration scales. That keeps the QR code the simple public entry point, and makes the Registry action what it is under the framework: a responsible, traceable act by a verified economic operator.
