{"id":709,"date":"2026-10-13T09:00:00","date_gmt":"2026-10-13T09:00:00","guid":{"rendered":"https:\/\/odmhome.com\/blog\/?p=709"},"modified":"2026-10-20T04:01:46","modified_gmt":"2026-10-19T20:01:46","slug":"ota-firmware-maintenance-after-launch","status":"publish","type":"post","link":"https:\/\/odmhome.com\/blog\/ota-firmware-maintenance-after-launch\/","title":{"rendered":"After Launch: Firmware Updates, Security Patches and Who Maintains Your Product"},"content":{"rendered":"

A connected product is not finished when it ships. It ships with firmware that will need fixing, a cloud service that will need maintaining, and a certificate that will expire. Brands that plan for this keep customers; brands that discover it in year two tend to discover it through a review that says the app stopped working. In short, After Launch Firmware Updates is the deciding factor for most buyers.<\/p>\n

What has to be maintained<\/h2>\n\n\n\n\n\n\n\n\n\n
Layer<\/th>\nWhy it changes<\/th>\nTypical cadence<\/th>\n<\/tr>\n<\/thead>\n
Device firmware<\/td>\nBugs, new features, protocol updates<\/td>\nOccasional, ideally OTA<\/td>\n<\/tr>\n
Security patches<\/td>\nVulnerabilities discovered later<\/td>\nUnscheduled, must be fast<\/td>\n<\/tr>\n
Mobile app<\/td>\nOS updates on iOS and Android<\/td>\nAt least annually<\/td>\n<\/tr>\n
Cloud service<\/td>\nCost, scaling, regional data rules<\/td>\nContinuous<\/td>\n<\/tr>\n
Certificates and keys<\/td>\nExpiry<\/td>\nYears, and always forgotten<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The certificate row is the one that has ended products. A TLS certificate or a cloud credential with a fixed expiry, no monitoring and no owner will take a working product offline on a specific date, and the fix requires a firmware update to devices already in customers’ homes.<\/p>\n

OTA architecture: three decisions<\/h2>\n

Signed updates.<\/strong> Every update must be cryptographically signed and verified by the device. Without this, an update mechanism is a remote access path \u2014 and for a lock or a camera, that is not a theoretical concern.<\/p>\n

Staged rollout.<\/strong> Updates go to a small percentage first, then widen. The failure mode this protects against is a bad update bricking a whole installed base simultaneously, which is the single worst outcome in connected hardware.<\/p>\n

Safe rollback.<\/strong> The device should keep a known-good image and be able to return to it. If an update fails mid-write, the product must still boot \u2014 which means dual-bank firmware or an equivalent, decided at the hardware design stage rather than patched in later.<\/p>\n

Ask your ODM partner three concrete questions: how are updates signed, can they be rolled back, and what percentage can be staged. The quality of the answer tells you how much of this was designed versus bolted on. The platform side of this decision is discussed in our white-label app and SDK guide<\/a>.<\/p>\n

Security patching is a service-level question<\/h2>\n

Agree, in writing, how long security patches will be provided and how quickly a critical vulnerability is addressed. This is not paranoia: connected devices are scanned continuously, and a camera or a lock with a known unpatched flaw becomes a support and reputational problem rather than a technical one. For cameras in particular, buyers in regulated sectors will ask directly \u2014 the same territory as our note on NDAA-compliant supply<\/a>.<\/p>\n

End of support: plan the end at the start<\/h2>\n

Every product has an end, usually driven by a chipset going obsolete rather than by a decision. What you want is: advance notice of component obsolescence, a last-time-buy opportunity, a stated date after which firmware updates stop, and \u2014 ideally \u2014 a defined offline behaviour. A device whose cloud service shuts down should degrade to working locally rather than becoming a paperweight, which is an argument for local control paths and local automations on a gateway<\/a> rather than cloud-only logic.<\/p>\n

The cost line nobody budgets<\/h2>\n

Cloud and maintenance cost scales with the installed base, not with the order. Ten thousand devices in the field is a recurring monthly cost and a support obligation that persists for years. Put it in the unit economics before pricing the product, alongside the one-off items in the development cost breakdown<\/a>. Then decide, honestly, what your support term is \u2014 and publish it. A stated “we provide security updates until 2031” is a marketing asset, and it forces the internal planning that makes it true.<\/p>\n

Who does what, in writing<\/h2>\n

The most common gap is not technical but organisational: nobody owns the app store listing. Firmware is usually maintained by the ODM partner, while the iOS and Android listings belong to the brand \u2014 and a listing with no named owner lapses, expires, or fails to be rebuilt against a new SDK. Put four owners in a document: firmware, cloud, app listings, and certificate renewal. Add a calendar entry for each certificate’s expiry with a reminder ninety days out, because that is the only one of the four that fails silently and completely.<\/p>\n

Frequently Asked Questions<\/h2>\n

How long should we commit to updates?<\/h3>\n

Two years of feature updates and four to five of security patches is a credible commitment for consumer smart home<\/a> hardware. Publish whatever you commit to.<\/p>\n

Can updates be rolled back?<\/h3>\n

They should be. Ask for the mechanism, not the reassurance.<\/p>\n

What happens if the cloud service ends?<\/h3>\n

Design for graceful degradation: local control should keep working. Cloud-only products become landfill.<\/p>\n

Who owns the update process?<\/h3>\n

Usually the ODM partner for firmware, you for the app store listings. Both need named owners \u2014 an unowned listing lapses.<\/p>\n

For how all of this is scheduled around a launch, see the lead-time guide<\/a>, and for the production-side discipline behind reliable firmware, the quality system<\/a>. That is why After Launch Firmware Updates keeps gaining attention in this category.<\/p>\n

<\/p>\n

Related Articles<\/h2>\n