how do I update data in a product passport that is already published

Adjusting data after publication: what is possible and what is not

A product passport that is live can be updated in parts, but cannot be completely rewritten at will. The ESPR makes a distinction between information that is inherent to a specific product or batch — such as material composition or test results — and information that can change, such as a repair status, a change of ownership, or an update by the manufacturer. Article 10 of the ESPR (Regulation (EU) 2024/1781) sets out requirements regarding the accessibility and accuracy of the data behind the QR code, and that is precisely the core issue: the data must be correct, even over time. A passport is therefore not a snapshot that is fixed forever, but neither is it a loose form that everyone can update at their own discretion.

For whom this applies and for whom it does not

This is relevant for any party responsible for compiling and keeping the passport up to date — for aluminium semi-finished products typically the manufacturer or the importer placing the product on the market. This concerns changes to the content of an already published passport, not the initial creation of a passport, and nor does it concern the question of who may view or consult a passport. It equally does not concern replacing the data carrier itself: if the QR code on the product is damaged or becomes unreadable, that is a different matter than updating the data behind it — what happens if the QR code on my aluminium becomes illegible addresses that specifically. Nor does adjusting a passport after a business closure fall within this scope; that touches on a different question, namely who has access to and responsibility for the data after a business closes.

When exactly this will come into play

An exact date on which these obligations enter into force for aluminium semi-finished products is not yet fixed. The ESPR as a framework regulation is already in force, but the concrete requirements per product group — including aluminium profiles, castings and packaging aluminium — will be laid down in a delegated act which according to the European Commission's work programme for 2025-2030 is expected in 2027. Until that act is in place, there is as yet no concrete obligation for this product group to create or modify passports. Once the delegated act has been published, the date will be stated here. What is already established is the principle from Article 9 of the ESPR: the passport must show the correct information throughout the entire period that it must be available — and that directly affects how changes after the fact are treated.

How this will work in practice

For those already working with a passport or preparing for it, the sequence is roughly as follows. First, it is established which piece of data is changing: is it an error in the original data, is it an addition (for example a certificate that becomes available later), or is it data that changes over time, such as a change of ownership of a semi-finished product that is resold. Next, it is checked whether the identification of the product remains the same — the link between the physical product and the passport runs via the unique identification code, and how do I assign a unique identification code to each product describes how that link is structured and why it must remain stable, even if the content of the passport changes. Subsequently, the change is implemented with the party that hosts and maintains the passport available: at alupas.eu this means that a change is submitted by the manufacturer or importer, which is then processed in the hosted passport without the QR code or link changing. That is precisely why hosting and data carrier are separate from the one-off compilation: the QR code on the aluminium remains unchanged, while the data behind it can be updated. Whoever links the passport to their own ERP or inventory system can also use that link to have changes run through automatically — can I link the digital product passport to my ERP or inventory management system addresses how that link works and what is required for it. In case of doubt as to whether an amendment still falls within the original product identity, or whether a new product (and thus a new passport) is actually created, the core of Article 9 is a good starting point: the passport must correctly describe the product unit in question, and as soon as this is no longer the case, a new registration is more appropriate than an amendment to the existing one.

Where this follows from: Articles 9, 10 and 11 of the ESPR

The basis lies in Article 9 of the ESPR (Regulation (EU) 2024/1781), which describes the digital product passport as a data carrier that contains correct and current information about the product for the established period. Article 10 of the ESPR elaborates on this with requirements for the content and accessibility of that information, and Article 11 of the ESPR governs the technical design and operation of the passport, including the way data is recorded and disclosed via the data carrier. Together, these articles form the framework within which an amendment after publication takes place: the identification and the carrier remain in place, the underlying data is updated as soon as it is no longer correct.

Companies that already produce or import aluminium semifinished products and are preparing for the product passport would be best advised to establish an internal process governing who may submit amendments and at what time — so that this process is in place when the delegated act for aluminium is published and the obligation actually takes effect.

What this is based on

The regulation itself is on EUR-Lex. We refer per statement; you do not have to take our word for it.

