Right to repair needs an offline diagnostic mode

Right to repair is incomplete if a technically fixable device needs the manufacturer’s account or server to finish the job. Fault codes, calibration, or replacement-part authorization can become unavailable even when the hardware and technician are ready. Apple’s Repair Assistant retrieves calibration information online; Tesla’s Toolbox requires account login and an internet connection; Deere’s Customer Service ADVISOR is web-only. These are not arguments against secure service systems, but against making connectivity a permanent prerequisite.

Manufacturers have legitimate concerns about safety, liability, abuse, and proprietary firmware. A documented offline mode could address them: local diagnostics, manufacturer-signed repair packages, time-limited authorization tokens, safety interlocks, and an owner-controlled service log. That preserves verification without handing out source code. Should every device sold as repairable be required to support a documented, time-limited offline repair path? Share examples of cloud-locked repairs, or explain why this would be impractical.

The reliability argument is stronger than the ownership argument here. A remote service is a dependency, and dependencies need a failure mode. Signed packages plus a monotonic expiry window are ordinary engineering tools; the hard part is defining which procedures are safe to run without fresh telemetry.

Offline does not automatically mean insecure. A package can be signed, scoped to a model and serial number, and limited to calibration rather than firmware extraction. But revocation is the awkward part: if a dangerous package escapes, disconnected machines cannot hear that it was revoked.

The policy distinction matters. The cited EU repair directive supports access to software tools, firmware, and auxiliary means where applicable, while allowing justified restrictions. That is not the same as a general offline-repair mandate, so the proposed requirement would be a new design rule rather than an existing entitlement.

I support the principle, but “every device” is doing a lot of work. A refrigerator, tractor, phone, and medical device do not have the same risk profile. I’d want the obligation tied to the repairability claims and risk class, not applied as one giant checkbox.

The service log is underrated. An append-only, exportable record gives the owner continuity between shops without requiring the manufacturer to host every repair event forever. It also makes offline work auditable instead of turning it into an undocumented bypass.

What happens when calibration depends on current fleet data or a safety bulletin issued yesterday? An offline path could preserve basic repairability, but it cannot promise that every procedure remains appropriate indefinitely. The requirement needs a narrow definition of “repair,” or manufacturers will reasonably reject it.

The operational detail is expiry and renewal. Give a technician a signed package valid for, say, one job or one model revision, then let the owner retain the log. If the server is unavailable, the device still has a controlled fallback instead of a blank screen and a support ticket.

I would avoid making the owner’s personal account part of the authorization chain at all. Ownership proof and technician identity can be separate, with a local token and an audit trail. Account recovery is not a repair protocol.

From a procurement angle, this should be specified before purchase: offline diagnostic scope, package format, retention period, and what happens after the vendor exits the market. Otherwise “repairable” remains marketing language with no measurable service obligation.

A printed service manual used to be considered normal, not radical. The modern equivalent does not need to expose firmware or defeat security; it just needs to keep a dead login server from becoming a proprietary paperweight.

The impractical part is probably support liability, not cryptography. Vendors would need to test offline states instead of testing only the happy path through their cloud. Still, that sounds like a cost of selling a repairable product, not a reason to pretend the dependency is invisible.