Who Can Update a Digital Product Passport After It Has Been Created?

There is no universal rule that the manufacturer, service provider, repairer or recycler can edit every part of a Digital Product Passport. ESPR makes update authority product-specific. The 2026 Registry regulation verifies who actors are, but verification is not the same thing as permission to change a particular passport field.

There are four different kinds of “update”

Most software collapses these into one Edit button. Legally and operationally, they are different.

1. Correcting the business's underlying product record

A supplier typo, new test result or corrected composition can change the business's source data.

That is internal product-data governance.

It does not automatically tell you whether the DPP should be overwritten, versioned or given a new product identity. That decision is owned by When a Product Changes, Do You Overwrite the Fact, Version the Record or Create a New Product?.

2. Updating data inside the DPP

This is the question Article 9(2)(g) and (h) ESPR reserves for the applicable product rule.

A manufacturer may be allowed to update one class of data. A repairer may be allowed to add a repair event. A recycler may have access to data without being able to modify the original composition record. The exact rights are not horizontal assumptions.

3. Updating the EU Registry registration data

The Registry stores registration data around the passport. Commission Implementing Regulation (EU) 2026/1778 gives verified economic operators the ability to register and modify registration data, subject to the Regulation and the relevant Union law.

The Registry supports versioning of registered data and timestamps updates.

That is not the same thing as editing every field hosted in the decentralised DPP.

4. Transferring responsibility for the registered DPP

A business sale, split, merger or cessation can transfer registered DPPs to another verified actor that takes over the obligations.

That is a responsibility transfer, not a normal data edit.

It is covered separately in What happens to your passports when the business changes hands.

Keeping these four actions separate prevents a lot of bad permission design.

The product-specific rule decides who may edit the passport

Article 9(2) ESPR is the controlling horizontal rule.

For each covered product group, the delegated act is expected to specify:

• the DPP data
• the data carrier
• the granularity
• customer access
• actor access rights
• the actors that create or update the DPP
• the data each actor may introduce or update
• how those updates work
• how long the DPP remains available.

That means a software provider cannot safely create one permanent permission model today that says:

manufacturer = edit all repairer = edit repair fields recycler = edit end-of-life fields

and assume it will be legally correct for every product group.

The better architecture is role-based and configurable:

actor identity + product rule + field permission + action

Only when all four line up should an update be permitted.

Verification is not edit permission

Commission Implementing Regulation (EU) 2026/1778 creates formal verification for economic operators and value-chain actors.

A value-chain actor includes a person or organisation, other than the economic operator, carrying out activities in the product value chain, such as a:

• repairer
• refurbisher
• remanufacturer
• recycler.

Only verified value-chain actors have access to the Registry, and they may perform actions there where specified in the relevant Union law.

That final qualification does most of the legal work.

A verified repairer is not automatically entitled to modify a product's registration or composition data.

A verified recycler is not automatically entitled to delete the original passport.

A verified remanufacturer may acquire broader obligations where the applicable product law treats the remanufactured product as a new regulated product, but that is a product-law question rather than a generic Registry permission.

The practical repair-information question is owned by What Repair Information Can a Digital Product Passport Actually Provide?. This page owns the different question: who has authority to change the record?

The economic operator has a special Registry role

For ESPR products covered by Article 8(1) of the Registry regulation, the DPP is registered by the verified economic operator placing the product on the market or putting it into service.

The verified economic operator is responsible for:

• the accuracy and completeness of the information it submits for registration
• keeping Registry information accurate, complete and up to date
• security of its Registry credentials and systems
• the actions of a third party it authorises to perform registration actions on its behalf.

Article 19 is explicit that authorising a third party does not remove the verified economic operator's responsibility.

So a software platform can act as an operational agent where the law allows it without becoming the legal owner of the business's underlying responsibility.

This is the same reason Who has to own this, and what happens when a field turns out to be wrong matters even when the technology is automated.

A service provider is not automatically the editor

A DPP service provider has a specific role in the DPP architecture. Under ESPR, the economic operator must make a backup copy available through a DPP service provider when placing the product on the market.

That does not mean the provider acquires unrestricted rights to change the customer's product claims.

Access, processing and provider responsibilities are separate from field ownership and update authority.

A robust provider should therefore be able to distinguish:

• hosting data
• backing up data
• processing data
• publishing data
• submitting Registry actions on behalf of a customer
• changing the customer's governed product assertion.

Those are not interchangeable permissions.

The provider boundary is covered in Who is allowed to hold your passport data, and what they may do with it.

A repairer can add something without rewriting the manufacturer's history

This is an important lifecycle design principle.

Imagine a product leaves the manufacturer with:

battery state: original repair history: none

A repairer later replaces a component.

If the applicable product rule allows the repairer to add repair information, a good DPP architecture should support a new lifecycle assertion such as:

repair event: component X replaced actor: verified repairer date: 4 June 2029

without silently changing the historical fact that the original manufacturer shipped the product with another component.

