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.
What has to be maintained
| Layer | Why it changes | Typical cadence |
|---|---|---|
| Device firmware | Bugs, new features, protocol updates | Occasional, ideally OTA |
| Security patches | Vulnerabilities discovered later | Unscheduled, must be fast |
| Mobile app | OS updates on iOS and Android | At least annually |
| Cloud service | Cost, scaling, regional data rules | Continuous |
| Certificates and keys | Expiry | Years, and always forgotten |
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.
OTA architecture: three decisions
Signed updates. Every update must be cryptographically signed and verified by the device. Without this, an update mechanism is a remote access path — and for a lock or a camera, that is not a theoretical concern.
Staged rollout. 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.
Safe rollback. 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 — which means dual-bank firmware or an equivalent, decided at the hardware design stage rather than patched in later.
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.
Security patching is a service-level question
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 — the same territory as our note on NDAA-compliant supply.
End of support: plan the end at the start
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 — ideally — 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 rather than cloud-only logic.
The cost line nobody budgets
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. Then decide, honestly, what your support term is — 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.
Who does what, in writing
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 — 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.
Frequently Asked Questions
How long should we commit to updates?
Two years of feature updates and four to five of security patches is a credible commitment for consumer smart home hardware. Publish whatever you commit to.
Can updates be rolled back?
They should be. Ask for the mechanism, not the reassurance.
What happens if the cloud service ends?
Design for graceful degradation: local control should keep working. Cloud-only products become landfill.
Who owns the update process?
Usually the ODM partner for firmware, you for the app store listings. Both need named owners — an unowned listing lapses.
For how all of this is scheduled around a launch, see the lead-time guide, and for the production-side discipline behind reliable firmware, the quality system. That is why After Launch Firmware Updates keeps gaining attention in this category.
Related Articles
- How to Choose an ODM Partner: 5 Pitfalls to Avoid
- Smart Watch: A Customizable Wearable for Health-Focused Brands and Retailers
- White-Label Video Doorbell App and SDK: What to Ask Your ODM
- Security Camera OEM Manufacturer: A Complete Guide for 2026
- 7-Inch Video Doorbell Kit: A Complete Smart Entry Solution for OEM Buyers
📌 This article is part of our Complete Security Hub — more guides and buying tips inside.
XingLiao Smart Home — OEM/ODM Sourcing Guides
- How to Choose a Smart Switch Manufacturer in China
- Smart Switch Board Manufacturer (OEM/ODM)
- Tuya Smart Switch OEM
- Video Intercom Manufacturer
- China Factory vs Trading Company — How to Tell
Need a quote? Talk to our Shenzhen factory →
