Highlights | At Embedded World North America 2026, conversations at the Mender booth and two conference sessions highlighted the growing complexity of connected products, increasingly combining Linux systems, microcontrollers (MCUs), applications, and firmware. Engineering teams need advanced software update management strategies that cover the complete product, planned well before production scale, and covering the entire device lifecycle.
Embedded World North America 2026 brought the embedded community to the Anaheim Convention Center in Anaheim, California, from September 22 to 24. Across three days of booth conversations, demos, and conference sessions, the Mender team heard a consistent message: managing connected products has grown far beyond updating a single device.
Showcasing software updates for microcontrollers (MCUs), the Mender demo quickly became a hot topic. Visitors frequently stopped to watch it, inquired about the Zephyr real-time operating system (RTOS), other RTOS environments, and how to manage software updates beyond embedded Linux.
As a market leader, Zephyr was a central topic, but the MCU market isn't exclusively Zephyr. FreeRTOS came up in several conversations, and other discussions covered FPGA-based hardware, NXP platforms, robotics, and other resource-constrained devices.
Software updates on microcontrollers – whether over-the-air (OTA) or in air-gapped environments – introduce different constraints around memory, flash storage, bootloaders, connectivity, and recovery. An A/B partition scheme that is routine on a Linux device requires a specific design to accommodate a device with limited flash and recovery paths heavily dependent on the bootloader. One question raised captures the practical challenge well: what changes when software updates have to span both Linux and MCU devices?
The Linux-and-MCU question is significant because many products now contain both. One medical device company described a product consisting of two separate devices: an NVIDIA system running Ubuntu and an NXP system running Yocto. The company is roughly two years away from production, yet its team already recognizes it will need to manage software updates across both devices within its product.
Similar patterns emerged in conversations about robotics, industrial equipment, appliances, automotive, satellites, FPGA-based systems, and edge devices. A single connected product may now include Linux systems, MCUs, containerized applications, firmware, and configuration data, each with its own update requirements.
The core question is shifting from "How do I update this single device?" to "How do I manage the software state of a product made up of multiple devices and components?" As products gain more independently updatable components, teams must plan not only how each component is updated individually, but also how changes across components are coordinated and verified as a whole.
Luis Ramírez-Vargas, Embedded Linux Customer Engineer at Northern.tech, explored fleet complexity in his conference session, "Scaling Software-Defined Device Fleets: Managing Software in the Field."
Scale introduces variables that a small pilot fleet rarely exposes, including:
Each of these variables compounds the others. A fleet that is straightforward to manage at a pilot scale can become untenable at a production scale unless the update infrastructure is designed for high complexity from the start — with visibility into what is running where, targeted deployments, and safe recovery when an update fails.
Where Ramírez-Vargas focused on scaling increasingly complex fleets, Esteban Agüero Pérez, Linux Embedded Engineer at Northern.tech, focused on the operational reality after a connected product ships. Offering a complementary perspective in his Exhibitor Forum session, "You Shipped Your Devices, Now What?," Agüero Pérez framed post-deployment work as a continuous cycle: ship, update, monitor, troubleshoot, recover, secure, maintain, and repeat. Shipping a connected product is not the end of the software engineering problem; it marks the start of the product's longest phase in the lifecycle.
Each stage of the cycle depends on decisions made before launch. Recovering from a failed update requires a rollback mechanism that already exists on the device. Troubleshooting a field issue requires visibility into the software each device is running. Delivering a security fix requires a secure, reliable path to every device in the fleet, including devices with intermittent connectivity. Teams managing brownfield deployments often experience the consequences firsthand: adding software update and maintenance capabilities after devices are in the field is far harder than building them into the product architecture from the beginning.
The lesson is straightforward: an update strategy is easiest to design before the first devices ship. Treating software updates and lifecycle management as part of the product architecture, rather than as capabilities added later, gives teams more options and fewer constraints as their fleets grow.
The EU Cyber Resilience Act (CRA) came up frequently, including among U.S. companies planning to sell into Europe. One small appliance manufacturer explained that its current cloud IoT approach wasn't providing the reliability it needed at scale, and that expanding into Europe would introduce CRA requirements. Another attendee had a new project in which OTA updates were being considered, specifically due to the CRA requirements.
The conversations also revealed some confusion about what the EU CRA actually requires. The essential requirements oblige manufacturers to ensure vulnerabilities can be addressed through security updates, and to provide mechanisms to securely distribute updates, automatically where applicable.
The CRA imposes obligations on vulnerability management and the timely delivery of security fixes, and manufacturers need an effective way to meet those obligations across deployed fleets. Mender provides operational capabilities that support mandated responsibilities, such as signed update delivery, deployment visibility, and robust rollback. Full CRA compliance, however, spans processes and documentation beyond any single solution. In practice, the CRA is accelerating investment in capabilities that manufacturers increasingly need to bolster security and safety.
Across three days in Anaheim, a consistent picture emerged. Connected products are becoming more heterogeneous, sophisticated, and complex. Fleets are growing more advanced, not only larger. Regulations such as the EU CRA are raising expectations for how manufacturers maintain devices after launch, and edge AI is extending the software stack that teams must manage in the field.
The common thread is that delivering an update is only one part of managing software today. Knowing what is running across a fleet, recovering safely when something goes wrong, and coordinating changes across the components of a product all shape whether a connected product remains secure and reliable over its lifetime.
Many of the challenges discussed in Anaheim, from fleet complexity to planning updates before production, are explored in depth in the 2026 State of Industrial IoT Device Lifecycle Management report. Learn more about the report and how engineering teams are approaching OTA updates and device lifecycle management today.