That distinction between original product truth and later lifecycle event is what makes multi-actor DPPs useful.

It also matters for evidence. A repairer should be able to evidence the intervention it performed without becoming the source of truth for a factory composition claim it did not observe.

For evidence scope, see What a passport field can and cannot prove.

Update rights should be field-specific, not page-specific

A simple “can edit passport” permission is too coarse.

The DPP framework points towards permissions that can differ by actor and data type.

A safer software model is:

The final cells in this table are deliberately not filled with universal permissions. The law has not created one horizontal permission matrix for every product.

Registry updates are versioned and logged

The Registry regulation gives a clearer operational rule for registration data.

Article 10 says changes to DPP registration data, including creation, modification and deletion, are logged and reflected in registration status.

The Registry supports versioning of registered data and stores a Commission timestamp for each update.

This creates an important implementation principle:

A correction should create an accountable history, not make the previous state disappear without trace.

That principle is stronger for Registry data because the Regulation explicitly requires versioning and logs.

For the underlying decentralised DPP, the exact update rights and lifecycle rules still depend on the applicable product law and the system design required to satisfy it.

What happens when the responsible person changes?

Changing the person who clicks Edit inside a company is different from changing the organisation that legally carries the obligation.

The Registry allows verified organisations to manage user profiles and, where Union law provides, delegate access rights to third-party users.

If the business itself changes hands, responsibility can be transferred using the Registry transfer mechanism where the conditions are met.

Do not solve a corporate transfer by simply changing an email address on the DPP.

Do not solve an employee departure by transferring the product identity to another company.

The actor hierarchy should be explicit:

organisation → legal role → user → permission → action

What should a business build now?

Even before every product-specific edit matrix exists, the low-regret controls are clear.

Keep source ownership separate from publication rights

Record who is the source of each fact, who approved it and who is permitted to publish a change.

Keep an immutable history

Do not destroy the previous value when a regulated field changes. Preserve effective dates, evidence and the actor who made the change.

Use field-level permissions

Do not give an external actor broad edit rights merely because they need access to one lifecycle field.

Separate customer users from legal actors

A SaaS user account should not be treated as the legal economic operator.

Build delegated actions as delegated actions

If software submits a Registry update for a customer, record that it acted on behalf of the responsible actor rather than claiming responsibility transferred to the platform.

Make product-specific permissions configurable

The permission model should accept the future delegated act instead of hard-coding a speculative textile rule today.

Direct questions

Can the manufacturer always edit the whole DPP?

Do not assume that. The applicable product rule determines who may create or update the DPP and which data each actor may introduce or update.

Can a repairer change the DPP?

Potentially, where the relevant Union law gives the repairer that action and the actor has the required access or verification. Being a repairer alone does not create universal write rights.

Can ActivateDigital update the Registry for a customer?

The Registry framework allows third-party registration actions where the relevant Union law provides for them and the third party meets the verification conditions. The verified economic operator remains responsible for compliance with its Registry obligations.

Does a DPP service provider own the passport data?

Do not infer ownership from hosting or backup. The service-provider role, contractual processing rights and legal update permissions are separate questions.

Can I overwrite a wrong value?

The data-governance answer depends on whether the change is a correction, new effective-date value, batch change, new product identity or evidence update. Registry registration data is versioned and logged. Use the overwrite/version/new-product decision guide for the underlying product record.

Who can delete a DPP?

There is no universal horizontal rule that every verified actor may delete any passport. Registry registration-data deletion and retention are governed by Regulation 2026/1778 and the applicable Union law, while product-specific DPP availability and lifecycle rules remain relevant.

What would change this page

Recheck this page when:

• a product-specific delegated act publishes its actor access and update-right matrix
• the DPP service-provider delegated act changes provider permissions or duties
• the Commission publishes detailed Registry delegation or value-chain-actor workflows
• new product legislation gives repairers, refurbishers, remanufacturers or recyclers explicit write rights
• a future technical standard changes how update provenance or signatures are implemented.

Try it on one product

Start by establishing which product facts belong to the business, what evidence supports them and what should happen when one changes. Permission design is much easier once field ownership is explicit.

Activate one product →

Primary and official sources

• Regulation (EU) 2024/1781, Ecodesign for Sustainable Products Regulation Relevant here: Articles 9(2)(f) to (i), 10, 11 and the value-chain definitions.

  View official source

• Commission Implementing Regulation (EU) 2026/1778 Relevant here: Articles 4, 5, 6, 6a, 8, 10, 19 and 20.

  View official source

• European Commission, DPP for Repairers and Recyclers Supports the current Commission description of the information repairers and recyclers may access, while confirming that exact information depends on product group and law. Last verified: 3 September 2026. This page is practical guidance, not personalised legal advice.

  View official source

https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/repairers-and-recyclers_en Supports the current Commission description of the information repairers and recyclers may access, while confirming that exact information depends on product group and law.

Last verified: 3 September 2026. This page is practical guidance, not personalised legal advice.