From 31 July, the repair path matters
On 31 July 2026, Member States must apply Directive (EU) 2024/1799. It is intended to promote the repair of goods and complements existing consumer guarantee rules. This is not a Digital Product Passport law. Yet the date is a useful operational milestone for manufacturers, importers, retailers and repair businesses: repair can only be offered reliably when the relevant product, spare-part and process data can be found and assessed. The Directive was adopted on 13 June 2024, entered into force on 30 July 2024 and applies from 31 July 2026, as confirmed by the European Commission and Article 22 of the Directive.
The practical mistake would be to treat a product passport as a compliance PDF. A dependable data layer must support the route from identifying a particular product to making a defensible repair decision. That work can start now without pretending that a product-group-specific DPP obligation has already been adopted.
What the repair Directive actually requires
The Directive covers goods subject to EU reparability requirements and listed in its Annex II. For those products, manufacturers must repair on request where repair is technically possible. The Commission cites refrigerators and smartphones as examples. The rules operate beyond the legal guarantee; within the guarantee period, they are designed to make repair the more attractive remedy. The Directive also creates a European repair-information form and a European online repair platform. The authoritative detail is in Directive (EU) 2024/1799.
For planning, one distinction matters. The Directive does not turn every product passport into a repair passport. It does not prescribe one universal spare-part data model or a particular QR code. The data required in a future DPP will follow the relevant delegated acts under the Ecodesign for Sustainable Products Regulation. Keeping that distinction clear avoids overclaiming in sales material and building data structures that do not fit the later product-group act.
Why the DPP is still the right data anchor
Regulation (EU) 2024/1781 defines the Digital Product Passport as an electronically accessible set of product-specific data. It provides that a DPP should be connected through a data carrier to a persistent unique product identifier. Future delegated acts can specify whether data are held at model, batch or item level, who may update them and how long the passport must remain available. Those elements are set out in Article 9.
Article 11 is especially relevant to repair operations: professional repairers and independent operators are expressly among the actors that may receive access according to the applicable rights. Access is not simply public; it is governed by product-group-specific rights. This leads to a technical design principle rather than a new legal claim: model separate data views for customers, repair businesses, spare-part teams and authorities. A QR code can resolve to a robust identifier, but it should not itself be the place where sensitive operational, contractual or customer data reside.
A six-stage repair data path
A sound target state does not start with a dashboard. It starts with an auditable flow.
1. Identify the product reliably
At scan or manual entry, the system must establish whether the request concerns a model, batch or individual unit. The persistent identifier needs stable resolution: not a campaign URL, a seasonal product page or an address that disappears in a redesign. With dynamic QR codes, a documented redirect and fallback path is therefore part of the architecture. For a technical introduction to product-level DPP endpoints, see the published qr3 guide to creating DPPs by API.
2. Keep reparability separate from diagnosis
A data sheet can say that a product is repairable in principle. It cannot on its own answer whether the specific fault, safety condition and spare-part availability allow repair. Keep separate fields for the product rule, fault diagnosis, safety alert and repair decision. The decision needs provenance, a timestamp and a responsible role. That prevents a general statement becoming an untestable promise to a customer.
3. Manage spare parts with versions and validity
Repair teams need more than a part number. They need compatibility, hardware or software revision, availability, permitted substitutes, safety information, installation instructions and the last verification date. A supplier-status change must not overwrite the original part record. Model versions and validity periods instead. This also makes recalls, service campaigns and later traceability manageable.
4. Define roles, not blanket access
Public information can include a model designation, care guidance and a repair contact point. Depending on the product, professional repairers need additional technical documents. Internal teams may require deeper supplier and quality data. Define that separation early and log access to non-public content. The ESPR requires a high level of security and privacy for DPPs, and customer personal data must not be stored in a passport without explicit consent.
5. Make the request status traceable
The new Directive improves access to repair information. Operational trust, however, comes from requests not disappearing into inboxes. A minimal status flow is enough: request received, identity or device checked, estimate prepared, spare part available, repair agreed, completed, or declined with a reason. Every decline should retain the specific reason and the next available route. This is also the foundation for credible service metrics.
6. Feed the repair outcome back
After a component replacement, at least the service history changes and configuration, guarantee information or safety status may also change. Define who may create that entry, what evidence must be retained and which roles can see which result. The ESPR requires DPP data to be accurate, complete and up to date. A repair history without governance would not meet that standard.
What to check this week
31 July is not a reason for a rushed full migration. It is a useful checkpoint for three concrete questions. First, can you connect a repair request for the affected product groups to an unambiguous product? Second, are spare-part and compatibility data versioned and discoverable by entitled repairers? Third, can you show who changed a record and why?
If any answer is no, begin with one pilot product and one real repair case. Measure time from scan to defensible decision, not the number of populated fields. That connects repair practice applying from 31 July with a DPP architecture that remains open for future delegated acts.
Sources
- European Commission: Directive on repair of goods – status and application date of the repair Directive.
- EUR-Lex: Directive (EU) 2024/1799 – official text, including Articles 4, 21 and 22 and Annex II.
- EUR-Lex: Regulation (EU) 2024/1781 – Digital Product Passport, particularly Articles 9 to 11 and Annex III.
