FOTA Firmware Updates for Hardware: Who Owns Year Three?
A device that ships with working firmware is not the same as a device that still works in year three. FOTA, firmware over the air, is the mechanism that closes that gap, and it is the part of an AI hardware programme that buyers most often leave to the supplier to sort out later. That works until the supplier's roadmap moves on, the app store listing lapses, or a security patch is needed for a component nobody documented. The commercial question is not whether updates happen, but who is contractually obliged to produce them, for how long, and at whose cost.
What FOTA actually covers, and what it does not
FOTA is a delivery channel, not a support policy. It can push a new firmware image to an AI wearable or a companion robot, but it cannot fix a hardware fault, replace a worn battery, or restore a cloud service you have switched off. Separate the three layers in your specification: the update client on the device, the update server or CDN that hosts images, and the signing key that authorises them. Each has a different owner and a different cost profile. If the signing key stays with the supplier and the supplier disappears, you cannot ship a patch even if you have the source. Ask for key custody, or a documented key escrow arrangement, as a line item rather than an afterthought.
The three-year question for unsold stock
Stock sitting in a European or North American warehouse is exposed the moment a firmware dependency changes. If the companion app requires a server certificate that expires, or the pairing flow depends on a service the supplier has retired, the units are not merely outdated, they are non-conforming against the description you sold them under. This is where importers inherit liability that the factory never carried. Two contractual instruments reduce the exposure: an offline or local update path that does not depend on a live cloud service, and a notice period for end of support long enough to run a final update campaign across channel inventory. Neither is exotic, but both must be designed in before tooling, because retrofitting a local update path to a sealed device is often impossible. The same discipline applies when you compare OEM versus ODM engagement models, since an ODM build usually places more of the software stack under the supplier's control.
Security patches and the regulatory backdrop
Radio equipment placed on the EU market is expected to remain compliant for its foreseeable lifetime, and the importer carrying the CE mark is the economic operator answerable for that. In practice this means you need a defensible answer to a simple question: if a vulnerability is disclosed in a chipset or an open-source library inside the device, who writes, tests and ships the fix? A supplier that answers "we will look at it" has not answered. What you want is a written support window, a defined severity triage, and a named engineering contact. Certification is a separate matter: CE RED scope, FCC Part 15, battery UN38.3 and the toy scope under EN 71 and EN 62115 are booked per hardware revision with an accredited laboratory, and a firmware change that alters radio behaviour can invalidate the tested configuration. Read the how we build and test description of QC gates with that in mind, because IQC, IPQC, FQC and OQC govern the build, not the lifetime of the software on it.
| Lifecycle item | Who normally owns it | What to agree in writing |
|---|---|---|
| Update client on device | Factory, at build | Update mechanism and rollback behaviour fixed in the specification |
| Signing key custody | Brand owner | Key handover or escrow, with format and access terms |
| Update server and CDN | Brand owner | Hosting, cost owner and migration path if the supplier exits |
| Support window | Negotiated | Start date, duration, severity triage and response expectation |
| End-of-support notice | Negotiated | Notice period long enough to clear channel stock or patch it |
| Offline update path | Factory, at design | Local update route that does not depend on a live cloud service |
| Importer duties | Importer | WEEE, BattG, DEEE/Triman, EORI and VAT registration |
Where an importer should say no
Some supplier positions are reasonable and some are not. Walk away from a build where the factory refuses to document the software bill of materials, where the update server is only reachable through the supplier's own account, or where the support window is described verbally and never appears in the purchase contract. Be equally firm about scope creep in the other direction: a companion robot is not a monitoring or emergency-response device, health metrics are wellness guidance rather than diagnosis, and translation output is a reference translation. Writing those boundaries into the product description protects you from a claim you cannot defend. If you are still at shortlisting stage, the how to vet a supplier checklist is a useful filter before you discuss firmware at all.
- Ask for the software bill of materials per hardware revision, including third-party libraries and licences.
- Confirm whether Google Play or GMS is licensed; it is not licensed by default on our builds.
- Test the update path on a sample, including a failed update and a rollback, before mass production.
- Confirm that a firmware change does not move the device outside its tested certification configuration.
- Decide who pays for the update server in years two and three, and put a number in the contract.
Planning the handover before tooling
Most lifecycle problems are cheap to solve at specification stage and expensive afterwards. Decide the support window, the key custody model, the offline update route and the end-of-support notice period while the industrial design is still open. That conversation is easier when the hardware platform is already documented, which is why buyers often start from the product catalogue or the AI device line to see which form factors fit, then move to OEM/ODM services once the software ownership model is settled. Minimum order quantities reflect that split: 500 units standard, 2,000 for firmware or app white-label, and 50 units quoted per project for service robots. Samples run 3 to 5 days from stock or 7 to 15 days configured, with sample cost credited against mass production, and production runs 25 to 35 days.
Send us the specification with your intended support window, your key custody preference and the markets you will register in, and we will return a build scope that states plainly what sits with the factory and what sits with you.
Questions buyers ask
Who is responsible for security patches after the warranty ends?
Under EU law the importer or brand owner carrying the CE mark is the economic operator, so the duty to keep a device patched follows the brand, not the factory. WingPhoenix can supply build images, signing keys and source access so you or a contracted engineering partner can ship updates. Agree the handover format before tooling starts.
What happens to unsold stock if firmware support stops?
Stock you cannot update becomes unsellable if the companion app or cloud endpoint is withdrawn, because the device no longer performs as described at purchase. Ask for an offline update path and a documented end-of-support notice period. Budget for either a final update campaign or a write-down.
Related: more on ai smart hardware · buyer guides · customisation tiers