Ecodesign Regulation
Effective November 1, 2026, Section 15 of the Ecodesign Act (ÖkodesignG) will regulate access to replacement parts and repair information for volunteer repair initiatives as well. Non-commercial repairers covered by the law must demonstrate compliance with the relevant regulations and provide proof of adequate insurance coverage. The scope and content of this access are determined by the applicable product regulations. Thus, the assessment begins with the specific product group and the requirements set forth therein.
In its overview dated July 29, 2026, the Federal Environment Agency lists, among other things, exploded views, diagnostic and error codes, as well as software and firmware, as repair information. This presents a practical challenge for product development:
The documentation must correspond to the specific device and its version.
When replacing a printed circuit board, for example, mechanical interchangeability alone is not sufficient. The replacement board must also be compatible with the intended software version. For this reason, a clear mapping between device variant, replacement part, and approved software version is required. If a supplier modifies an assembly, verifying this mapping is part of product maintenance.
In small development teams, this work competes with ongoing projects. If well-maintained documentation is lacking, a query from the service department can trigger the need to search through old development versions again. If the person in charge is unavailable, the reliance on their knowledge becomes apparent. That is why responsibilities and update procedures should be clearly defined even during development and should align with existing CAD, PLM, and software processes.
In our article “Sustainability in Product Development—Part 1” we already discussed repairability as a development decision. For product maintenance, we consider mechanical, electronic, and software aspects together.
If your team lacks the capacity for product maintenance, you can, for example, define the preparation of a device family—including documented variants, clarified interfaces, and a designated person responsible for future changes—as a limited development task.
