Innovation in AI application development moves fast. New computer vision (CV) models, updated neural network weights, and refined detection algorithms can emerge on a weekly or even daily basis. Teams and system integrators leveraging AI-enabled IoT products increasingly expect their fleets to reflect the latest analytical capabilities, not whatever was baked into a firmware bundle months ago.
For example, a smart camera product line rarely sees a single use case. One unit monitors a retail floor using a fresh convolutional neural network (CNN) model, updated weekly to keep pace with new shoplifting patterns. Another camera sits on an outdoor perimeter fence, where the same detection model runs untouched for months while the underlying OS quietly absorbs a security patch. A third secures a government facility, where neither the model nor the OS moves without a maintenance window, a change ticket, and an approval chain. The hardware is the same; the context and requirements of each software layer are not.
The variability in use, not just the number of devices in the field, is the difficulty in updating AI-enabled products, like smart cameras. Components within the same product need to evolve on varying schedules, driven by different teams, for specific reasons. A management infrastructure that ties every device to a single release pipeline cannot serve all of them at once, or any of them well.
Software update complexity challenges in AI-driven IoT products
Advances in self-learning video analytics, appearance search, and behavioral anomaly detection transformed smart cameras from passive recording devices into active security infrastructure. And, coverage now extends into access control and perimeter analytics. Today, a single unit may run embedded Linux, a real-time AI application layer, a CNN inference model, and a firmware stack from the silicon vendor. Each of these has its own owner, release cadence, and risk profile.
Innovation velocity is a competitive differentiator. Companies building physical security products compete on the quality of their AI models: detection accuracy, inference speed, and the breadth of scenarios it handles. Every engineering hour spent maintaining an in-house software update infrastructure is an hour not spent improving the model itself, or shipping the features that actually differentiate the product.
Security compliance requirements are tightening. The EU Cyber Resilience Act (CRA) introduces mandatory security obligations for connected products sold in the European market, including role-based access control (RBAC), audit trails, and controlled update pipelines. An update process that conflates the permissions of an AI researcher, a firmware engineer, and a field support technician is a compliance gap waiting to surface during an audit.
Update needs diverge as fleets mature. A newly deployed fleet might update its detection model and its OS at a similar cadence. As the product matures, that alignment breaks down. Model improvements accelerate as the R&D team learns what customers need; OS updates slow to a quarterly security cadence once the platform stabilizes; firmware barely moves at all. An infrastructure built around a single shared release schedule falls further behind the real pace of each component the longer the product is in the field.
Why monolithic deployments break down at scale
Bundling firmware, OS, applications, and files into a single release made sense when smart cameras were simpler, and updates were infrequent and scheduled. That assumption no longer holds. When every software layer ships together, a change to any one of them forces a release of all of them: an improved motion-detection model triggers a full firmware flash, and a routine OS security patch requires revalidating the AI application on top of it. The slowest-moving component throttles the release velocity of every other component, and every release carries the combined risk footprint of everything bundled into it, whether or not that component actually changed.
The problem compounds as a fleet scales and diversifies. Some customers want continuous model updates as new detection scenarios emerge. Others need dynamic reconfiguration based on the time of day or event triggers. Others still run under compliance schedules that require any updates to be reviewed, tested, and approved on tight timelines. A single all-or-nothing release strategy cannot accommodate any of these without over-serving one requirement at the expense of another.
Fleet management adds a further layer of difficulty. Coordinating thousands of devices across customer sites, network topologies, and compliance postures requires targeting specific device groups, staging rollouts, and rolling back cleanly if something goes wrong, none of which a manual or semi-manual pipeline can sustain. And because embedded devices are exposed to power loss and network interruptions during updates, an interrupted install must leave the device in a known-good state regardless of which layer was being updated. Without that guarantee built in, every release, however small, is a potential fleet-wide outage waiting to happen.
Independent update domains adapt to each fleet’s pace of change
The fix isn't a better bundle. It's removing the bundle as a concept, so that each layer of the software stack updates on its own schedule, risk, and release cadence actually demanded.
For example, Mender separates a smart camera's software into independently deployable domains, each using the update mechanism suited to it:
- Embedded Linux OS updates are delivered as full rootfs-image updates using an A/B partition scheme.
- AI application updates are deployed as independent containerized application updates.
- CNN model file updates are delivered as lightweight Artifact updates, independent of both the OS and the application layer.
- Firmware updates are delivered through proxy deployments for components that can't run a Mender client directly.
Because each domain is decoupled, each can move at its own pace without restricting other software layers. A customer running weekly model updates does not force weekly OS releases. Quarterly, audited OS patches do not block the R&D team from shipping a detection improvement the same week it's validated. And because the domains are independent, a failed model update can't corrupt the OS, and an OS rollback doesn't silently revert a model improvement that had nothing to do with it. Each layer carries only its own risk, not the combined risk of everything shipped alongside it.
A/B Partition Design and Rollback
At any time, the device holds two complete OS partitions: the one currently running and a standby version. An update writes to the standby partition while the device keeps operating on the active one, and the bootloader only switches over once the new image is fully written and verified. If power is lost mid-write, the active partition is untouched. If the new image fails to boot, the device reverts automatically. The result holds regardless of how frequently or infrequently OS updates are scheduled for a given fleet.
Granular access control keeps each domain in the right hands.
Because model updates, application updates, and OS updates are separate deployment types, RBAC can restrict each to the team responsible for it; an AI researcher pushing a model file cannot touch firmware, and a field technician troubleshooting a device cannot push an OS release. That separation also turns update governance from a manual policy into enforced, auditable control, which is precisely what regulations like the CRA are beginning to require.
Fewer constraints on how fast any one layer moves
When update domains are decoupled, the pace of innovation in one part of the stack is no longer constrained by another part’s release schedule. Detection models can ship as often as the data supports it. OS updates can follow whatever compliance cadence a customer's environment demands. Firmware can stay untouched for as long as it's stable. None of these schedules has to negotiate with the other, and none compromises the fail-safe guarantees that keep a device recoverable in the field.
That flexibility is what lets a single product line serve both a retail deployment that iterates weekly and a regulated facility that approves changes quarterly, without maintaining two separate update infrastructures to do it.
See how it works
To learn how to containerize Mender with Docker, check out Composable Updates: Independent Update Domains for OS, Applications, and Containers.
