Must I record how long a device receives software updates?
Software support is not yet a binding obligation
A mandatory period for software updates is not yet fixed. The ESPR framework regulation (Regulation (EU) 2024/1781) does provide the legal basis to make this binding per product category, but the actual requirement — how long a manufacturer must continue to supply updates, and whether that period must be stated in the digital product passport — will only be laid down in a delegated act for the specific product group. For electronics and ICT equipment, that act does not yet exist. Until it does, there is no general, enforceable obligation to set an update period in the passport, even though software obsolescence is precisely the kind of sustainability topic that the ESPR is designed to address.
Relevant for products with software, not for everything
This subject applies to devices whose functionality depends on software: smart domestic appliances, ICT equipment, and broader electronics with firmware or operating software. For purely mechanical products without software, the question simply does not arise. Also within the electronics sector: the ESPR works with delegated acts per product subcategory, so a requirement that applies to smartphones does not automatically apply to a washing machine or a router. The framework regulation itself (Articles 5 to 7) lists the type of requirements that can be set — including durability, reliability and suitability for repair and upgrade — but does not yet translate that into a specific number of years for a specific product. Anyone now looking for a firm period for a specific appliance will therefore find it nowhere in the current text of the ESPR.
No fixed date yet: delegated acts per category
There is no fixed date when this will apply to electronics and ICT. According to the ESPR work plan 2025-2030, delegated acts are being developed per product subcategory, with an expectation that the first of these will be published from 2027 onwards. This is an indication from the work plan, not a commitment and not a law. Until a delegated act for a specific product group is published, the general provisions of the ESPR (Articles 5 to 7 for the substantive requirements, Article 10 for what must be in the digital product passport) apply to that group without a concrete update period yet following from them. As soon as a delegated act for electronics or ICT is published, the date and content of that requirement will be stated here.
What this means: order of approach
Anyone wishing to prepare for this should first look at their own product category in the ESPR work plan and then follow the publication of the corresponding delegated act from there — that is the moment when it becomes clear whether, and for how long, an update period becomes mandatory and whether it must be included in the digital product passport. Until that publication, there is no legal obligation to include this information in a passport, but nothing prevents a manufacturer from keeping track internally now of how long software support is promised per product line — that is then an own, voluntary commitment, not an ESPR obligation. For anyone having a digital product passport drawn up, this means in practice: the current passport structure does not yet need to contain this field, but as soon as the delegated act for the relevant product subcategory prescribes it, that field will be added to the passport and filled with the data supplied by the manufacturer or importer at that time. Anyone who now keeps data on software support — which models, which periods, which update policies — has a head start for when the requirement becomes concrete, because that data will then already be available to incorporate into the passport.
The basis: Articles 5 to 7 and Article 10
The possibility of imposing requirements on software support follows from Articles 5 to 7 of the ESPR (Regulation (EU) 2024/1781), which form the framework for ecodesign: performance requirements such as durability, reliability and upgradeability, and information requirements on these matters. These articles name the categories of requirements that can be further specified via delegated acts for each product group, but do not themselves establish a concrete update period. Article 10 of the same regulation governs what must be included in the digital product passport; here too, the precise data fields per product category are determined on the basis of the requirements established for that category. As long as no delegated act has been published for electronics and ICT that specifically mentions software support, this subject remains within the framework regulation a possibility, not a concrete obligation.
If you are already dealing with this question, it is best to keep an eye on the publication of the delegated act for your own product category and in the meantime get your own data on software support in order, so that it is ready as soon as the passport asks for it.
What this is based on
- Regulation (EU) 2024/1781 (ESPR), Articles 5 to 7 (ecodesign requirements, performance and information requirements)
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
The regulation itself is on EUR-Lex. We provide references per statement; you do not have to take our word for it.
What you must concretely do
What is expected of you
Software support can become an ecological design requirement
The ESPR makes it possible to include requirements in delegated acts concerning the sustainability of a product, and within that also concerning software: how long a device receives functional and security updates, and what happens to the functionality of the device once that support ends. Articles 5 to 7 of the ESPR (Regulation (EU) 2024/1781) names this as part of the performance and information requirements that can be established per product group. For electronics and ICT equipment, this is one of the subjects considered relevant, given the role of software in the lifespan of a device — a washing machine or laptop that technically still works, but no longer receives updates, is often replaced in practice anyway. For a company of 10 to 100 employees, this means that the department responsible for product information (often the same one that already compiles warranty periods and user manuals) must start keeping track of a new data point: the period during which updates are delivered, per product model or per software version.
The information must be traceable in the product passport
Article 10 of the ESPR (Regulation (EU) 2024/1781) describes which information must be included in the digital product passport once a delegated act establishes that for a product group. Once software support duration becomes a requirement for electronics, that information does not only end up in a manual or on a website, but also in the passport itself — structured, and linked to the QR data carrier on the product. For a mid-sized company, this means that the update period cannot be determined separately by the software department and communicated separately by marketing: that information must ultimately be in the same dataset as, for example, energy consumption and repairability score. What exactly must be in the passport varies by product group; on which data will appear in the product passport for electronics? is an overview of the categories of data that appear in it.
The stated period must match reality
Establishing a support duration is one step; making that happen is another. If a manufacturer commits to a period of updates in the passport, the expectation is that this period is actually met — and that changes (an earlier stopped update cycle, an acquisition where a software team is downsized) are recorded. This touches on the question of how often passport data must remain current; see how current must the data be? for what is known about that. For a company of this size, this often means that the commitment on update duration is not only made by the product manager, but is coordinated with the party that actually maintains the software — internal team or external supplier.
Where things go wrong in practice
A first scenario: a manufacturer mentions an update period in marketing material ("five years of security updates"), but this commitment is not documented anywhere in an internal document with a start date and end date. Once that information must be in the passport, there is no unambiguous source to draw from.
A second scenario: the software of a device is supplied by a supplier (a chip manufacturer, a platform provider), and the importer who compiles the product passport does not know how long that supplier guarantees support. The responsibility for the correctness of passport data lies with the party having the passport drawn up, even if the underlying information comes from a third party.
A third scenario: a device is sold in multiple versions (different chipsets, different software versions per market region), but the update period is stated as a single figure for the entire model number. Upon later inspection, some versions turn out to be supported for a shorter period than others.
A fourth situation: a device already sold receives no further updates earlier than planned due to a strategy change, without this change being communicated to whoever manages the product passport. The passport data continues to show the original, overly optimistic period.
A fifth situation: a company assumes that "software support" concerns only security updates, while functional updates (new features, compatibility with new accessories) are treated separately — and communication about this to the customer is inconsistent, without clarity on which of the two belongs in the passport.
What you can document
- An internal document per product model with the committed period of functional updates and security updates, each with a clear start date (for example market introduction) and, if known, end date.
- Agreements with software suppliers or component suppliers regarding the minimum support duration they guarantee, including what happens in case of acquisition, bankruptcy or discontinuation of a platform.
- An overview of which functionality of the device depends on software updates, and what happens to that functionality once support ends (for example: the device continues to perform basic functions, but loses connection with an app).
- A process to communicate changes in the update schedule (early discontinuation, extension) to the department that manages the product passport, so that the data does not fall behind reality.
- Distinction per version or variant of a product model, if software support differs per chipset or market region.
- Documentation of the source of the information: is the stated period an own commitment, or a passed-on guarantee from a component supplier? This is relevant once someone asks what a data point in the passport is based on — see also I have found an error in the product passport, what now? for how to handle incorrect or outdated data.
Once the delegated act for electronics and ICT is published, it will become clear here what data exactly is mandatory and in what form. Until then, building your own verifiable file on update periods is a way to avoid having to reconstruct later what was once promised.
This is not legal advice. This page provides general information about the regulations that this platform covers. We are not familiar with 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, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections take priority.