Designing Connected Hardware That Can Actually Be Repaired

Repairability has moved from a virtue to a requirement in the EU, and the dates are close enough to matter to anything being designed now. What makes this different from most compliance work is that it cannot be handled at the end. A privacy policy can be written the week before launch. A device that cannot be opened without destroying it is finished being decided at the first mechanical review.

The headline requirements are concrete. Batteries must retain at least 80 percent capacity after 800 charge cycles. Software support must run at least five years. Spare parts must be available for at least seven years for phones and up to ten for large appliances. Read those as engineering constraints rather than as legal text and they say something specific: you are committing to a supply chain, a build environment and a parts inventory for the better part of a decade.

The spare parts obligation is the one that surprises teams, because it constrains component selection years ahead. Designing around a part that goes end-of-life in three years means either buying a decade of stock up front or redesigning the board later to keep supplying repairs. Neither is free, and the decision is made — usually without anyone noticing — at the moment someone picks a component because it was cheapest in the current catalogue.

Mechanical choices are where most repairability is won or lost, and the tradeoff is usually against ingress protection. Adhesive is cheaper than fasteners, seals better, and makes a device thinner. It also means the first repair attempt destroys the housing. Getting both is possible — captive screws with a replaceable gasket is the standard answer — but it costs millimetres and cents that have to be defended early, before the industrial design is frozen.

For connected hardware there is a further problem the rules address only indirectly: a repaired device has to be able to rejoin the world. If the mainboard carries the device identity and pairing state, replacing it produces a physically working device that no longer authenticates, is not recognised by the owner's account, and cannot be re-provisioned without a support ticket. That is a repairability failure even though every mechanical requirement was met. Deciding early where identity lives, and making re-provisioning a supported flow rather than a factory-only path, is the part of this that belongs to firmware rather than to mechanical engineering.

The useful test is to try it. Take a production unit, replace the battery and the mainboard using only tools and documentation a third party could obtain, then bring it back onto the network as its original owner. Everything that goes wrong in that hour is what the regulation is about, and it is considerably cheaper to discover before the tooling is cut.