can I have the data in the product passport updated automatically
Automatic updates are possible, but not automatic themselves
Yes, data in the digital product passport can be updated automatically, but this does not happen by itself — it is something that must be set up. The ESPR requires that the passport contains current data and that it is technically possible to update information, but the regulation does not mandate automatic integration. Whether an update runs automatically depends on how the passport is technically configured: if it stands alone, someone updates it manually; if it is linked to a source system, a change there can flow directly into the passport.
For which data automation works and does not work
The distinction that matters here is between data that is fixed at production and data that changes during the product's lifetime. A technical characteristic such as material composition or a test result is established at the moment the product is made, and does not change thereafter — automatic updating is less relevant there, because there is nothing that changes. Other data is dynamic: a repair status, a change of owner, an update of a warranty period, or data that differs per market region. For such data, a link with a source system is valuable, because the passport then moves with what changes in practice, without someone having to enter that separately each time. Article 10 of the ESPR (Regulation (EU) 2024/1781) establishes as a requirement that the data in the passport is accurate, complete and current — that is the obligation to which automation can be a practical answer, but the regulation itself does not mandate the technique to achieve that.
What also does not apply here: replacing automation by simply making changes. Who is authorized to adjust which data, and how that remains demonstrable, is a different matter than the technique of updating itself. A link makes the process faster, but does not remove the responsibility to determine which data are correct.
When this becomes relevant is not yet fixed per product group
There is no fixed date on which automatic updating becomes mandatory, simply because the obligation to automate does not exist — what is established is the requirement that the passport must be current once it applies to a product group. When this comes into effect for each product group is determined per delegated regulation and thus varies per product. Until the moment that a product group falls under an obligation, no passport is needed and therefore no updating question arises. Once a product group does fall under the obligation, the requirement of accuracy and currency applies from that moment — the form in which this is technically resolved (manually or automatically) is up to the manufacturer or importer, within the technical frameworks that Article 11 of the ESPR (Regulation (EU) 2024/1781) sets for the functioning of the passport.
How this is tackled in practice
The first step is to determine which data in the passport actually change during the product's lifetime, and which are fixed. For the fixed data, automation is usually not necessary — they are entered once and remain in place. For the dynamic data, the next step is to look at whether there is already a system in which that information is maintained, such as an ERP system, an inventory system or a service administration. If there is, then linking the digital product passport to an ERP system or inventory system is the way to ensure that a change in the source automatically flows into the passport, without duplication of work.
After that, it is a matter of establishing who within the organization is permitted to make a change and how that change remains traceable — not because the regulations prescribe this as a separate process, but because a product passport that must remain available for ten years or longer can change owner or status multiple times during that period. This also raises the question of how long a product passport must remain available, and what happens to it if the data behind it changes — see how long a product passport must remain available. If you are compiling digital product passports for multiple product groups, it is advisable to set up the link in such a way that a change in the source system does not inadvertently affect the wrong passport, especially when a product falls under multiple passports at once falls.
The legal basis: articles 9, 10 and 11 of the ESPR
That the passport must contain current data follows from article 10 of the ESPR (Regulation (EU) 2024/1781), which sets accuracy, completeness and currency as requirements for the information in the passport. Article 9 of the ESPR (Regulation (EU) 2024/1781) describes what the digital product passport is substantively and what information it contains, and article 11 of the ESPR (Regulation (EU) 2024/1781) governs the technical design and operation of the passport, including the possibility to update data. None of these articles prescribes a specific technology or form of automation — the obligation is the result (current, accurate data), not the method by which that result is achieved.
Those wishing to see how a link with their own system looks in practice, or how a unique identification per product plays a role in this, will find that in the knowledge base; for the exact text of the articles, the official publication of the ESPR in EUR-Lex is the source to consult.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 11 (technical design and operation of the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), article 9 (digital product passport)
The regulation itself is on EUR-Lex. We provide references for each claim; you do not have to take our word for it.
What you must do concretely
What is expected of you
The data in the passport must correspond to the current situation of the product
Article 9 of the ESPR (Regulation (EU) 2024/1781) sets requirements for the content of the digital product passport, and that content must represent the characteristics of the product as it is placed on the market. For a company with 10 to 100 employees, this means there must be a line connecting the place where product data originates or changes (procurement, engineering, quality control) to the place where the passport is located. In a manual process, this is a responsibility that must be assigned to someone; in a linked system, that update runs automatically alongside a change in the source system.
The passport must be technically designed so that data can be updated.
Article 11 of the ESPR addresses the technical design and operation of the digital product passport, and from this it follows that a passport is not a static document that is published once and then left as is. The QR code or other data carrier points to a location where data can be retrieved, and that location must therefore also be modifiable. For a company, this means that the choice for a platform or supplier is also a choice for how straightforward updates will be in the future — a passport that is effectively a fixed PDF-like file complies less well with that technical expectation than a passport that is linked to a living data source.
The link to source systems is a separate technical choice, not a requirement in itself.
Article 10 of the ESPR describes the requirements that the digital product passport must meet, but does not prescribe specific technology to synchronize data. Automatic updating is therefore not a separate legal requirement; it is a way to meet the existing requirement for accurate and up-to-date data. For companies with an ERP or PIM system, the question is whether the product passport can be linked to their own system is therefore mainly an operational question: how many products, how often do specifications change, and how much manual work is acceptable before errors arise.
Where things go wrong in practice
A first situation that often occurs: a supplier change in a component is processed in the ERP system, but no one has included the passport in the list of "systems that also need to be changed as a result". The passport then continues to display an outdated composition while the product has been supplied differently for months.
A second situation arises at companies that work with multiple product groups and thus with multiple passports that must align with each other. If one underlying piece of data (for example a material composition) appears in multiple passports, updating it in one place is not automatically carried through to the other places, unless that has been explicitly arranged.
A third situation: a company thinks the passport is "finished" after delivery and treats it like a certificate that no longer changes. Whereas precisely for composite products with a passport per component a change in one component can have an impact on the passport of the composite product, without that being immediately apparent.
A fourth situation occurs with manual entry via a portal: someone enters data once at launch, but no recurring process has been agreed for checking or updating. After a year, no one is certain whether the data is still correct, and no one feels responsible for it.
A fifth situation arises from a business takeover or discontinuation of a product line: the question what happens to the passport if the company ceases operations is only asked at the moment it becomes urgent, whereas agreements about updates and transfer of ownership should actually have been established in advance.
What you can document
- An overview of which source systems (ERP, PIM, quality database) feed which data field into the passport, so that it is clear where each change must be directed.
- An internal process or checklist that indicates when a product change automatically leads to a passport update and when manual review is necessary.
- A designated responsible person or role for keeping passport data current, even if this is largely automated technically.
- Documentation of the link between your own system and the passport platform, including which fields synchronize automatically and which do not — relevant when considering linking to your own ERP or inventory system.
- An overview of how product identification codes are structured, so that an update always reaches the correct passport — see also the explanation on assigning a unique identification code per product.
- A log or version history of changes to passport data, so that it can be traced afterwards when and why an adjustment was made.
- Agreements with suppliers or chain partners about notifying changes that affect the passport, so that an update does not depend on chance or loose emails.
This is not legal advice. This page provides general information about the regulations that this platform concerns. We do not know your situation. If you are in doubt about your own case, consult a lawyer or the competent supervisory authority.
Written with AI based on the sources above, reviewed by a human on 2026-09-05. Is something incorrect? Let us know — corrections are given priority.