How often must I update the data in the product passport?
Keeping it up to date happens when changes occur, not on a fixed schedule
The ESPR does not contain a fixed deadline such as "update every year" or "amend within thirty days". What it does contain, in Article 9 of Regulation (EU) 2024/1781, is that the information in the digital product passport must be accurate, complete and up to date. This is a results obligation, not a calendar obligation: the passport must be correct at the moment someone consults it, and must not be checked only after a fixed period. For most product data entered at creation — origin, materials, conformity — nothing changes after production, so for that data, "keeping it up to date" is in practice mainly: leaving it recorded correctly. For data that can change, such as information about repair or a change of owner, the obligation applies at the moment that change occurs.
Who this applies to, and for which data it does not
This obligation affects the party responsible for the product passport — usually the manufacturer or importer who places the product on the market. Article 10 of the ESPR describes the technical and organisational requirements for the passport, including who may supply or amend which information. This means that not every party in the chain can simply modify data: who may amend which information depends on the role that party has in relation to the product. What explicitly does not fall under this: data that is by definition a snapshot, such as a test result or a certificate on the date of creation. These do not need to be continuously reconfirmed — they simply remain on record as a historical fact, unless a later change (such as a new version of the product) requires a new passport or an amendment. Nor is this an obligation to proactively search for changes; the obligation arises at the moment there is new, relevant information.
When exactly this takes effect is not yet fixed per product group
The general standard — accurate, complete, up to date — applies as soon as the product passport becomes mandatory for a product group. But how that standard applies in practice, with which triggers and possibly which deadlines, is further developed per product group in the delegated acts that the European Commission draws up for that group. At present, for most product groups it has not yet been determined which events precisely require an update and within what timeframe. Anyone seeking a specific, per-product-group answer to this will therefore not find it in the ESPR itself but in the delegated act published for that specific group. Until then, the general line from Article 9 applies: the passport must be correct, and the responsible party ensures that.
What this means in practice
For a manufacturer or importer working with a product passport, this amounts to a few practical steps. First: determine which data in the passport are static (remain as entered) and which are dynamic (can change during the product's lifetime, such as repair history or ownership). Next: set up a process by which changes to that dynamic data actually make it into the passport — this requires a link between the place where that information is generated (for example, a repair service or a second owner) and the passport itself. Then: keep an eye on which delegated act appears for your product group, because that will determine whether additional, specific requirements for keeping it up to date apply. And finally: take into account that "up to date" does not mean nothing needs to happen until there is a reason — as soon as there is a change that is relevant to the information in the passport, the obligation arises to process it, regardless of whether a fixed deadline for it has already been set.
Where this is stated: Article 9 and 10 ESPR
The requirement that information in the digital product passport must be accurate, complete and up-to-date follows from Article 9 of Regulation (EU) 2024/1781 (ESPR), which contains the general provisions for the digital product passport. Article 10 of the same regulation sets out the technical and organisational requirements that the passport must comply with, including the question of who may provide or modify information. Both articles leave the concrete implementation — which events lead to an update and within what timeframe — to the delegated acts that are adopted for each product group on the basis of this regulation.
Those who already have to deal with a product passport are well advised to distinguish between static and dynamic data in their own data structure in advance, and to monitor the publication of the delegated act for their own product group for the precise rules on keeping information up-to-date.
Where this is based on
- 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
Articles 9 and 10 of the ESPR (Regulation (EU) 2024/1781) describe what a digital product passport must be able to do and which data should be included in it, but do not provide a general rule for how often that data must be updated. What does follow from the text, however, is a number of reference points that together determine how current a passport must be in practice.
The passport must be correct at the moment it is consulted
Article 9 states that the digital product passport must be accessible via the data carrier and that the information in it must reflect the characteristics of the product. For a company with ten to one hundred employees, this means that the passport is not a snapshot that remains on the shelf after publication, but a collection of data that corresponds to what is known about the product as long as the passport is accessible. When a specification changes — a different supplier of a component, an adjusted composition, a new test result — a difference arises between what the passport says and what the product actually is.
Changes to product data flow through to the passport
Article 10 sets out requirements for the data in the passport, including data that directly result from the product group-specific rules established for each product group. That raises the question which data goes into the product passport of products, because not every piece of data has the same sensitivity to change. A physical dimension rarely changes, a test result on an environmental indicator can change as soon as the production method changes or as soon as a new measurement is taken according to the method for measuring the values. For a company with multiple product variants and periodic adjustments to its assortment, this means that maintaining passport data is a recurring task, not a one-time exercise at launch.
The link between passport and product must remain recognizable
A passport that belongs to a product must still recognize that product at the moment something changes in a model variant, a batch or a product version. For a medium-sized company working with multiple model numbers, this means that a change to a product not only affects a technical file, but also raises a question: which passports belong to which version, and is that distinction still clear for someone consulting the passport via the QR code on the product itself.
Where things go wrong in practice
A supplier change is not implemented in the passport. A manufacturer switches supplier for a component, the new specifications differ in some respects, but no one links that change back to the already published passport. The passport continues to show the old data.
Test results are confused with fixed characteristics. A result from a single measurement is entered in the passport as if it were a permanent fact, when it actually belongs to a specific batch or test date. In a next production run, the moment is missing when someone asks themselves whether the data is still correct.
Repair information no longer matches the current parts offer. Data about repair and parts in the passport are filled in at launch, but when a part is phased out or replaced by a different part number, the old information remains because no one treats that part of the passport as a "living" document.
Multiple language versions drift apart. When a Dutch text is updated, it is forgotten that a French or German version also exists for data in multiple languages. One language version then shows a different state of affairs than the other, while both are linked to the same QR code.
A discovered error is solved provisionally instead of structurally. Someone notices that a passport displays incorrect data, manually adjusts it in the system at that moment, but fails to record when and why this adjustment was made. With the next modification, it is no longer possible to trace what the original source of the error was — whereas there should be a fixed procedure for the moment when an error is discovered in an already published passport.
What you can document
- An overview of which data in the passport are susceptible to change — a distinction between fixed characteristics (dimensions, material type) and variable data (test results, supplier of a component, availability of spare parts).
- A fixed moment in the production process at which passport data are checked — for example with every modification to the technical documentation, when a supplier changes, or during a periodic internal review.
- A person responsible for maintaining each passport per product group — particularly relevant for a company that is active in multiple product groups simultaneously, because the data and review frequency can differ per product group.
- A log of changes to a published passport — what has been adjusted, when, and based on which source document, so that a modification remains traceable.
- A check on the consistency between language versions with every modification, so that one language version does not lag behind the other.
- An overview of which data are published under which conditions, especially when part of the underlying information relates to the question of whether data about the product are commercially sensitive and therefore should not simply be accessible to everyone — this distinction carries through into how an update is implemented and who has access to it.
For companies that work with a platform that hosts the passport and manages the QR data carrier, part of this documentation shifts to the agreement with that party: who implements the modification, within which process, and how is it ensured that the published version matches the most recently submitted data from the company itself.
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 on the basis of the sources above, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections are given priority.