What you must concretely do

What is expected of you

The ESPR is based on a product passport that remains usable throughout the entire life cycle of the product. This does not mean that the content remains the same forever: some data changes after publication, for example because a test result is supplemented, a part of the supply chain changes, or because it becomes apparent that previously entered data is incorrect. Article 9 and Article 10 of the ESPR (Regulation (EU) 2024/1781) describe what a digital product passport must contain and what requirements it must meet; Article 11 addresses the technical design and operation of it. From this follow a number of practical obligations for those who manage the passport after publication.

The link between product and data remains intact

The passport should remain accessible via the same unique identification code and the same carrier, even if the underlying data changes. For a company with 10 to 100 employees, this means that a change in administration must not lead to a new QR code on a product already in circulation. How that link between product and passport is technically structured is related to the way in which give each product a unique identification code has been given: that code does not change along with a data amendment, only the content behind the code.

Data must remain current and reliable

Article 9 sets requirements for the correctness and currency of information in the passport. This is not a snapshot upon delivery, but an ongoing principle. For a manufacturing company, this means there must be a way to flag when data becomes outdated — for example following a change in alloy composition, a new test report, or an adjustment to recycled content. Those who link the passport to an existing ERP or inventory system can often let changes flow through automatically; how this works is described at link to your own system.

The history of amendments must be traceable

Article 11 describes requirements for the technical functioning of the passport, including the way in which data is stored and made accessible. For a user consulting the passport, what matters above all is that the information displayed is correct at the time of consultation. For the manufacturer or importer, this means that changes must be traceable: who modified what, and when. This is not only a technical matter, but also an organisational one — particularly when multiple departments (quality, sales, engineering) provide input for the same passport.

Changes must not disrupt discoverability

A passport that has been entered in the European register must remain findable and consultable according to the stated requirements, even after modification. What must be included in it and how that relates to changes in the underlying data is described at the register of digital product passports. A modification in the passport itself does not automatically mean that the register entry will also be updated — this is a point to watch when setting up the management process.

Where things go wrong in practice

A number of situations recur regularly in practice when modifying an already published passport.

A new QR code with each modification. Some companies have a new QR code generated with every data change, out of caution. The result is that older products with the old code no longer match the current passport, or confusion arises about which code belongs to which batch.

Modification in the system, not in the passport. A change is made in the ERP system, but the link to the passport is not renewed. The user who scans the QR code then still sees the old data, while the internal administration has already been updated.

Unclear about who is authorised to make changes. When multiple departments provide input, there is sometimes no documented responsibility for the final decision on a change. A quality test result and an updated composition from procurement can then be entered separately, without anyone checking the relationship.

No visibility of the consequences for linked passports. For a product that, together with other components, has multiple product passports a change in one passport is sometimes made without checking whether it also has consequences for the linked passport of another component.

Forgetting that older language versions become outdated. For a passport that displays multiple language versions via one QR code a change is sometimes made only in the main language, while the translated versions remain unchanged.

What you can document now

An internal change protocol: who is authorised to modify which data, who reviews the change before it goes live, and how is the change documented.
An overview of which fields in the passport come from which source system, so that when a change is made in the ERP system, it is clear which passport component is affected.
A log of changes per passport, with date, description and the person who made the change — useful when there is a later question about when a piece of data was modified.
An agreement on how to handle multilingual versions: whether a change in the main language automatically leads to a review of the translated versions.
A check on the register entry after a change, so that the data in the European register aligns with the current content of the passport.
For products with multiple passports: an overview of the interdependencies, so that a change in one passport does not inadvertently cause another passport to fall behind.

For these points, templates are available that align with the platform's structure, so that the change process does not have to be reinvented on a case-by-case basis.

This is not legal advice. This page provides general information on the legislation that this platform covers. We do not know your situation. If in doubt about your own case, consult a lawyer or the competent supervisory authority.

Written with AI based on the sources above, checked by a human on 2026-09-05. Is something incorrect? Let us know — corrections are prioritised.